linux-kernel - Re: [PATCH v4 1/1] eventpoll: Replace rwlock with spinlock

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: <CAHk-=wheHZRWPyNNoqXB8+ygw2PqEYjbyKQfSbYpirecg5K1Nw@mail.gmail.com>
Date: Tue, 15 Jul 2025 09:42:52 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nam Cao <namcao@...utronix.de>
Cc: Christian Brauner <brauner@...nel.org>, Xi Ruoyao <xry111@...111.site>, 
	Frederic Weisbecker <frederic@...nel.org>, Valentin Schneider <vschneid@...hat.com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, John Ogness <john.ogness@...utronix.de>, 
	K Prateek Nayak <kprateek.nayak@....com>, Clark Williams <clrkwllms@...nel.org>, 
	Steven Rostedt <rostedt@...dmis.org>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev, 
	linux-rt-users@...r.kernel.org, Joe Damato <jdamato@...tly.com>, 
	Martin Karsten <mkarsten@...terloo.ca>, Jens Axboe <axboe@...nel.dk>, stable@...r.kernel.org
Subject: Re: [PATCH v4 1/1] eventpoll: Replace rwlock with spinlock

On Tue, 15 Jul 2025 at 05:47, Nam Cao <namcao@...utronix.de> wrote:
>
>  fs/eventpoll.c | 139 +++++++++----------------------------------------
>  1 file changed, 26 insertions(+), 113 deletions(-)

Yeah, this is more like the kind of diffstat I like to see for
eventpoll. Plus it makes things fundamentally simpler.

It might be worth looking at ep_poll_callback() - the only case that
had read_lock_irqsave() - and seeing if perhaps some of the tests
inside the lock might be done optimistically, or delayed to after the
lock.

For example, the whole wakeup sequence looks like it should be done
*after* the ep->lock has been released, because it uses its own lock
(ie the

                if (sync)
                        wake_up_sync(&ep->wq);
                else
                        wake_up(&ep->wq);

thing uses the wq lock, and there is nothing that ep->lock protects
there as far as I can tell.

So I think this has some potential for _simple_ optimizations, but I'm
not sure how worth it it is.

Thanks,
          Linus