[git pull] fileattr series from Miklos

[git pull] fileattr series from Miklos

[Al Viro]

	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

Re: [git pull] fileattr series from Miklos

[Linus Torvalds]

On Mon, Apr 26, 2021 at 3:42 PM Al Viro <viro@zeniv.linux.org.uk> 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

Re: [git pull] fileattr series from Miklos

[pr-tracker-bot]

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

Re: [git pull] fileattr series from Miklos

[David Sterba]

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.