Date: Wed, 22 Aug 2007 12:53:29 +0200
From: Jarek Poplawski <jarkao2@o2.pl>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
       Roland McGrath <roland@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] do_sigaction: don't worry about signal_pending()
Message-ID: <20070822105329.GG1684@ff.dom.local>
References: <20070820160157.GA1279@tv-sign.ru> <20070822094325.GF1684@ff.dom.local> <20070822100210.GA139@tv-sign.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070822100210.GA139@tv-sign.ru>
User-Agent: Mutt/1.4.2.2i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1825
Lines: 43

On Wed, Aug 22, 2007 at 02:02:10PM +0400, Oleg Nesterov wrote:
> On 08/22, Jarek Poplawski wrote:
> >
> > On 20-08-2007 18:01, Oleg Nesterov wrote:
> > > do_sigaction() returns -ERESTARTNOINTR if signal_pending(). The comment says:
> > > 
> > > 	* If there might be a fatal signal pending on multiple
> > > 	* threads, make sure we take it before changing the action.
> > > 	
> > > I think this is not needed. We should only worry about SIGNAL_GROUP_EXIT case,
> > > bit it implies a pending SIGKILL which can't be cleared by do_sigaction.
> > 
> > Isn't it for optimization e.g., to skip this 'do while' loop below for
> > such multiple threads, which would get SIGKILL or SIGSTOP anyway?
> 
> Yes, in that case this 'do while' doesn't make sense. But this is very
> unlikely, sigaction() shouldn't be called too much often, better to save
> a couple of bytes from icache.
> 
> Also, please note that sigaction() is not special, almost any system call
> could be started with
> 
> 	if (current->signal->flags & SIGNAL_GROUP_EXIT)
> 		return ANYVALUE;
> 
> to "optimize" for the case when the task is dying.

OK, I only wasn't sure this was considered before getting this
"not needed" verdict.

BTW, sometimes, even if something is very unlikely, but very
time-consuming, and skipping this isn't so costly, there could be
a gain at the end. So, maybe it's about individual cases and some
testing too? (At least, it seems, somebody found this so usable,
she/he bothered with such a long comment, and we know it's a last
thing any decent kernel hacker would care to do...)

Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/