linux-kernel - Re: [RFC PATCH -RT] epoll: Fix eventpoll read-lock not writer-fair in PREEMPT

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: <87v93srltf.fsf@jogness.linutronix.de>
Date:   Thu, 26 Aug 2021 22:36:04 +0206
From:   John Ogness <john.ogness@...utronix.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Frederic Weisbecker <frederic@...nel.org>
Cc:     linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mike Galbraith <efault@....de>
Subject: Re: [RFC PATCH -RT] epoll: Fix eventpoll read-lock not writer-fair in PREEMPT_RT

On 2021-08-26, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> On 2021-08-25 15:27:54 [+0200], Frederic Weisbecker wrote:
>> Hi,
>> 
>> Ok the patch is gross but at least this lets me start a discussion
>> about the issue.
>> 
>> ---
>> From d9d66d650b3dac8947a34464dd2e0b546a8c6b63 Mon Sep 17 00:00:00 2001
>> From: Frederic Weisbecker <frederic@...nel.org>
>> Date: Wed, 25 Aug 2021 14:24:54 +0200
>> Subject: [RFC PATCH -RT] epoll: Fix eventpoll read-lock not writer-fair in PREEMPT_RT
>> 
>> The eventpoll lock has been converted to an rwlock some time ago with:
>> 
>> 	a218cc491420 (epoll: use rwlock in order to reduce ep_poll
>> 					callback() contention)
>> 
>> Unfortunately this can result in scenarios where a high priority caller
>> of epoll_wait() need to wait for the completion of lower priority wakers.
>> 
>> The typical scenario is:
>> 
>> 1) epoll_wait() waits and sleeps for new events in the ep_poll() loop.
>> 
>> 2) new events arrive in ep_poll_callback(), the waiter is awaken while
>>    ep->lock is read-acquired.
>> 
>> 3) The high priority waiter preempts the waker but it can't acquire the
>>    write lock in epoll_wait() so it blocks waiting for the low prio waker
>>    without priority inheritance.
>> 
>> I guess making readlock writer fair is still not the plan so all I can
>> propose is to make that rwlock build-conditional.
>
> It is writer fair in a sense that once a writer attempts to acquire
> the lock no new reader are allowed in.
>
> What you want is that the writer pi-boosts each reader which is what
> is not done (multi reader boost). Long ago there was an attempt to
> make this happen (I think with rwsem) but it turned out to be
> problematic.  There was a workaround by only allowing one reader and
> doing PI as usual.

This patch is essentially forcing that exact workaround for eventpoll.

John Ogness