1. 15 Mar, 2018 1 commit
    • Eric W. Biederman's avatar
      fs: Teach path_connected to handle nfs filesystems with multiple roots. · 95dd7758
      Eric W. Biederman authored
      On nfsv2 and nfsv3 the nfs server can export subsets of the same
      filesystem and report the same filesystem identifier, so that the nfs
      client can know they are the same filesystem.  The subsets can be from
      disjoint directory trees.  The nfsv2 and nfsv3 filesystems provides no
      way to find the common root of all directory trees exported form the
      server with the same filesystem identifier.
      The practical result is that in struct super s_root for nfs s_root is
      not necessarily the root of the filesystem.  The nfs mount code sets
      s_root to the root of the first subset of the nfs filesystem that the
      kernel mounts.
      This effects the dcache invalidation code in generic_shutdown_super
      currently called shrunk_dcache_for_umount and that code for years
      has gone through an additional list of dentries that might be dentry
      trees that need to be freed to accomodate nfs.
      When I wrote path_connected I did not realize nfs was so special, and
      it's hueristic for avoiding calling is_subdir can fail.
      The practical case where this fails is when there is a move of a
      directory from the subtree exposed by one nfs mount to the subtree
      exposed by another nfs mount.  This move can happen either locally or
      remotely.  With the remote case requiring that the move directory be cached
      before the move and that after the move someone walks the path
      to where the move directory now exists and in so doing causes the
      already cached directory to be moved in the dcache through the magic
      of d_splice_alias.
      If someone whose working directory is in the move directory or a
      subdirectory and now starts calling .. from the initial mount of nfs
      (where s_root == mnt_root), then path_connected as a heuristic will
      not bother with the is_subdir check.  As s_root really is not the root
      of the nfs filesystem this heuristic is wrong, and the path may
      actually not be connected and path_connected can fail.
      The is_subdir function might be cheap enough that we can call it
      unconditionally.  Verifying that will take some benchmarking and
      the result may not be the same on all kernels this fix needs
      to be backported to.  So I am avoiding that for now.
      Filesystems with snapshots such as nilfs and btrfs do something
      similar.  But as the directory tree of the snapshots are disjoint
      from one another and from the main directory tree rename won't move
      things between them and this problem will not occur.
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Fixes: 397d425d
       ("vfs: Test for and handle paths that are unreachable from their mnt_root")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  2. 27 Nov, 2017 1 commit
    • Linus Torvalds's avatar
      Rename superblock flags (MS_xyz -> SB_xyz) · 1751e8a6
      Linus Torvalds authored
      This is a pure automated search-and-replace of the internal kernel
      superblock flags.
      The s_flags are now called SB_*, with the names and the values for the
      moment mirroring the MS_* flags that they're equivalent to.
      Note how the MS_xyz flags are the ones passed to the mount system call,
      while the SB_xyz flags are what we then use in sb->s_flags.
      The script to do this was:
          # places to look in; re security/*: it generally should *not* be
          # touched (that stuff parses mount(2) arguments directly), but
          # there are two places where we really deal with superblock flags.
          FILES="drivers/mtd drivers/staging/lustre fs ipc mm \
                  include/linux/fs.h include/uapi/linux/bfs_fs.h \
                  security/apparmor/apparmorfs.c security/apparmor/include/lib.h"
          # the list of MS_... constants
                ACTIVE NOUSER"
          for i in $SYMS; do SED_PROG="$SED_PROG -e s/MS_$i/SB_$i/g"; done
          # we want files that contain at least one of MS_...,
          # with fs/namespace.c and fs/pnode.c excluded.
          L=$(for i in $SYMS; do git grep -w -l MS_$i $FILES; done| sort|uniq|grep -v '^fs/namespace.c'|grep -v '^fs/pnode.c')
          for f in $L; do sed -i $f $SED_PROG; done
      Requested-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 17 Nov, 2017 2 commits
  4. 20 Aug, 2017 1 commit
    • Chuck Lever's avatar
      NFS: Fix NFSv2 security settings · 53a75f22
      Chuck Lever authored
      For a while now any NFSv2 mount where sec= is specified uses
      AUTH_NULL. If sec= is not specified, the mount uses AUTH_UNIX.
      Commit e68fd7c8 ("mount: use sec= that was specified on the
      command line") attempted to address a very similar problem with
      NFSv3, and should have fixed this too, but it has a bug.
      The MNTv1 MNT procedure does not return a list of security flavors,
      so our client makes up a list containing just AUTH_NULL. This should
      enable nfs_verify_authflavors() to assign the sec= specified flavor,
      but instead, it incorrectly sets it to AUTH_NULL.
      I expect this would also be a problem for any NFSv3 server whose
      MNTv3 MNT procedure returned a security flavor list containing only
      Fixes: e68fd7c8 ("mount: use sec= that was specified on ... ")
      BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=310
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
  5. 17 Jul, 2017 1 commit
    • David Howells's avatar
      VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb) · bc98a42c
      David Howells authored
      Firstly by applying the following with coccinelle's spatch:
      	@@ expression SB; @@
      	-SB->s_flags & MS_RDONLY
      to effect the conversion to sb_rdonly(sb), then by applying:
      	@@ expression A, SB; @@
      	-(!sb_rdonly(SB)) && A
      	+!sb_rdonly(SB) && A
      	-A != (sb_rdonly(SB))
      	+A != sb_rdonly(SB)
      	-A == (sb_rdonly(SB))
      	+A == sb_rdonly(SB)
      	-A && (sb_rdonly(SB))
      	+A && sb_rdonly(SB)
      	-A || (sb_rdonly(SB))
      	+A || sb_rdonly(SB)
      	-(sb_rdonly(SB)) != A
      	+sb_rdonly(SB) != A
      	-(sb_rdonly(SB)) == A
      	+sb_rdonly(SB) == A
      	-(sb_rdonly(SB)) && A
      	+sb_rdonly(SB) && A
      	-(sb_rdonly(SB)) || A
      	+sb_rdonly(SB) || A
      	@@ expression A, B, SB; @@
      	-(sb_rdonly(SB)) ? 1 : 0
      	-(sb_rdonly(SB)) ? A : B
      	+sb_rdonly(SB) ? A : B
      to remove left over excess bracketage and finally by applying:
      	@@ expression A, SB; @@
      	-(A & MS_RDONLY) != sb_rdonly(SB)
      	+(bool)(A & MS_RDONLY) != sb_rdonly(SB)
      	-(A & MS_RDONLY) == sb_rdonly(SB)
      	+(bool)(A & MS_RDONLY) == sb_rdonly(SB)
      to make comparisons against the result of sb_rdonly() (which is a bool)
      work correctly.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  6. 13 Jul, 2017 3 commits
  7. 09 Jun, 2017 1 commit
    • Scott Mayhew's avatar
      security/selinux: allow security_sb_clone_mnt_opts to enable/disable native labeling behavior · 0b4d3452
      Scott Mayhew authored
      When an NFSv4 client performs a mount operation, it first mounts the
      NFSv4 root and then does path walk to the exported path and performs a
      submount on that, cloning the security mount options from the root's
      superblock to the submount's superblock in the process.
      Unless the NFS server has an explicit fsid=0 export with the
      "security_label" option, the NFSv4 root superblock will not have
      SBLABEL_MNT set, and neither will the submount superblock after cloning
      the security mount options.  As a result, setxattr's of security labels
      over NFSv4.2 will fail.  In a similar fashion, NFSv4.2 mounts mounted
      with the context= mount option will not show the correct labels because
      the nfs_server->caps flags of the cloned superblock will still have
      Allowing the NFSv4 client to enable or disable SECURITY_LSM_NATIVE_LABELS
      behavior will ensure that the SBLABEL_MNT flag has the correct value
      when the client traverses from an exported path without the
      "security_label" option to one with the "security_label" option and
      vice versa.  Similarly, checking to see if SECURITY_LSM_NATIVE_LABELS is
      set upon return from security_sb_clone_mnt_opts() and clearing
      NFS_CAP_SECURITY_LABEL if necessary will allow the correct labels to
      be displayed for NFSv4.2 mounts mounted with the context= mount option.
      Resolves: https://github.com/SELinuxProject/selinux-kernel/issues/35
      Signed-off-by: default avatarScott Mayhew <smayhew@redhat.com>
      Reviewed-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Tested-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
  8. 03 Jun, 2017 1 commit
  9. 04 May, 2017 1 commit
    • Jan Kara's avatar
      nfs: Fix bdi handling for cloned superblocks · 9052c7cf
      Jan Kara authored
      In commit 0d3b12584972 "nfs: Convert to separately allocated bdi" I have
      wrongly cloned bdi reference in nfs_clone_super(). Further inspection
      has shown that originally the code was actually allocating a new bdi (in
      ->clone_server callback) which was later registered in
      nfs_fs_mount_common() and used for sb->s_bdi in nfs_initialise_sb().
      This could later result in bdi for the original superblock not getting
      unregistered when that superblock got shutdown (as the cloned sb still
      held bdi reference) and later when a new superblock was created under
      the same anonymous device number, a clash in sysfs has happened on bdi
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 10284 at /linux-next/fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x74
      sysfs: cannot create duplicate filename '/devices/virtual/bdi/0:32'
      Modules linked in: axp20x_usb_power gpio_axp209 nvmem_sunxi_sid sun4i_dma sun4i_ss virt_dma
      CPU: 1 PID: 10284 Comm: mount.nfs Not tainted 4.11.0-rc4+ #14
      Hardware name: Allwinner sun7i (A20) Family
      [<c010f19c>] (unwind_backtrace) from [<c010bc74>] (show_stack+0x10/0x14)
      [<c010bc74>] (show_stack) from [<c03c6e24>] (dump_stack+0x78/0x8c)
      [<c03c6e24>] (dump_stack) from [<c0122200>] (__warn+0xe8/0x100)
      [<c0122200>] (__warn) from [<c0122250>] (warn_slowpath_fmt+0x38/0x48)
      [<c0122250>] (warn_slowpath_fmt) from [<c02ac178>] (sysfs_warn_dup+0x64/0x74)
      [<c02ac178>] (sysfs_warn_dup) from [<c02ac254>] (sysfs_create_dir_ns+0x84/0x94)
      [<c02ac254>] (sysfs_create_dir_ns) from [<c03c8b8c>] (kobject_add_internal+0x9c/0x2ec)
      [<c03c8b8c>] (kobject_add_internal) from [<c03c8e24>] (kobject_add+0x48/0x98)
      [<c03c8e24>] (kobject_add) from [<c048d75c>] (device_add+0xe4/0x5a0)
      [<c048d75c>] (device_add) from [<c048ddb4>] (device_create_groups_vargs+0xac/0xbc)
      [<c048ddb4>] (device_create_groups_vargs) from [<c048dde4>] (device_create_vargs+0x20/0x28)
      [<c048dde4>] (device_create_vargs) from [<c02075c8>] (bdi_register_va+0x44/0xfc)
      [<c02075c8>] (bdi_register_va) from [<c023d378>] (super_setup_bdi_name+0x48/0xa4)
      [<c023d378>] (super_setup_bdi_name) from [<c0312ef4>] (nfs_fill_super+0x1a4/0x204)
      [<c0312ef4>] (nfs_fill_super) from [<c03133f0>] (nfs_fs_mount_common+0x140/0x1e8)
      [<c03133f0>] (nfs_fs_mount_common) from [<c03335cc>] (nfs4_remote_mount+0x50/0x58)
      [<c03335cc>] (nfs4_remote_mount) from [<c023ef98>] (mount_fs+0x14/0xa4)
      [<c023ef98>] (mount_fs) from [<c025cba0>] (vfs_kern_mount+0x54/0x128)
      [<c025cba0>] (vfs_kern_mount) from [<c033352c>] (nfs_do_root_mount+0x80/0xa0)
      [<c033352c>] (nfs_do_root_mount) from [<c0333818>] (nfs4_try_mount+0x28/0x3c)
      [<c0333818>] (nfs4_try_mount) from [<c0313874>] (nfs_fs_mount+0x2cc/0x8c4)
      [<c0313874>] (nfs_fs_mount) from [<c023ef98>] (mount_fs+0x14/0xa4)
      [<c023ef98>] (mount_fs) from [<c025cba0>] (vfs_kern_mount+0x54/0x128)
      [<c025cba0>] (vfs_kern_mount) from [<c02600f0>] (do_mount+0x158/0xc7c)
      [<c02600f0>] (do_mount) from [<c0260f98>] (SyS_mount+0x8c/0xb4)
      [<c0260f98>] (SyS_mount) from [<c0107840>] (ret_fast_syscall+0x0/0x3c)
      Fix the problem by always creating new bdi for a superblock as we used
      to do.
      Reported-and-tested-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Fixes: 0d3b12584972ce5781179ad3f15cca3cdb5cae05
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
  10. 20 Apr, 2017 2 commits
  11. 30 Jan, 2017 1 commit
  12. 24 Dec, 2016 1 commit
  13. 01 Dec, 2016 1 commit
  14. 19 Sep, 2016 1 commit
  15. 16 Aug, 2016 1 commit
  16. 19 Jul, 2016 1 commit
  17. 17 May, 2016 1 commit
  18. 09 May, 2016 1 commit
  19. 21 Oct, 2015 1 commit
  20. 12 Aug, 2015 1 commit
  21. 28 May, 2015 1 commit
    • Luis R. Rodriguez's avatar
      kernel/params: constify struct kernel_param_ops uses · 9c27847d
      Luis R. Rodriguez authored
      Most code already uses consts for the struct kernel_param_ops,
      sweep the kernel for the last offending stragglers. Other than
      include/linux/moduleparam.h and kernel/params.c all other changes
      were generated with the following Coccinelle SmPL patch. Merge
      conflicts between trees can be handled with Coccinelle.
      In the future git could get Coccinelle merge support to deal with
      patch --> fail --> grammar --> Coccinelle --> new patch conflicts
      automatically for us on patches where the grammar is available and
      the patch is of high confidence. Consider this a feature request.
      Test compiled on x86_64 against:
      	* allnoconfig
      	* allmodconfig
      	* allyesconfig
      @ const_found @
      identifier ops;
      const struct kernel_param_ops ops = {
      @ const_not_found depends on !const_found @
      identifier ops;
      -struct kernel_param_ops ops = {
      +const struct kernel_param_ops ops = {
      Generated-by: Coccinelle SmPL
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Junio C Hamano <gitster@pobox.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: cocci@systeme.lip6.fr
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  22. 23 Apr, 2015 1 commit
  23. 15 Apr, 2015 1 commit
  24. 12 Mar, 2015 1 commit
  25. 06 Feb, 2015 1 commit
  26. 20 Jan, 2015 1 commit
  27. 12 Sep, 2014 1 commit
  28. 04 Aug, 2014 1 commit
  29. 12 Jul, 2014 1 commit
  30. 10 Jun, 2014 1 commit
  31. 29 May, 2014 1 commit
  32. 13 Mar, 2014 1 commit
    • Theodore Ts'o's avatar
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o authored
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
  33. 15 Nov, 2013 1 commit
  34. 28 Oct, 2013 3 commits