lkml.org 
[lkml]   [2024]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2] epoll: be better about file lifetimes
From
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 returns, it means that f_count is already
> dead, and any use of it won't actually get a reference to the file any
> more: it's dead regardless.
>
> Make sure we have a valid ref on the file pointer before we call down to
> vfs_poll() from the epoll routines.
>
> Link: https://lore.kernel.org/lkml/0000000000002d631f0615918f1e@google.com/
> Reported-by: syzbot+045b454ab35fd82a35fb@syzkaller.appspotmail.com
> Reviewed-by: Jens Axboe <axboe@kernel.dk>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>
> Changes since v1:
>
> - add Link, Reported-by, and Jens' reviewed-by. And sign off on it
> because it looks fine to me and we have some testing now.
>
> - move epi_fget() closer to the user
>
> - more comments about the background
>
> - remove the rcu_read_lock(), with the comment explaining why it's not
> needed
>
> - note about returning zero rather than something like EPOLLERR|POLLHUP
> for a file that is going away

I did look at that 0 return as well and agreed this is the right choice,
but adding the comment is a good idea.

Anyway, patch still looks fine to me. I'd word wrap the comment section
above epi_fget() wider, but that's just a stylistic choice...

--
Jens Axboe


\
 
 \ /
  Last update: 2024-05-27 18:16    [W:0.200 / U:3.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site