[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whULchE1i5LA2Fa=ZndSAzPXGWh_e5+a=YV3qT1BEST7w@mail.gmail.com>
Date: Fri, 3 May 2024 16:16:15 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: keescook@...omium.org, axboe@...nel.dk, brauner@...nel.org,
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 Fri, 3 May 2024 at 15:07, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Suppose your program calls select() on a pipe and dmabuf, sees data to be read
> from pipe, reads it, closes both pipe and dmabuf and exits.
>
> Would you expect that dmabuf file would stick around for hell knows how long
> after that? I would certainly be very surprised by running into that...
Why?
That's the _point_ of refcounts. They make the thing they refcount
stay around until it's no longer referenced.
Now, I agree that dmabuf's are a bit odd in how they use a 'struct
file' *as* their refcount, but hey, it's a specialty use. Unusual
perhaps, but not exactly wrong.
I suspect that if you saw a dmabuf just have its own 'refcount_t' and
stay around until it was done, you wouldn't bat an eye at it, and it's
really just the "it uses a struct file for counting" that you are
reacting to.
Linus
Powered by blists - more mailing lists