lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fix signalfd interaction with thread-private signals


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

\
 
 \ /
  Last update: 2007-06-23 00:49    [W:0.121 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site