mirror of
https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git
synced 2026-09-09 00:08:12 +08:00
Benjamin Coddington
26289dd6d4
JIRA: https://issues.redhat.com/browse/RHEL-94440 Conflicts: on btrfs we don't have FMODE_BUF_WASYNC nor FMODE_CAN_ODIRECT yet. For ext4, we've already got FMODE_CAN_ODIRECT. For f2fs, we don't hae FMODE_BUF_RASYNC yet. commit 210a03c9d51aa0e6e6f06980116e3256da8d4c48 Author: Christian Brauner <brauner@kernel.org> Date: Thu Mar 28 13:27:24 2024 +0100 fs: claw back a few FMODE_* bits 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 files. 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 fop_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. I suspect there's a few more we can move into there and that we can also redirect a bunch of new flag suggestions that follow this pattern into the fop_flags field instead of f_mode. Link: https://lore.kernel.org/r/20240328-gewendet-spargel-aa60a030ef74@brauner Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>