22 Jul, 2022

1 commit

  • commit 5750676b64a561f7ec920d7c6ba130fc9c7378f3 upstream.

    If dedupe of an EOF block is not constrainted to match against only
    other EOF blocks with the same EOF offset into the block, it can
    match against any other block that has the same matching initial
    bytes in it, even if the bytes beyond EOF in the source file do
    not match.

    Fix this by constraining the EOF block matching to only match
    against other EOF blocks that have identical EOF offsets and data.
    This allows "whole file dedupe" to continue to work without allowing
    eof blocks to randomly match against partial full blocks with the
    same data.

    Reported-by: Ansgar Lößer
    Fixes: 1383a7ed6749 ("vfs: check file ranges before cloning files")
    Link: https://lore.kernel.org/linux-fsdevel/a7c93559-4ba1-df2f-7a85-55a143696405@tu-darmstadt.de/
    Signed-off-by: Dave Chinner
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     

23 Aug, 2021

1 commit

  • We added CONFIG_MANDATORY_FILE_LOCKING in 2015, and soon after turned it
    off in Fedora and RHEL8. Several other distros have followed suit.

    I've heard of one problem in all that time: Someone migrated from an
    older distro that supported "-o mand" to one that didn't, and the host
    had a fstab entry with "mand" in it which broke on reboot. They didn't
    actually _use_ mandatory locking so they just removed the mount option
    and moved on.

    This patch rips out mandatory locking support wholesale from the kernel,
    along with the Kconfig option and the Documentation file. It also
    changes the mount code to ignore the "mand" mount option instead of
    erroring out, and to throw a big, ugly warning.

    Signed-off-by: Jeff Layton

    Jeff Layton
     

24 Jan, 2021

2 commits

  • Enable generic ioctls to handle idmapped mounts by passing down the
    mount's user namespace. If the initial user namespace is passed nothing
    changes so non-idmapped mounts will see identical behavior as before.

    Link: https://lore.kernel.org/r/20210121131959.646623-22-christian.brauner@ubuntu.com
    Cc: Christoph Hellwig
    Cc: David Howells
    Cc: Al Viro
    Cc: linux-fsdevel@vger.kernel.org
    Reviewed-by: Christoph Hellwig
    Reviewed-by: James Morris
    Signed-off-by: Christian Brauner

    Christian Brauner
     
  • The two helpers inode_permission() and generic_permission() are used by
    the vfs to perform basic permission checking by verifying that the
    caller is privileged over an inode. In order to handle idmapped mounts
    we extend the two helpers with an additional user namespace argument.
    On idmapped mounts the two helpers will make sure to map the inode
    according to the mount's user namespace and then peform identical
    permission checks to inode_permission() and generic_permission(). If the
    initial user namespace is passed nothing changes so non-idmapped mounts
    will see identical behavior as before.

    Link: https://lore.kernel.org/r/20210121131959.646623-6-christian.brauner@ubuntu.com
    Cc: Christoph Hellwig
    Cc: David Howells
    Cc: Al Viro
    Cc: linux-fsdevel@vger.kernel.org
    Reviewed-by: Christoph Hellwig
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: Christian Brauner

    Christian Brauner
     

14 Dec, 2020

1 commit

  • Call remap_verify_area() on the source file as well as the destination.

    When called from vfs_dedupe_file_range() the check as already been
    performed, but not so if called from layered fs (overlayfs, etc...)

    Could ommit the redundant check in vfs_dedupe_file_range(), but leave for
    now to get error early (for fear of breaking backward compatibility).

    This call shouldn't be performance sensitive.

    Signed-off-by: Miklos Szeredi

    Miklos Szeredi
     

16 Oct, 2020

1 commit


15 Oct, 2020

1 commit

  • I would like to move all the generic helpers for the vfs remap range
    functionality (aka clonerange and dedupe) into a separate file so that
    they won't be scattered across the vfs and the mm subsystems. The
    eventual goal is to be able to deselect remap_range.c if none of the
    filesystems need that code, but the tricky part here is picking a
    stable(ish) part of the merge window to rearrange code.

    Signed-off-by: Darrick J. Wong

    Darrick J. Wong