[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjmC+coFdA_k6_JODD8_bvad=H4pn4yGREqOTm+eMB+rg@mail.gmail.com>
Date: Wed, 8 May 2024 10:14:44 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Simon Ser <contact@...rsion.fr>, Pekka Paalanen <pekka.paalanen@...labora.com>,
Christian König <ckoenig.leichtzumerken@...il.com>,
Christian Brauner <brauner@...nel.org>, 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: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about
file lifetimes
On Wed, 8 May 2024 at 09:19, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So since we already have two versions of F_DUPFD (the other being
> F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> on that existing naming pattern, and called it F_DUPFD_QUERY instead.
>
> I'm not married to the name, so if somebody hates it, feel free to
> argue otherwise.
Side note: with this patch, doing
ret = fcntl(fd1, F_DUPFD_QUERY, fd2);
will result in:
-1 (EBADF): 'fd1' is not a valid file descriptor
-1 (EINVAL): old kernel that doesn't support F_DUPFD_QUERY
0: fd2 does not refer to the same file as fd1
1: fd2 is the same 'struct file' as fd1
and it might be worth noting a couple of things here:
(a) fd2 being an invalid file descriptor does not cause EBADF, it
just causes "does not match".
(b) we *could* use more bits for more equality
IOW, it would possibly make sense to extend the 0/1 result to be
- bit #0: same file pointer
- bit #1: same path
- bit #2: same dentry
- bit #3: same inode
which are all different levels of "sameness".
Does anybody care? Do we want to extend on this "sameness"? I'm not
convinced, but it might be a good idea to document this as a possibly
future extension, ie *if* what you care about is "same file pointer",
maybe you should make sure to only look at bit #0.
Linus
Powered by blists - more mailing lists