Re: [PATCH/RFC] signal races/bugs, losing TIF_SIGPENDING and otherwoes

[Nicholas Miell]

On Tue, 2007-06-05 at 13:22 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
> > >  - I still think there's something wrong with dequeue_signal() being
> > > potentially called with a task different than current by signalfd, since
> > > __dequeue_signal() (among others) mucks around with current regardless.
> > > I'd love to just make signalfd's read() only do anything if current ==
> > > ctx->tsk and remove the task argument from dequeue_signal... that would
> > > fix it nicely too no ?
> > 
> > There's got to be a clean solution that does not limit signalfd, no? I 
> > have no time to look at it immediately, but I can look into it in the 
> > next few days, if someone else does not do it before...
> 
> Is there a real usage to dequeuing somebody else signals with signalfd ?
> If yes, then we can do something around the lines of passing task down
> to __dequeue_signal, though I'm not too sure waht this notifier is about
> and wether it might rely on being called from within the affected task
> context...
> 
> Ben.
> 

signalfd() doesn't deliver thread-targeted signals to the wrong threads,
does it?

Hmm.

It looks like reading from a signalfd will give you either
process-global signals or the thread-specific signals that are targeted
towards the thread that originally created the signalfd (regardless of
which thread actually calls read()).

Which is weird, to say the least. Definitely needs to be noted in the
man page, which doesn't seem to exist yet.

Is there a reason why signalfd() doesn't behave like regular signals in
this regard?

-- 
Nicholas Miell <nmiell@xxxxxxxxxxx>

-
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/