From: Al Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>,
Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Dave Chinner <david@fromorbit.com>,
io-uring@vger.kernel.org
Subject: Re: [PATCH v2] fs: claw back a few FMODE_* bits
Date: Thu, 4 Apr 2024 01:18:23 +0100 [thread overview]
Message-ID: <20240404001823.GP538574@ZenIV> (raw)
In-Reply-To: <20240328-gewendet-spargel-aa60a030ef74@brauner>
On Thu, Mar 28, 2024 at 01:27:24PM +0100, Christian Brauner wrote:
> (Fwiw, FMODE_NOACCOUNT and FMODE_BACKING could live in fop_flags as
> well because they're also completely static but they aren't really
> about file operations so they're better suited for FMODE_* imho.)
????
FMODE_BACKING is set for files opened by e.g. overlayfs in the underlying
layers. They bloody well can share file_operations with the files opened
in the same underlying filesystem the usual way - you wouldn't be able
to store that in file_operations, simply because the instances with
identical ->f_op might differ in that flag.
The same goes for FMODE_NOACCOUNT - kernel_file_open() vs. open(2)
can easily yield struct file instances that differ in that flag, but
have the same ->f_op.
next prev parent reply other threads:[~2024-04-04 0:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 12:27 [PATCH v2] fs: claw back a few FMODE_* bits Christian Brauner
2024-03-28 13:08 ` Christoph Hellwig
2024-04-02 10:51 ` Jan Kara
2024-04-02 12:59 ` Jens Axboe
2024-04-03 21:12 ` Mark Brown
2024-04-04 9:12 ` Jan Kara
2024-04-04 11:43 ` Mark Brown
2024-04-05 10:27 ` Christian Brauner
2024-04-05 11:12 ` Mark Brown
2024-04-04 0:18 ` Al Viro [this message]
2024-04-05 10:06 ` Christian Brauner
2024-04-06 6:10 ` Al Viro
2024-04-06 6:16 ` Al Viro
2024-04-09 9:12 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240404001823.GP538574@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.