From: Andrew Morton <akpm@linux-foundation.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: jbaron@akamai.com, rpenyaev@suse.de, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 2/2] fs/epoll: restore waking from ep_done_scan()
Date: Mon, 5 Apr 2021 18:50:18 -0700 [thread overview]
Message-ID: <20210405185018.40d437d392863f743131fcda@linux-foundation.org> (raw)
In-Reply-To: <20210405231025.33829-3-dave@stgolabs.net>
On Mon, 5 Apr 2021 16:10:25 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote:
> 339ddb53d373 (fs/epoll: remove unnecessary wakeups of nested epoll) changed
> the userspace visible behavior of exclusive waiters blocked on a common
> epoll descriptor upon a single event becoming ready. Previously, all tasks
> doing epoll_wait would awake, and now only one is awoken, potentially causing
> missed wakeups on applications that rely on this behavior, such as Apache Qpid.
>
> While the aforementioned commit aims at having only a wakeup single path in
> ep_poll_callback (with the exceptions of epoll_ctl cases), we need to restore
> the wakeup in what was the old ep_scan_ready_list() such that the next thread
> can be awoken, in a cascading style, after the waker's corresponding ep_send_events().
>
Tricky. 339ddb53d373 was merged in December 2019. So do we backport
this fix? Could any userspace code be depending upon the
post-339ddb53d373 behaviour?
Or do we just leave the post-339ddb53d373 code as-is? Presumably the
issue is very rarely encountered, and changeing it back has its own
risks.
next prev parent reply other threads:[~2021-04-06 1:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-05 23:10 [PATCH 0/2] fs/epoll: restore user-visible behavior upon event ready Davidlohr Bueso
2021-04-05 23:10 ` [PATCH 1/2] kselftest: introduce new epoll test case Davidlohr Bueso
2021-04-05 23:10 ` [PATCH 2/2] fs/epoll: restore waking from ep_done_scan() Davidlohr Bueso
2021-04-06 1:50 ` Andrew Morton [this message]
2021-04-06 3:22 ` Davidlohr Bueso
2021-04-06 5:09 ` Andrew Morton
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=20210405185018.40d437d392863f743131fcda@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=jbaron@akamai.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rpenyaev@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.