[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130930181358.GA29544@redhat.com>
Date: Mon, 30 Sep 2013 20:13:58 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] sched, wait: Collapse __wait_event macros -v4
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists