Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 1 May 2015 09:05:25 -0700 | Subject | Re: context tracking vs. syscall_trace_leave & do_notify_resume loop |
| |
On Fri, May 1, 2015 at 9:00 AM, Rik van Riel <riel@redhat.com> wrote: > On 05/01/2015 11:55 AM, Andy Lutomirski wrote: >> On Thu, Apr 30, 2015 at 6:30 PM, Rik van Riel <riel@redhat.com> wrote: > >>> I suspect it would be possible to stick a call to a new function >>> (return_to_user ?) right after the DISABLE_INTERRUPTS below, which >>> could be used to do the context tracking user_enter just once, and >>> later on also to load the user FPU context (patches I have sitting >>> around). >>> >>> syscall_return: >>> /* The IRETQ could re-enable interrupts: */ >>> DISABLE_INTERRUPTS(CLBR_ANY) >>> TRACE_IRQS_IRETQ >>> >>> Andy, Denys, do you guys see any issues with that idea? >> >> Ick. Let's make the mess better before we make it worse. Now that >> Denys disentangled the syscall exit path from the interrupt exit path, >> let me see if I can just rewrite the syscall exit path entirely later >> this week. > > I suspect we probably only need two possible function > calls at syscall exit time: > > 1) A function that is called with interrupts still > enabled, testing flags that could be set again > if something happens (eg. preemption) between > when the function is called, and we return to > user space. > > 2) A function that is called after the point of > no return, with interrupts disabled, which > does (mostly) small things that only happen > once.
I think we only need one function. It would be (asm pseudocode):
disable irqs; if (slow) { save extra regs; call function; restore extra regs; }
return via opportunistic sysret path.
I can't see any legitimate reason for the current mess, except that it's no complicated and so poorly documented that everyone's afraid of fixing it.
--Andy
| |