From: "Arve Hjønnevåg" <arve@android.com>
To: Eric Wong <normalperson@yhbt.net>
Cc: NeilBrown <neilb@suse.de>, "Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org,
Davide Libenzi <davidel@xmailserver.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: epoll: possible bug from wakeup_source activation
Date: Thu, 7 Mar 2013 20:56:49 -0800 [thread overview]
Message-ID: <CAMP5Xgdsam2DGLshL5Uu5Q4La_nAq=u1YRNBwAxDstgCvJiqfw@mail.gmail.com> (raw)
In-Reply-To: <20130308013027.GA31830@dcvr.yhbt.net>
On Thu, Mar 7, 2013 at 5:30 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>> Hi Arve, looking at commit 4d7e30d98939a0340022ccd49325a3d70f7e0238
>> (epoll: Add a flag, EPOLLWAKEUP, to prevent suspend ...)
>>
>> I think the reason for using ep->ws instead of epi->ws in the unlikely
>> ovflist case applies to the likely rdllist case, too. Since epi->ws is
>> only protected by ep->mtx, it can also be deactivated while inside
>> ep_poll_callback.
>>
>> So something like the following patch might be necessary
>> (shown here with extra context):
>>
>> --- a/fs/eventpoll.c
>> +++ b/fs/eventpoll.c
>> @@ -968,39 +968,45 @@ static int ep_poll_callback(wait_queue_t *wait, unsigned mode, int sync, void *k
>> if (unlikely(ep->ovflist != EP_UNACTIVE_PTR)) {
>> if (epi->next == EP_UNACTIVE_PTR) {
>> epi->next = ep->ovflist;
>> ep->ovflist = epi;
>> if (epi->ws) {
>> /*
>> * Activate ep->ws since epi->ws may get
>> * deactivated at any time.
>> */
>> __pm_stay_awake(ep->ws);
>> }
>>
>> }
>
> Thinking about this more, it looks like the original ep->ovflist case of
> using ep->ws is unnecessary.
>
> ep->ovflist != EP_UNACTIVE_PTR can only happen while ep->mtx is held (in
> ep_scan_ready_list); which means ep_modify+friends cannot remove epi->ws.
>
The callback function in ep_scan_ready_list can call __pm_relax on it though.
> ep_poll_callback holding ep->lock means ep_poll_callback prevents
> ep_scan_ready_list from setting ep->ovflist = EP_UNACTIVE_PTR and
> releasing ep->mtx.
This code is reached when ep_scan_ready_list has set ep->ovflist to
NULL before releasing ep->lock. Since the callback function can call
__pm_relax on epi->ws without holding ep->lock we call __pm_stay_awake
in ep->ws here (the callback does not call __pm_relax on that).
>
>> goto out_unlock;
>> }
>>
>> /* If this file is already in the ready list we exit soon */
>> if (!ep_is_linked(&epi->rdllink)) {
>> list_add_tail(&epi->rdllink, &ep->rdllist);
>> - __pm_stay_awake(epi->ws);
>> + if (epi->ws) {
>> + /*
>> + * Activate ep->ws since epi->ws may get
>> + * deactivated at any time.
>> + */
>> + __pm_stay_awake(ep->ws);
>> + }
>> }
>
> I still think ep->ws needs to be used in the common ep->rdllist case.
ep_scan_ready_list calls __pm_relax on ep->ws when it is done, so this
will not work. ep->ws is not a "ep->rdllist not empty wakeup_source is
is a "ep_scan_ready_list is running" wakeup_source.
--
Arve Hjønnevåg
next prev parent reply other threads:[~2013-03-08 4:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 11:26 epoll: possible bug from wakeup_source activation Eric Wong
2013-03-08 1:30 ` Eric Wong
2013-03-08 4:56 ` Arve Hjønnevåg [this message]
2013-03-08 20:49 ` Eric Wong
2013-03-09 4:09 ` Arve Hjønnevåg
2013-03-09 7:10 ` Eric Wong
2013-03-10 1:11 ` Eric Wong
2013-03-10 4:59 ` Eric Dumazet
2013-03-10 11:50 ` [PATCH] epoll: use RCU protect wakeup_source in epitem Eric Wong
2013-03-14 3:09 ` [PATCH mm] epoll: lock ep->mtx in ep_free to silence lockdep Eric Wong
2013-03-11 23:37 ` epoll: possible bug from wakeup_source activation Arve Hjønnevåg
2013-03-12 0:17 ` Eric Wong
2013-03-12 0:29 ` Arve Hjønnevåg
2013-03-12 0:44 ` Eric Wong
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='CAMP5Xgdsam2DGLshL5Uu5Q4La_nAq=u1YRNBwAxDstgCvJiqfw@mail.gmail.com' \
--to=arve@android.com \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=normalperson@yhbt.net \
--cc=rjw@sisk.pl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).