Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 17 Jun 2015 08:16:41 -0700 | Subject | Re: [RFC/INCOMPLETE 00/13] x86: Rewrite exit-to-userspace code |
| |
On Jun 17, 2015 2:49 AM, "Ingo Molnar" <mingo@kernel.org> wrote: > > > * Andy Lutomirski <luto@kernel.org> 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
| |