Re: [RFC/INCOMPLETE 00/13] x86: Rewrite exit-to-userspace code

[Andy Lutomirski]

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...

--Andy
--
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/