linux-kernel - Re: [PATCH] eventpoll: fix missing wakeup for ovflist in ep_poll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200423203159.c9fc9988649e08d59e13e64d@linux-foundation.org>
Date:   Thu, 23 Apr 2020 20:31:59 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Khazhismel Kumykov <khazhy@...gle.com>
Cc:     viro@...iv.linux.org.uk, rpenyaev@...e.de, r@....cc,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jason Baron <jbaron@...mai.com>
Subject: Re: [PATCH] eventpoll: fix missing wakeup for ovflist in
 ep_poll_callback

On Thu, 23 Apr 2020 19:50:57 -0700 Khazhismel Kumykov <khazhy@...gle.com> wrote:

> In the event that we add to ovflist, before 339ddb53d373 we would be
> woken up by ep_scan_ready_list, and did no wakeup in ep_poll_callback.
> With that wakeup removed, if we add to ovflist here, we may never wake
> up. Rather than adding back the ep_scan_ready_list wakeup - which was
> resulting un uncessary wakeups, trigger a wake-up in ep_poll_callback.
> 
> We noticed that one of our workloads was missing wakeups starting with
> 339ddb53d373 and upon manual inspection, this wakeup seemed missing to
> me. With this patch added, we no longer see missing wakeups. I haven't
> yet tried to make a small reproducer, but the existing kselftests in
> filesystem/epoll passed for me with this patch.

I'm no longer familiar with this code, so I'll await input from others.

> Fixes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll")
> Signed-off-by: Khazhismel Kumykov <khazhy@...gle.com>

However it sounds like a cc:stable would be warranted here, so that
earlier affected kernels get the fix?