[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whrSSNYVzTHNFDNGag_xcKuv=RaQUX8+n29kkic39DRuQ@mail.gmail.com>
Date: Sat, 4 May 2024 08:53:47 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.org>
Cc: Al Viro <viro@...iv.linux.org.uk>, keescook@...omium.org, axboe@...nel.dk,
christian.koenig@....com, dri-devel@...ts.freedesktop.org,
io-uring@...r.kernel.org, jack@...e.cz, laura@...bott.name,
linaro-mm-sig@...ts.linaro.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
minhquangbui99@...il.com, sumit.semwal@...aro.org,
syzbot+045b454ab35fd82a35fb@...kaller.appspotmail.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
On Sat, 4 May 2024 at 08:40, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> And maybe it's even *only* dma-buf that does that fget() in its
> ->poll() function. Even *then* it's not a dma-buf.c bug.
They all do in the sense that they do
poll_wait
-> __pollwait
-> get_file (*boom*)
but the boom is very small because the poll_wait() will be undone by
poll_freewait(), and normally poll/select has held the file count
elevated.
Except for epoll. Which leaves those pollwait entries around until
it's done - but again will be held up on the ep->mtx before it does
so.
So everybody does some f_count games, but possibly dma-buf is the only
one that ends up expecting to hold on to the f_count for longer
periods.
Linus
Powered by blists - more mailing lists