Re: [RFC/INCOMPLETE 00/13] x86: Rewrite exit-to-userspace code
From: Andy Lutomirski
Date: Wed Jun 17 2015 - 11:17:13 EST
On Jun 17, 2015 2:49 AM, "Ingo Molnar" <mingo@xxxxxxxxxx> wrote:
> * Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> > I tried to clean it up incrementally, but I decided it was too hard. Instead,
> > this series just replaces the code. It seems to work.
> Any known bugs beyond UML build breakage?
One minor one: the 64-bit and compat syscall asm changes should be
folded together. I was overly optimistic about bisectability -- the
intermediate step doesn't build. I haven't tested well enough to be
really comfortable with it, though.
There's another minor error in my description: the 32-bit code is not
a prerequisite for the exception_enter removal, so v2 will remove a
whole bunch of exception_enter calls. This considerably improves the
quality of the debugging checks.
> > Context tracking in particular works very differently now. The low-level entry
> > code checks that we're in CONTEXT_USER and switches to CONTEXT_KERNEL. The exit
> > code does the reverse. There is no need to track what CONTEXT_XYZ state we came
> > from, because we already know. Similarly, SCHEDULE_USER is gone, since we can
> > reschedule if needed by simply calling schedule() from C code.
> > The main things that are missing are that I haven't done the 32-bit parts
> > (anyone want to help?) and therefore I haven't deleted the old C code. I also
> > think this may break UML for trivial reasons.
> > Because I haven't converted the 32-bit code yet, all of the now-unnecessary
> > unnecessary calls to exception_enter are still present in traps.c.
> > IRQ context tracking is still duplicated. We should probably clean it up by
> > changing the core code to supply something like
> > irq_enter_we_are_already_in_context_kernel.
> > Thoughts?
> So assuming you fix the UML build I'm inclined to go for it, even in this
> incomplete form, to increase testing coverage.
> Doing that will also decrease ongoing merge friction between your work and other
> entry code cleanups ...
Sounds good to me. I'm not convinced this is 4.2 material, though.
Would it go in a separate branch for now?
On a related note, do you have any idea what work_notifysig_v86 in
entry_32.S is for? It seems unnecessary and wrong to me. Unnecessary
because we have return_to_32bit. Wrong because I don't see how we can
reliably enter vm86 mode if we have exit work enabled -- one of the
giant turds in vm86_32.c literally jumps from C code to
resume_userspace on vm86 entry, and resume_userspace promptly checks
for work and might land in work_notifysig_v86 before we ever make it
to v8086/user mode.
I think it may actually be impossible to use vm86 under ptrace. ISTR
I had some trouble when trying to strace my test case...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/