[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140729173136.GA2808@redhat.com>
Date: Tue, 29 Jul 2014 19:31:36 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
Will Drewry <wad@...omium.org>, X86 ML <x86@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
linux-arch <linux-arch@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
Alexei Starovoitov <ast@...mgrid.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v3 6/8] x86: Split syscall_trace_enter into two phases
On 07/29, Andy Lutomirski wrote:
>
> On Tue, Jul 29, 2014 at 9:54 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > Yes, just to trigger the slow path, I guess.
> >
> >> I'll update the code to call user_exit iff TIF_NOHZ is
> >> set.
> >
> > Or perhaps it would be better to not add another user of this (strange) flag
> > and just call user_exit() unconditionally(). But, yes, you need to use
> > from "work = flags & (_TIF_WORK_SYSCALL_ENTRY & ~TIF_NOHZ)" then.\
>
> user_exit looks slow enough to me that a branch to try to avoid it may
> be worthwhile. I bet that explicitly checking the flag is
> actually both faster and clearer.
I don't think so (unless I am confused again), note that user_exit() uses
jump label. But this doesn't matter. I meant that we should avoid TIF_NOHZ
if possible because I think it should die somehow (currently I do not know
how ;). And because it is ugly to check the same condition twice:
if (work & TIF_NOHZ) {
// user_exit()
if (context_tracking_is_enabled())
context_tracking_user_exit();
}
TIF_NOHZ is set if and only if context_tracking_is_enabled() is true.
So I think that
work = current_thread_info()->flags & (_TIF_WORK_SYSCALL_ENTRY & ~TIF_NOHZ);
user_exit();
looks a bit better. But I won't argue.
> That's what I did for v4.
I am going to read it today. Not that I think I can help or find something
wrong.
Oleg.
--
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