public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Fr馘駻ic Weisbecker" <fweisbec@gmail.com>, X86 <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Denys Vlasenko" <dvlasenk@redhat.com>
Subject: Re: context tracking vs. syscall_trace_leave & do_notify_resume loop
Date: Fri, 01 May 2015 12:00:02 -0400	[thread overview]
Message-ID: <5543A302.1020205@redhat.com> (raw)
In-Reply-To: <CALCETrUhmZjF1NbYHHE=CBswvrwNOyZja7zxpXeEjbFv-mRq5Q@mail.gmail.com>

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.

-- 
All rights reversed

  reply	other threads:[~2015-05-01 16:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01  1:30 context tracking vs. syscall_trace_leave & do_notify_resume loop Rik van Riel
2015-05-01 15:55 ` Andy Lutomirski
2015-05-01 16:00   ` Rik van Riel [this message]
2015-05-01 16:05     ` Andy Lutomirski
2015-05-01 16:14       ` Rik van Riel
2015-05-01 16:16         ` Andy Lutomirski
2015-05-01 16:19           ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5543A302.1020205@redhat.com \
    --to=riel@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox