Re: Fundamental race condition in wait_event_interruptible_exclusive() ?

[Oleg Nesterov]

I have alredy replied to Ingo, but if I was not clear...

On 12/08, Linus Torvalds wrote:
>
> The reason it is buggy is that wait_event_interruptible_exclusive()
> does this (inside the __wait_event() macro that it expands to):
>
>                 long __int = prepare_to_wait_event(&wq_head,
> &__wq_entry, state);\
>
>          \
>                 if (condition)
>          \
>                         break;
>          \
>
>          \
>                 if (___wait_is_interruptible(state) && __int) {
>          \
>                         __ret = __int;
>          \
>                         goto __out;
>          \
>
> and the thing is, if does that "__ret = __int" case and returns
> -ERESTARTSYS, it's possible that the wakeup event has already been
> consumed,

Afaics, no.

> because we've added ourselves as an exclusive writer to the
> queue. So it _says_ it was interrupted, not woken up, and the wait got
> cancelled, but because we were an exclusive waiter, we might be the
> _only_ thing that got woken up,

And that is why ___wait_event() always checks the condition after
prepare_to_wait_event(), whatever it returns.

And. If it actually does "__ret = __int" and returns -ERESTARTSYS, then
this task was already removed from the list, so we should not worry about
the case when wake_up() comes after prepare_to_wait_event().

> And the basic point is that the return value
> from wait_event_interruptible_exclusive() seems to not really be
> reliable. You can't really use it -

see above ...

> even if it says you got
> interrupted, you still have to go back and check the condition and do
> the work, and only do interruptability handling after that.

This is exactly what ___wait_event() does. Even if prepare_to_wait_event()
says you got interrupted, it still checks the condition and returns success
if it is true.

Oleg.