lkml.org 
[lkml]   [2015]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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


\
 
 \ /
  Last update: 2015-05-01 18:41    [W:0.039 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site