linux-stable.git/fs/ioctl.c, branch v5.16

Merge tag 'vfs-5.15-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux

2021-08-31T18:06:32+00:00

Pull project quota update from Darrick Wong:
 "A single VFS patch that prevents userspace from setting project quota
  ids on files that the VFS considers invalid"

* tag 'vfs-5.15-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  fs: forbid invalid project ID

fs: forbid invalid project ID

2021-08-03T16:48:04+00:00

fileattr_set_prepare() should check if project ID
is valid, otherwise dqget() will return NULL for
such project ID quota.

Signed-off-by: Wang Shilong 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong

fs: remove generic_block_fiemap

2021-07-27T09:00:36+00:00

Remove the now unused generic_block_fiemap helper.

Link: https://lore.kernel.org/r/20210720133341.405438-5-hch@lst.de
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jan Kara

vfs: add fileattr ops

2021-04-12T13:04:23+00:00

There's a substantial amount of boilerplate in filesystems handling
FS_IOC_[GS]ETFLAGS/ FS_IOC_FS[GS]ETXATTR ioctls.

Also due to userspace buffers being involved in the ioctl API this is
difficult to stack, as shown by overlayfs issues related to these ioctls.

Introduce a new internal API named "fileattr" (fsxattr can be confused with
xattr, xflags is inappropriate, since this is more than just flags).

There's significant overlap between flags and xflags and this API handles
the conversions automatically, so filesystems may choose which one to use.

In ->fileattr_get() a hint is provided to the filesystem whether flags or
xattr are being requested by userspace, but in this series this hint is
ignored by all filesystems, since generating all the attributes is cheap.

If a filesystem doesn't implemement the fileattr API, just fall back to
f_op->ioctl().  When all filesystems are converted, the fallback can be
removed.

32bit compat ioctls are now handled by the generic code as well.

Signed-off-by: Miklos Szeredi

fs: remove ksys_ioctl

2020-07-31T06:16:01+00:00

Fold it into the only remaining caller.

Signed-off-by: Christoph Hellwig 
Acked-by: Linus Torvalds

fs: remove the access_ok() check in ioctl_fiemap

2020-06-04T03:16:55+00:00

access_ok just checks we are fed a proper user pointer.  We also do that
in copy_to_user itself, so no need to do this early.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ritesh Harjani 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-9-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: handle FIEMAP_FLAG_SYNC in fiemap_prep

2020-06-04T03:16:55+00:00

By moving FIEMAP_FLAG_SYNC handling to fiemap_prep we ensure it is
handled once instead of duplicated, but can still be done under fs locks,
like xfs/iomap intended with its duplicate handling.  Also make sure the
error value of filemap_write_and_wait is propagated to user space.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Amir Goldstein 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-8-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: move fiemap range validation into the file systems instances

2020-06-04T03:16:55+00:00

Replace fiemap_check_flags with a fiemap_prep helper that also takes the
inode and mapped range, and performs the sanity check and truncation
previously done in fiemap_check_range.  This way the validation is inside
the file system itself and thus properly works for the stacked overlayfs
case as well.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Amir Goldstein 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-7-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: move the fiemap definitions out of fs.h

2020-06-04T03:16:55+00:00

No need to pull the fiemap definitions into almost every file in the
kernel build.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ritesh Harjani 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-5-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: mark __generic_block_fiemap static

2020-06-04T03:16:54+00:00

There is no caller left outside of ioctl.c.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ritesh Harjani 
Reviewed-by: Jan Kara 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-4-hch@lst.de
Signed-off-by: Theodore Ts'o