From: Jens Axboe <axboe@kernel.dk>
To: Sasha Levin <sashal@kernel.org>, gregkh@linuxfoundation.org
Cc: stable@vger.kernel.org
Subject: Re: FAILED: patch "[PATCH] io_uring: prevent potential eventfd recursion on poll" failed to apply to 5.5-stable tree
Date: Mon, 10 Feb 2020 20:37:10 -0700 [thread overview]
Message-ID: <d0de57b7-036e-bb24-f01f-4e9ff1284800@kernel.dk> (raw)
In-Reply-To: <20200209183345.GP3584@sasha-vm>
On 2/9/20 11:33 AM, Sasha Levin wrote:
> On Sun, Feb 09, 2020 at 12:52:51PM +0100, gregkh@linuxfoundation.org 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@vger.kernel.org>.
>>
>> thanks,
>>
>> greg k-h
>>
>> ------------------ original commit in Linus's tree ------------------
>>
>>From f0b493e6b9a8959356983f57112229e69c2f7b8c Mon Sep 17 00:00:00 2001
>> From: Jens Axboe <axboe@kernel.dk>
>> 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@vger.kernel.org # 5.1+
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
> 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
prev parent reply other threads:[~2020-02-11 3:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 11:52 FAILED: patch "[PATCH] io_uring: prevent potential eventfd recursion on poll" failed to apply to 5.5-stable tree gregkh
2020-02-09 18:33 ` Sasha Levin
2020-02-11 3:37 ` Jens Axboe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0de57b7-036e-bb24-f01f-4e9ff1284800@kernel.dk \
--to=axboe@kernel.dk \
--cc=gregkh@linuxfoundation.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox