[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5543A302.1020205@redhat.com>
Date: Fri, 01 May 2015 12:00:02 -0400
From: Rik van Riel <riel@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
CC: Fr馘駻ic Weisbecker <fweisbec@...il.com>,
X86 <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: context tracking vs. syscall_trace_leave & do_notify_resume loop
On 05/01/2015 11:55 AM, Andy Lutomirski wrote:
> On Thu, Apr 30, 2015 at 6:30 PM, Rik van Riel <riel@...hat.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.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists