Splits the handling of FS_IOC_[GS]ETFLAGS from ->ioctl() into
a separate method. The interface is reasonably uniform across the
filesystems that support it and gives nice boilerplate removal.
The branch is straight from Miklos' tree (it's #fileattr_v6 there),
sat merged into vfs.git #for-next for a while. Not sure what's the normal
way to do pull requests in situations like that - do you prefer a reference
to my tree (as below) or to mszeredi/vfs.git?
The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:
Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git miklos.fileattr
for you to fetch changes up to c4fe8aef2f07c8a41169bcb2c925f6a3a6818ca3:
ovl: remove unneeded ioctls (2021-04-12 15:04:30 +0200)
----------------------------------------------------------------
Miklos Szeredi (23):
vfs: add fileattr ops
ecryptfs: stack fileattr ops
ovl: stack fileattr ops
btrfs: convert to fileattr
ext2: convert to fileattr
ext4: convert to fileattr
f2fs: convert to fileattr
gfs2: convert to fileattr
orangefs: convert to fileattr
xfs: convert to fileattr
efivars: convert to fileattr
hfsplus: convert to fileattr
jfs: convert to fileattr
nilfs2: convert to fileattr
ocfs2: convert to fileattr
reiserfs: convert to fileattr
ubifs: convert to fileattr
vfs: remove unused ioctl helpers
fuse: move ioctl to separate source file
fuse: unsigned open flags
fuse: add internal open/release helpers
fuse: convert to fileattr
ovl: remove unneeded ioctls
Documentation/filesystems/locking.rst | 11 +-
Documentation/filesystems/vfs.rst | 15 ++
fs/btrfs/ctree.h | 3 +
fs/btrfs/inode.c | 4 +
fs/btrfs/ioctl.c | 226 +++-------------
fs/ecryptfs/inode.c | 22 ++
fs/efivarfs/file.c | 77 ------
fs/efivarfs/inode.c | 44 +++
fs/ext2/ext2.h | 7 +-
fs/ext2/file.c | 2 +
fs/ext2/ioctl.c | 88 +++---
fs/ext2/namei.c | 2 +
fs/ext4/ext4.h | 12 +-
fs/ext4/file.c | 2 +
fs/ext4/ioctl.c | 208 +++------------
fs/ext4/namei.c | 2 +
fs/f2fs/f2fs.h | 3 +
fs/f2fs/file.c | 216 +++------------
fs/f2fs/namei.c | 2 +
fs/fuse/Makefile | 2 +-
fs/fuse/dir.c | 6 +-
fs/fuse/file.c | 435 +++---------------------------
fs/fuse/fuse_i.h | 40 ++-
fs/fuse/ioctl.c | 490 ++++++++++++++++++++++++++++++++++
fs/gfs2/file.c | 63 ++---
fs/gfs2/inode.c | 4 +
fs/gfs2/inode.h | 3 +
fs/hfsplus/dir.c | 2 +
fs/hfsplus/hfsplus_fs.h | 14 +-
fs/hfsplus/inode.c | 54 ++++
fs/hfsplus/ioctl.c | 84 ------
fs/inode.c | 87 ------
fs/ioctl.c | 325 ++++++++++++++++++++++
fs/jfs/file.c | 6 +-
fs/jfs/ioctl.c | 111 +++-----
fs/jfs/jfs_dinode.h | 7 -
fs/jfs/jfs_inode.h | 4 +-
fs/jfs/namei.c | 6 +-
fs/nilfs2/file.c | 2 +
fs/nilfs2/ioctl.c | 61 ++---
fs/nilfs2/namei.c | 2 +
fs/nilfs2/nilfs.h | 3 +
fs/ocfs2/file.c | 2 +
fs/ocfs2/ioctl.c | 59 ++--
fs/ocfs2/ioctl.h | 3 +
fs/ocfs2/namei.c | 3 +
fs/ocfs2/ocfs2_ioctl.h | 8 -
fs/orangefs/file.c | 79 ------
fs/orangefs/inode.c | 50 ++++
fs/overlayfs/dir.c | 2 +
fs/overlayfs/file.c | 110 --------
fs/overlayfs/inode.c | 77 ++++++
fs/overlayfs/overlayfs.h | 5 +-
fs/overlayfs/readdir.c | 4 -
fs/reiserfs/file.c | 2 +
fs/reiserfs/ioctl.c | 121 ++++-----
fs/reiserfs/namei.c | 2 +
fs/reiserfs/reiserfs.h | 7 +-
fs/reiserfs/super.c | 2 +-
fs/ubifs/dir.c | 2 +
fs/ubifs/file.c | 2 +
fs/ubifs/ioctl.c | 78 +++---
fs/ubifs/ubifs.h | 3 +
fs/xfs/libxfs/xfs_fs.h | 4 -
fs/xfs/xfs_ioctl.c | 258 +++++-------------
fs/xfs/xfs_ioctl.h | 11 +
fs/xfs/xfs_ioctl32.c | 2 -
fs/xfs/xfs_ioctl32.h | 2 -
fs/xfs/xfs_iops.c | 7 +
include/linux/fileattr.h | 59 ++++
include/linux/fs.h | 16 +-
71 files changed, 1727 insertions(+), 2010 deletions(-)
create mode 100644 fs/fuse/ioctl.c
create mode 100644 include/linux/fileattr.h
On Mon, Apr 26, 2021 at 3:42 PM Al Viro <[email protected]> wrote:
>
> The branch is straight from Miklos' tree (it's #fileattr_v6 there),
> sat merged into vfs.git #for-next for a while. Not sure what's the normal
> way to do pull requests in situations like that - do you prefer a reference
> to my tree (as below) or to mszeredi/vfs.git?
This is fine. The only downside here is that there was no signed tag,
which I would have preferred - either from you or from Milkos.
We've had this a couple of times before, and I've started trying to
"document" it with a "Pull X from Y via Z" thing. See for example
git show 836d7f0572ca 70cd33d34c60
which is a similar kind of thing where Borislav just forwarded Ard's
work (and it has happened in the past a couple of times without those
kinds of notices).
Btw, unrelated to that, this pull request got a conflict with
64708539cd23 ("btrfs: use btrfs_inode_lock/btrfs_inode_unlock inode
lock helpers")
which I think I sorted out correctly (the "inode_lock()" is now done
by the VFS layer for the fileattr things, and the btrfs use of
"btrfs_inode_lock/btrfs_inode_unlock" ended up being undone). But just
to be safe I'm cc'ing the btrfs people involved. Please double-check
that I didn't screw something up.
(Note: it doesn't show up as a conflict in the merge itself, because
each piece was a straight "take the case from one side or the other",
and in this case "take it from the fileattr" side meant that the
inode_[un]lock -> btrfs_inode_[un]lock conversion for the fileattr
cases just went away).
Linus
The pull request you sent on Mon, 26 Apr 2021 22:42:19 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git miklos.fileattr
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a4f7fae10169cf626bb83e97f229ee78c71ceea8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Tue, Apr 27, 2021 at 11:31:19AM -0700, Linus Torvalds wrote:
> Btw, unrelated to that, this pull request got a conflict with
>
> 64708539cd23 ("btrfs: use btrfs_inode_lock/btrfs_inode_unlock inode
> lock helpers")
>
> which I think I sorted out correctly (the "inode_lock()" is now done
> by the VFS layer for the fileattr things, and the btrfs use of
> "btrfs_inode_lock/btrfs_inode_unlock" ended up being undone). But just
> to be safe I'm cc'ing the btrfs people involved. Please double-check
> that I didn't screw something up.
Checked, it's ok. Thanks.