On 2/9/20 11:33 AM, Sasha Levin wrote:
> On Sun, Feb 09, 2020 at 12:52:51PM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>>
>> The patch below does not apply to the 5.5-stable tree.
>> If someone wants it applied there, or to any other stable or longterm
>> tree, then please email the backport, including the original git commit
>> id to <stable@xxxxxxxxxxxxxxx>.
>>
>> thanks,
>>
>> greg k-h
>>
>> ------------------ original commit in Linus's tree ------------------
>>
>>From f0b493e6b9a8959356983f57112229e69c2f7b8c Mon Sep 17 00:00:00 2001
>> From: Jens Axboe <axboe@xxxxxxxxx>
>> Date: Sat, 1 Feb 2020 21:30:11 -0700
>> Subject: [PATCH] io_uring: prevent potential eventfd recursion on poll
>>
>> If we have nested or circular eventfd wakeups, then we can deadlock if
>> we run them inline from our poll waitqueue wakeup handler. It's also
>> possible to have very long chains of notifications, to the extent where
>> we could risk blowing the stack.
>>
>> Check the eventfd recursion count before calling eventfd_signal(). If
>> it's non-zero, then punt the signaling to async context. This is always
>> safe, as it takes us out-of-line in terms of stack and locking context.
>>
>> Cc: stable@xxxxxxxxxxxxxxx # 5.1+
>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>
> I queued it back to 5.5 by taking f2842ab5b72d ("io_uring: enable option
> to only trigger eventfd for async completions") and working around
> missing commit 69b3e546139a ("io_uring: change io_ring_ctx bool fields
> into bit fields"). However, 5.4 is a bit more complex than what I can
> tackle without a test suite.
>
> Jens, is there something I can run to validate io_uring on older
> kernels?
liburing has a set of regression tests, but unfortunately mostly tailored
to the current kernel, though stable should hopefully pass if we have
everything we need backported! I can try and stake a stab at the backport
too, I'll have more later in this round anyway...
--
Jens Axboe
