Hi Oleg,

  thanks for your comments.

On Fri, 2 Feb 2007 21:00:39 +0300 Oleg Nesterov <[EMAIL PROTECTED]> wrote:

> On 02/01, S?bastien Dugu? wrote:
> > 
> > +struct task_struct * sigevent_find_task(sigevent_t * event)
> > +{
> > +   struct task_struct *task = NULL;
> > +
> > +   if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
> > +           return NULL;
> > +
> > +   if ((event->sigev_notify & SIGEV_THREAD_ID ) == SIGEV_THREAD_ID) {
> > +           task = find_task_by_pid(event->sigev_notify_thread_id);
> > +
> > +           if (!task || task->tgid != current->tgid)
> > +                   task = NULL;
> > +   } else if (event->sigev_notify == SIGEV_SIGNAL)
> > +           task = current->group_leader;
> > +
> > +   return task;
> > +}
> 
> I am afraid this is still not right. Consider
> 
>       ->sigev_notify == SIGEV_THREAD_ID | RANDOM_BIT
> 
> Now, the second "if (SIGEV_THREAD_ID)" returns a valid task. However,
> 
>       really_put_req:
> 
>               if (notify == SIGEV_THREAD_ID || notify == SIGEV_SIGNAL)
>                       put_task_struct();
> 
> doesn't work, so we have task_struct leak.

  Right, I'll revert back to the old code with cleanups.

> 
> Worse, this breaks posix-timers. Note that posix-timers allow SIGEV_NONE,
> the timer is not queued in that case, we shouldn't do ->sigev_signo check.
> This means that aio should check SIGEV_NONE itself.
> 
> Also, it is critical for posix-timers that SIGEV_THREAD_ID doesn't come
> with another bit (like in the example below), note the code like
> 
>       if (sigev_notify == (SIGEV_SIGNAL|SIGEV_THREAD_ID))
>               ...
> 
> IOW: good_sigevent() in its current form is very cryptic, and it _really_
> needs a cleanup, but we should not change its behaviour.

  Yep. I must admit that I didn't pay enough attention to this 10-liner,
but in the end it rightfully backfired on me.

> 
> Apart from this, I don't see other problems in the signal related code in
> this series.
> 
> Oleg.
> 

  Thanks again for your review.

  Sébastien.
-
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/

Reply via email to