On 09/30, Peter Zijlstra wrote:
>
> On Mon, Sep 30, 2013 at 07:40:54PM +0200, Oleg Nesterov wrote:
> > Once again, of course I do not blame this series, but
> > wait_event_timeout(wq, true, 0) still returns 0.
>
> So we have:
>
> [...snip...]
> So wait_event_timeout(wq, true, 0) turns into:
Not really, because of fast-path check,
#define wait_event_timeout(wq, condition, timeout)
\
({
\
long __ret = timeout;
\
if (!(condition))
\
__ret = __wait_event_timeout(wq, condition, timeout);
\
__ret;
\
})
we do not even call __wait_event_timeout() if "condition" is already
true at the start.
> > ___wait_event(wq, ___wait_cond_timeout(condition), \
> > TASK_INTERRUPTIBLE, 0, ret, \
> > spin_unlock_irq(&lock); \
> > - __ret = schedule_timeout(__ret); \
> > + ___wait_schedule_timeout(__ret); \
> > spin_lock_irq(&lock));
>
> You can't do that; you'll break/return without the lock held.
Yes, see another email, already noticed this.
And let me repeat just in case, I think this series is fine, just
wait.h needs another minor/orthogonal fix.
Oleg.
--
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/
