Re: Fix signalfd interaction with thread-private signals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 


On Sat, 23 Jun 2007, Benjamin Herrenschmidt wrote:
> 
> > 
> > It does exactly so, please note this chunk
> > 
> >  @@ -330,7 +339,7 @@ asmlinkage long sys_signalfd(int ufd, si
> > 
> >                  init_waitqueue_head(&ctx->wqh);
> >                  ctx->sigmask = sigmask;
> >  -               ctx->tsk = current;
> >  +               ctx->tsk = current->group_leader;
> > 
> > > It might well be that signalfd's concept of context is wrong in the
> > > first place and it should be attached to processes rather than threads
> > > and that made more explicit in the first place...
> 
> Yup, looks like I was looking at a wrong patch... I think it's the right
> thing to do indeed.

Quite frankly, it strikes me that if we want to do this, then we shouldn't 
save the _process_ information at all, we should save the "sighand" 
instead.

So either we save the process info, or we save the sighand, but saving the 
"group_leader" seems totally bogus. Especially as the group leader can 
change (by execve()).

One thing that strikes me as I look at that function is that the whole 
signalfd thing doesn't seem to do any reference counting. Ie it looks 
totally buggy wrt passing the resulting fd off to somebody else, and then 
exiting in the original process.

What did I miss?

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux