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

2024-05-05 Thread Linus Torvalds
On Sun, 5 May 2024 at 13:02, David Laight 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

RE: [PATCH v2] epoll: be better about file lifetimes

2024-05-05 Thread David Laight
From: Linus Torvalds > Sent: 05 May 2024 18:56 > > epoll can call out to vfs_poll() with a file pointer that may race with > the last 'fput()'. That would make f_count go down to zero, and while > the ep->mtx locking means that the resulting file pointer tear-down will > be blocked until the poll

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

2024-05-05 Thread Jens Axboe
On 5/5/24 11:55 AM, Linus Torvalds wrote: > epoll can call out to vfs_poll() with a file pointer that may race with > the last 'fput()'. That would make f_count go down to zero, and while > the ep->mtx locking means that the resulting file pointer tear-down will > be blocked until the poll

[PATCH v2] epoll: be better about file lifetimes

2024-05-05 Thread Linus Torvalds
epoll can call out to vfs_poll() with a file pointer that may race with the last 'fput()'. That would make f_count go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that f_count is already dead, and any