Re: sched/wait: Fix add_wait_queue() behavioral change

[Jens Axboe <axboe@kernel.dk>]

On 2/11/18 11:28 AM, Linus Torvalds wrote:
> On Sun, Feb 11, 2018 at 2:32 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>>
>> Indeed, the bug was introduced in v4.13 and the fix was included in v4.15, but
>> it's missing from v4.13 and v4.14 - not sure how I missed that.
> 
> Sadly, this would actually have been picked up automatically, except
> for this other problem:
> 
>> Fixes: ("sched/wait: Standardize internal naming of wait-queue entries")
> 
> If that had instead said
> 
>   Fixes: 50816c48997a ("sched/wait: Standardize internal naming of
> wait-queue entries")
> 
> then I think Greg's stable scripts would have noticed this even
> without any Cc: stable.
> 
> But the commit ID for the thing it fixed was only in the body of the
> email, not in that Fixes: line, so together with the lack of stable cc
> it got entirely missed.
> 
> That said, the block layer doesn't use exclusive waits very much, so
> I'm not sure how much this can trigger. So any block IO hangs don't
> sound likely to be due to this. The only exclusive waits I can find
> are:
> 
>  - regular request allocation.
> 
>    But *all* the waiters are exclusive, so this won't affect it
> 
>  - blk-mq-tag.c uses
> 
>         prepare_to_wait_exclusive(&ws->wait, ,,
> 
>    But all the _wakers_ seem to do "wake_up_all()", so again the order
> on the wait list shouldn't matter.
> 
> but maybe I'm missing something.
> 
> Regardless, that commit should be back-ported, but I do get the
> feeling that it never really ended up being something that people
> could possibly trigger in practice.

Newer kernels do use them without wake_up_all(), but then he would
not be hitting the regression here. It is possible that he's seeing
hangs that aren't at the end of the IO stack, just somewhere else.
Or it could be that it's something else entirely...

In any case, it's prudent to back port the fix to the kernels that
don't have it.

-- 
Jens Axboe