From: Dave Chinner <david@fromorbit.com>
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>,
Alexander Viro <viro@zeniv.linux.org.uk>,
io-uring@vger.kernel.org
Subject: Re: [PATCH] [RFC]: fs: claw back a few FMODE_* bits
Date: Thu, 28 Mar 2024 12:18:06 +1100 [thread overview]
Message-ID: <ZgTFTu8byn0fg9Ld@dread.disaster.area> (raw)
In-Reply-To: <20240327-begibt-wacht-b9b9f4d1145a@brauner>
On Wed, Mar 27, 2024 at 05:45:09PM +0100, Christian Brauner wrote:
> There's a bunch of flags that are purely based on what the file
> operations support while also never being conditionally set or unset.
> IOW, they're not subject to change for individual file opens. Imho, such
> flags don't need to live in f_mode they might as well live in the fops
> structs itself. And the fops struct already has that lonely
> mmap_supported_flags member. We might as well turn that into a generic
> fops_flags member and move a few flags from FMODE_* space into FOP_*
> space. That gets us four FMODE_* bits back and the ability for new
> static flags that are about file ops to not have to live in FMODE_*
> space but in their own FOP_* space. It's not the most beautiful thing
> ever but it gets the job done. Yes, there'll be an additional pointer
> chase but hopefully that won't matter for these flags.
>
> If this is palatable I suspect there's a few more we can move into there
> and that we can also redirect new flag suggestions that follow this
> pattern into the fops_flags field instead of f_mode. As of yet untested.
>
> (Fwiw, FMODE_NOACCOUNT and FMODE_BACKING could live in fops_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.)
>
> Signed-off-by: Christian Brauner <brauner@kernel.org>
.....
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 632653e00906..d13e21eb9a3c 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1230,8 +1230,7 @@ xfs_file_open(
> {
> if (xfs_is_shutdown(XFS_M(inode->i_sb)))
> return -EIO;
> - file->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC | FMODE_BUF_WASYNC |
> - FMODE_DIO_PARALLEL_WRITE | FMODE_CAN_ODIRECT;
> + file->f_mode |= FMODE_NOWAIT | FMODE_CAN_ODIRECT;
> return generic_file_open(inode, file);
> }
>
> @@ -1490,7 +1489,6 @@ const struct file_operations xfs_file_operations = {
> .compat_ioctl = xfs_file_compat_ioctl,
> #endif
> .mmap = xfs_file_mmap,
> - .mmap_supported_flags = MAP_SYNC,
> .open = xfs_file_open,
> .release = xfs_file_release,
> .fsync = xfs_file_fsync,
> @@ -1498,6 +1496,8 @@ const struct file_operations xfs_file_operations = {
> .fallocate = xfs_file_fallocate,
> .fadvise = xfs_file_fadvise,
> .remap_file_range = xfs_file_remap_range,
> + .fops_flags = FOP_MMAP_SYNC | FOP_BUF_RASYNC | FOP_BUF_WASYNC |
> + FOP_DIO_PARALLEL_WRITE,
> };
>
> const struct file_operations xfs_dir_file_operations = {
> @@ -1510,4 +1510,6 @@ const struct file_operations xfs_dir_file_operations = {
> .compat_ioctl = xfs_file_compat_ioctl,
> #endif
> .fsync = xfs_dir_fsync,
> + .fops_flags = FOP_MMAP_SYNC | FOP_BUF_RASYNC | FOP_BUF_WASYNC |
> + FOP_DIO_PARALLEL_WRITE,
> };
Why do we need to set any of these for directory operations now that
we have a clear choice? i.e. we can't mmap directories, and the rest
of these flags are for read() and write() operations which we also
can't do on directories...
....
> @@ -1024,7 +1024,7 @@ int io_write(struct io_kiocb *req, unsigned int issue_flags)
>
> /* File path supports NOWAIT for non-direct_IO only for block devices. */
> if (!(kiocb->ki_flags & IOCB_DIRECT) &&
> - !(kiocb->ki_filp->f_mode & FMODE_BUF_WASYNC) &&
> + !fops_buf_wasync(kiocb->ki_filp) &&
> (req->flags & REQ_F_ISREG))
> goto copy_iov;
You should probably also fix that comment - WASYNC is set when the
filesystem supports NOWAIT for buffered writes.
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2024-03-28 1:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 16:45 [PATCH] [RFC]: fs: claw back a few FMODE_* bits Christian Brauner
2024-03-27 17:19 ` Jens Axboe
2024-03-28 9:40 ` Christian Brauner
2024-03-28 1:18 ` Dave Chinner [this message]
2024-03-28 5:36 ` Christoph Hellwig
2024-03-28 8:06 ` Christian Brauner
2024-03-28 8:13 ` Christoph Hellwig
2024-03-28 9:41 ` Christian Brauner
2024-04-01 23:16 ` Dave Chinner
2024-03-28 5:35 ` Christoph Hellwig
2024-03-28 9:29 ` 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=ZgTFTu8byn0fg9Ld@dread.disaster.area \
--to=david@fromorbit.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.