linux-kernel - Re: [PATCH v2] epoll: be better about file lifetimes

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]

Date: Sun, 5 May 2024 13:16:51 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <David.Laight@...lab.com>
Cc: "axboe@...nel.dk" <axboe@...nel.dk>, "brauner@...nel.org" <brauner@...nel.org>, 
	"christian.koenig@....com" <christian.koenig@....com>, 
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, 
	"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>, "jack@...e.cz" <jack@...e.cz>, 
	"keescook@...omium.org" <keescook@...omium.org>, "laura@...bott.name" <laura@...bott.name>, 
	"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>, 
	"minhquangbui99@...il.com" <minhquangbui99@...il.com>, 
	"sumit.semwal@...aro.org" <sumit.semwal@...aro.org>, 
	"syzbot+045b454ab35fd82a35fb@...kaller.appspotmail.com" <syzbot+045b454ab35fd82a35fb@...kaller.appspotmail.com>, 
	"syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>, 
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v2] epoll: be better about file lifetimes

On Sun, 5 May 2024 at 13:02, David Laight <David.Laight@...lab.com> wrote:
>
> How much is the extra pair of atomics going to hurt performance?
> IIRC a lot of work was done to (try to) make epoll lockless.

If this makes people walk away from epoll, that would be absolutely
*lovely*. Maybe they'd start using io_uring instead, which has had its
problems, but is a lot more capable in the end.

Yes, doing things right is likely more expensive than doing things
wrong. Bugs are cheap. That doesn't make buggy code better.

Epoll really isn't important enough to screw over the VFS subsystem over.

I did point out elsewhere how this could be fixed by epoll() removing
the ep items at a different point:

  https://lore.kernel.org/all/CAHk-=wj6XL9MGCd_nUzRj6SaKeN0TsyTTZDFpGdW34R+zMZaSg@mail.gmail.com/

so if somebody actually wants to fix up epoll properly, that would
probably be great.

In fact, that model would allow epoll() to just keep a proper refcount
as an fd is added to the poll events, and would probably fix a lot of
nastiness. Right now those ep items stay around for basically random
amounts of time.

But maybe there are other ways to fix it. I don't think we have an
actual eventpoll maintainer any more, but what I'm *not* willing to
happen is eventpoll messing up other parts of the kernel. It was
always a ugly performance hack, and was only acceptable as such. "ugly
hack" is ok. "buggy ugly hack" is not.

              Linus