[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1207739787.27048.57.camel@shinybook.infradead.org>
Date: Wed, 09 Apr 2008 12:16:27 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Oleg Nesterov <oleg@...sign.ru>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Roland McGrath <roland@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-s390@...r.kernel.org, tony.luck@...el.com,
linux-ia64@...r.kernel.org, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] set_restore_sigmask TIF_SIGPENDING
On Tue, 2008-04-08 at 15:35 +0400, Oleg Nesterov wrote:
> Why do we need any flag? It looks a bit ugly. Isn't it better to introduce
> the new magic ERESTART_XXX which means ERESTARTNOHAND + restore-sigmask ?
>
> We only need this flag as an implicit parameter to the arch dependent do_signal()
> which we can't call directly, and thus it must imply TIF_SIGPENDING, and it
> is not valid after do_signal() (should be cleared). This all looks like
> ERESTART_ magic, why should we add something else ?
>
> See also http://marc.info/?l=linux-kernel&m=113734458516136
>
> Of course, probably it is too late to change the implementation even if
> I am right, the question is: what I am missed?
Q: When ppoll() is interrupted by a signal, what signal mask should be
active when the signal handler is active?
I believe that the signal handler should run with the temporary sigmask
which was set by ppoll(), and the original sigmask should be restored
only when the handler completes -- and that's what we achieve with
TIF_RESTORE_SIGMASK.
So a signal which was originally enabled but is temporarily disabled by
the mask passed to ppoll() will not be able to interrupt the handler for
the signal which interrupted ppoll().
Your version will restore the original signal mask _before_ invoking the
signal handler which interrupted ppoll() -- which I believe is not the
intended semantics. And IIRC that was the whole point in implementing
ppoll() in kernel rather than trying to emulate it in userspace in the
first place.
--
dwmw2
--
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