Hi, On 09/08, Tejun Heo wrote: > > Hello, > > On Wed, Sep 07, 2011 at 08:22:17PM +0200, Oleg Nesterov wrote: > > wait_event_freezable() and wait_event_freezable_timeout() stop > > the waiting if try_to_freeze() fails. This is not right, we can > > race with __thaw_task() and in this case > > > > - wait_event_freezable() returns the wrong ERESTARTSYS > > > > - wait_event_freezable_timeout() can return the positive > > value while condition == F > > Indeed, nice catch. This one actually is pretty dangerous. We > probably want to make a separate fix for this and backport it to > -stable? And I forgot to mention that wait_event_freezable_timeout() doesn't handle -ERESTARTSYS at all. But I don't think -stable needs this fix. According to grep, nobody check the returned value, and none of the callers plays with signals. > > Change the code to always check __retval/condition before return. > > > > Note: with or without this patch the timeout logic looks strange, > > probably we should recalc timeout if try_to_freeze() returns T. > > > > Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx> > > Yeap, with freezable_with_signal gone, this looks correct & simpler to > me I don't really understand this... set_freezable_with_signal() has a lot of problems, yes... But even if it wasn't removed this fix makes sense anyway, afaics. If freezable_with_signal caller does wait_event_freezable_timeout(), __retval becomes -ERESTARTSYS after freeze_task(). The next iteration will return 0 with the KERN_ERR message from schedule_timeout(). > but it would be nice if you can sprinkle some documentation while > at it. :) But they already have the comment ;) What can I add? Oleg. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
