Re: synchronous signal in the blocked signal context
From: Paul E. McKenney
Date: Tue Aug 01 2006 - 14:58:19 EST
On Tue, Aug 01, 2006 at 11:13:04AM -0700, Siddha, Suresh B wrote:
> On Tue, Aug 01, 2006 at 11:13:32AM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 01, 2006 at 08:25:12AM -0700, Linus Torvalds wrote:
> > >
> > >
> > > On Tue, 1 Aug 2006, Paul E. McKenney wrote:
> > > > >
> > > > > Paul? Should I just revert, or did you have some deeper reason for it?
> > > >
> > > > I cannot claim any deep thought on this one, so please do revert it.
> > >
> > > Well, I do have to say that I like the notion of trying to have the _same_
> > > semantics for "force_sig_info()" and "force_sig_specific()", so in that
> > > way your patch is fine - I just missed the fact that it changed it back to
> > > the old broken ones (that results in endless SIGSEGV's if the SIGSEGV
> > > happens when setting up the handler for the SIGSEGV and other
> > > "interesting" issues, where a bug can result in the user process hanging
> > > instead of just killing it outright).
> > I guess I am glad I was not -totally- insane when submitting the
> > original patch. ;-)
> > > However, I wonder if the _proper_ fix is to just either remove
> > > "force_sig_specific()" entirely, or just make that one match the semantics
> > > of "force_sig_info()" instead (rather than doing it the other way - change
> > > for_sig_specific() to match force_sig_info()).
> > One question -- the original (2.6.14 or thereabouts) version of
> > force_sig_info() would do the sigdelset() and recalc_sig_pending()
> > even if the signal was not blocked, while your patch below would
> > do sigdelset()/recalc_sig_pending() only if the signal was blocked,
> > even if it was not ignored. Not sure this matters, but thought I
> > should ask.
> > > force_sig_info() has only two uses, and both should be ok with the
> > s/force_sig_info/force_sig_specific/? I see >100 uses of force_sig_info().
> > > force_sig_specific() semantics, since they are for SIGSTOP and SIGKILL
> > > respectively, and those should not be blockable unless you're a kernel
> > > thread (and I don't think either of them could validly ever be used with
> > > kernel threads anyway), so doing it the other way around _should_ be ok.
> > OK, SIGSTOP and SIGKILL cannot be ignored or blocked. So wouldn't
> > they end up skipping the recalc_sig_pending() in the new code,
> > where they would have ended up executing it in the 2.6.14 version
> > of force_sig_specific()?
> I don't think it matters.
> signal_wake_up() in the path of specific_send_sig_info() should anyhow
> do that.
OK, looks plausible upon reviewing the code paths.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/