[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120425125042.GF6871@ZenIV.linux.org.uk>
Date: Wed, 25 Apr 2012 13:50:42 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Russell King <linux@....linux.org.uk>,
Tejun Heo <tj@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Roland McGrath <roland@...k.frob.com>
Subject: Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such
On Wed, Apr 25, 2012 at 02:37:46PM +0200, Oleg Nesterov wrote:
> As for sys_sigsuspend() and this race in particular:
>
> > Arrival of a signal that has userland handler
> > and that isn't blocked by the mask given to sigsuspend() should terminate
> > sigsuspend().
>
> Yes. But note that do_signal() restores the old sigmask. This means that
> the signal we get after the first do_signal() was not blocked before
> sigsuspend() was called. So, to some extent, we can pretend that the
> handler was executed before sigsuspend() and it was never restarted.
Signal might have already arrived by the time we restore sigmask. So no,
it might have been blocked prior to sigsuspend().
I agree that relying on disabled interrupts doesn't work - objection would
have worked if it was just "what if we get NEED_RESCHED and while we are
scheduled away a signal arrives", but this scenario doesn't depend on
that. We definitely want interrupts enabled before we start playing with
do_notify_resume(), especially if things like deferred fput, etc. end up
there as well.
--
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