1. 08 Dec, 2018 1 commit
  2. 16 Feb, 2018 1 commit
  3. 01 Sep, 2017 1 commit
  4. 28 Aug, 2017 1 commit
  5. 29 Jul, 2017 7 commits
  6. 17 Mar, 2017 1 commit
    • Vaibhav Jain's avatar
      kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file() · 966fa72a
      Vaibhav Jain authored
      Recently started seeing a kernel oops when a module tries removing a
      memory mapped sysfs bin_attribute. On closer investigation the root
      cause seems to be kernfs_release_file() trying to call
      kernfs_op.release() callback that's NULL for such sysfs
      bin_attributes. The oops occurs when kernfs_release_file() is called from
      kernfs_drain_open_files() to cleanup any open handles with active
      memory mappings.
      The patch fixes this by checking for flag KERNFS_HAS_RELEASE before
      calling kernfs_release_file() in function kernfs_drain_open_files().
      On ppc64-le arch with cxl module the oops back-trace is of the
      form below:
      [  861.381126] Unable to handle kernel paging request for instruction fetch
      [  861.381360] Faulting instruction address: 0x00000000
      [  861.381428] Oops: Kernel access of bad area, sig: 11 [#1]
      [  861.382481] NIP: 0000000000000000 LR: c000000000362c60 CTR:
      Call Trace:
      [c000000f1680b750] [c000000000362c34] kernfs_drain_open_files+0x104/0x1d0 (unreliable)
      [c000000f1680b790] [c00000000035fa00] __kernfs_remove+0x260/0x2c0
      [c000000f1680b820] [c000000000360da0] kernfs_remove_by_name_ns+0x60/0xe0
      [c000000f1680b8b0] [c0000000003638f4] sysfs_remove_bin_file+0x24/0x40
      [c000000f1680b8d0] [c00000000062a164] device_remove_bin_file+0x24/0x40
      [c000000f1680b8f0] [d000000009b7b22c] cxl_sysfs_afu_remove+0x144/0x170 [cxl]
      [c000000f1680b940] [d000000009b7c7e4] cxl_remove+0x6c/0x1a0 [cxl]
      [c000000f1680b990] [c00000000052f694] pci_device_remove+0x64/0x110
      [c000000f1680b9d0] [c0000000006321d4] device_release_driver_internal+0x1f4/0x2b0
      [c000000f1680ba20] [c000000000525cb0] pci_stop_bus_device+0xa0/0xd0
      [c000000f1680ba60] [c000000000525e80] pci_stop_and_remove_bus_device+0x20/0x40
      [c000000f1680ba90] [c00000000004a6c4] pci_hp_remove_devices+0x84/0xc0
      [c000000f1680bad0] [c00000000004a688] pci_hp_remove_devices+0x48/0xc0
      [c000000f1680bb10] [c0000000009dfda4] eeh_reset_device+0xb0/0x290
      [c000000f1680bbb0] [c000000000032b4c] eeh_handle_normal_event+0x47c/0x530
      [c000000f1680bc60] [c000000000032e64] eeh_handle_event+0x174/0x350
      [c000000f1680bd10] [c000000000033228] eeh_event_handler+0x1e8/0x1f0
      [c000000f1680bdc0] [c0000000000d384c] kthread+0x14c/0x190
      [c000000f1680be30] [c00000000000b5a0] ret_from_kernel_thread+0x5c/0xbc
      Fixes: f83f3c51 ("kernfs: fix locking around kernfs_ops->release() callback")
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. 03 Mar, 2017 1 commit
    • David Howells's avatar
      statx: Add a system call to make enhanced file info available · a528d35e
      David Howells authored
      Add a system call to make extended file information available, including
      file creation and some attribute flags where available through the
      underlying filesystem.
      The getattr inode operation is altered to take two additional arguments: a
      u32 request_mask and an unsigned int flags that indicate the
      synchronisation mode.  This change is propagated to the vfs_getattr*()
      Functions like vfs_stat() are now inline wrappers around new functions
      vfs_statx() and vfs_statx_fd() to reduce stack usage.
      The idea was initially proposed as a set of xattrs that could be retrieved
      with getxattr(), but the general preference proved to be for a new syscall
      with an extended stat structure.
      A number of requests were gathered for features to be included.  The
      following have been included:
       (1) Make the fields a consistent size on all arches and make them large.
       (2) Spare space, request flags and information flags are provided for
           future expansion.
       (3) Better support for the y2038 problem [Arnd Bergmann] (tv_sec is an
       (4) Creation time: The SMB protocol carries the creation time, which could
           be exported by Samba, which will in turn help CIFS make use of
           FS-Cache as that can be used for coherency data (stx_btime).
           This is also specified in NFSv4 as a recommended attribute and could
           be exported by NFSD [Steve French].
       (5) Lightweight stat: Ask for just those details of interest, and allow a
           netfs (such as NFS) to approximate anything not of interest, possibly
           without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
           Dilger] (AT_STATX_DONT_SYNC).
       (6) Heavyweight stat: Force a netfs to go to the server, even if it thinks
           its cached attributes are up to date [Trond Myklebust]
      And the following have been left out for future extension:
       (7) Data version number: Could be used by userspace NFS servers [Aneesh
           Can also be used to modify fill_post_wcc() in NFSD which retrieves
           i_version directly, but has just called vfs_getattr().  It could get
           it from the kstat struct if it used vfs_xgetattr() instead.
           (There's disagreement on the exact semantics of a single field, since
           not all filesystems do this the same way).
       (8) BSD stat compatibility: Including more fields from the BSD stat such
           as creation time (st_btime) and inode generation number (st_gen)
           [Jeremy Allison, Bernd Schubert].
       (9) Inode generation number: Useful for FUSE and userspace NFS servers
           [Bernd Schubert].
           (This was asked for but later deemed unnecessary with the
           open-by-handle capability available and caused disagreement as to
           whether it's a security hole or not).
      (10) Extra coherency data may be useful in making backups [Andreas Dilger].
           (No particular data were offered, but things like last backup
           timestamp, the data version number and the DOS archive bit would come
           into this category).
      (11) Allow the filesystem to indicate what it can/cannot provide: A
           filesystem can now say it doesn't support a standard stat feature if
           that isn't available, so if, for instance, inode numbers or UIDs don't
           exist or are fabricated locally...
           (This requires a separate system call - I have an fsinfo() call idea
           for this).
      (12) Store a 16-byte volume ID in the superblock that can be returned in
           struct xstat [Steve French].
           (Deferred to fsinfo).
      (13) Include granularity fields in the time data to indicate the
           granularity of each of the times (NFSv4 time_delta) [Steve French].
           (Deferred to fsinfo).
      (14) FS_IOC_GETFLAGS value.  These could be translated to BSD's st_flags.
           Note that the Linux IOC flags are a mess and filesystems such as Ext4
           define flags that aren't in linux/fs.h, so translation in the kernel
           may be a necessity (or, possibly, we provide the filesystem type too).
           (Some attributes are made available in stx_attributes, but the general
           feeling was that the IOC flags were to ext[234]-specific and shouldn't
           be exposed through statx this way).
      (15) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
           Michael Kerrisk].
           (Deferred, probably to fsinfo.  Finding out if there's an ACL or
           seclabal might require extra filesystem operations).
      (16) Femtosecond-resolution timestamps [Dave Chinner].
           (A __reserved field has been left in the statx_timestamp struct for
           this - if there proves to be a need).
      (17) A set multiple attributes syscall to go with this.
      The new system call is:
      	int ret = statx(int dfd,
      			const char *filename,
      			unsigned int flags,
      			unsigned int mask,
      			struct statx *buffer);
      The dfd, filename and flags parameters indicate the file to query, in a
      similar way to fstatat().  There is no equivalent of lstat() as that can be
      emulated with statx() by passing AT_SYMLINK_NOFOLLOW in flags.  There is
      also no equivalent of fstat() as that can be emulated by passing a NULL
      filename to statx() with the fd of interest in dfd.
      Whether or not statx() synchronises the attributes with the backing store
      can be controlled by OR'ing a value into the flags argument (this typically
      only affects network filesystems):
       (1) AT_STATX_SYNC_AS_STAT tells statx() to behave as stat() does in this
       (2) AT_STATX_FORCE_SYNC will require a network filesystem to synchronise
           its attributes with the server - which might require data writeback to
           occur to get the timestamps correct.
       (3) AT_STATX_DONT_SYNC will suppress synchronisation with the server in a
           network filesystem.  The resulting values should be considered
      mask is a bitmask indicating the fields in struct statx that are of
      interest to the caller.  The user should set this to STATX_BASIC_STATS to
      get the basic set returned by stat().  It should be noted that asking for
      more information may entail extra I/O operations.
      buffer points to the destination for the data.  This must be 256 bytes in
      The following structures are defined in which to return the main attribute
      	struct statx_timestamp {
      		__s64	tv_sec;
      		__s32	tv_nsec;
      		__s32	__reserved;
      	struct statx {
      		__u32	stx_mask;
      		__u32	stx_blksize;
      		__u64	stx_attributes;
      		__u32	stx_nlink;
      		__u32	stx_uid;
      		__u32	stx_gid;
      		__u16	stx_mode;
      		__u16	__spare0[1];
      		__u64	stx_ino;
      		__u64	stx_size;
      		__u64	stx_blocks;
      		__u64	__spare1[1];
      		struct statx_timestamp	stx_atime;
      		struct statx_timestamp	stx_btime;
      		struct statx_timestamp	stx_ctime;
      		struct statx_timestamp	stx_mtime;
      		__u32	stx_rdev_major;
      		__u32	stx_rdev_minor;
      		__u32	stx_dev_major;
      		__u32	stx_dev_minor;
      		__u64	__spare2[14];
      The defined bits in request_mask and stx_mask are:
      	STATX_TYPE		Want/got stx_mode & S_IFMT
      	STATX_MODE		Want/got stx_mode & ~S_IFMT
      	STATX_NLINK		Want/got stx_nlink
      	STATX_UID		Want/got stx_uid
      	STATX_GID		Want/got stx_gid
      	STATX_ATIME		Want/got stx_atime{,_ns}
      	STATX_MTIME		Want/got stx_mtime{,_ns}
      	STATX_CTIME		Want/got stx_ctime{,_ns}
      	STATX_INO		Want/got stx_ino
      	STATX_SIZE		Want/got stx_size
      	STATX_BLOCKS		Want/got stx_blocks
      	STATX_BASIC_STATS	[The stuff in the normal stat struct]
      	STATX_BTIME		Want/got stx_btime{,_ns}
      	STATX_ALL		[All currently available stuff]
      stx_btime is the file creation time, stx_mask is a bitmask indicating the
      data provided and __spares*[] are where as-yet undefined fields can be
      Time fields are structures with separate seconds and nanoseconds fields
      plus a reserved field in case we want to add even finer resolution.  Note
      that times will be negative if before 1970; in such a case, the nanosecond
      fields will also be negative if not zero.
      The bits defined in the stx_attributes field convey information about a
      file, how it is accessed, where it is and what it does.  The following
      attributes map to FS_*_FL flags and are the same numerical value:
      	STATX_ATTR_COMPRESSED		File is compressed by the fs
      	STATX_ATTR_IMMUTABLE		File is marked immutable
      	STATX_ATTR_APPEND		File is append-only
      	STATX_ATTR_NODUMP		File is not to be dumped
      	STATX_ATTR_ENCRYPTED		File requires key to decrypt in fs
      Within the kernel, the supported flags are listed by:
      [Are any other IOC flags of sufficient general interest to be exposed
      through this interface?]
      New flags include:
      	STATX_ATTR_AUTOMOUNT		Object is an automount trigger
      These are for the use of GUI tools that might want to mark files specially,
      depending on what they are.
      Fields in struct statx come in a number of classes:
       (0) stx_dev_*, stx_blksize.
           These are local system information and are always available.
       (1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time, stx_ino,
           stx_size, stx_blocks.
           These will be returned whether the caller asks for them or not.  The
           corresponding bits in stx_mask will be set to indicate whether they
           actually have valid values.
           If the caller didn't ask for them, then they may be approximated.  For
           example, NFS won't waste any time updating them from the server,
           unless as a byproduct of updating something requested.
           If the values don't actually exist for the underlying object (such as
           UID or GID on a DOS file), then the bit won't be set in the stx_mask,
           even if the caller asked for the value.  In such a case, the returned
           value will be a fabrication.
           Note that there are instances where the type might not be valid, for
           instance Windows reparse points.
       (2) stx_rdev_*.
           This will be set only if stx_mode indicates we're looking at a
           blockdev or a chardev, otherwise will be 0.
       (3) stx_btime.
           Similar to (1), except this will be set to 0 if it doesn't exist.
      The following test program can be used to test the statx system call:
      Just compile and run, passing it paths to the files you want to examine.
      The file is built automatically if CONFIG_SAMPLES is enabled.
      Here's some example output.  Firstly, an NFS directory that crosses to
      another FSID.  Note that the AUTOMOUNT attribute is set because transiting
      this directory will cause d_automount to be invoked by the VFS.
      	[root@andromeda ~]# /tmp/test-statx -A /warthog/data
      	statx(/warthog/data) = 0
      	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
      	Device: 00:26           Inode: 1703937     Links: 125
      	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
      	Access: 2016-11-24 09:02:12.219699527+0000
      	Modify: 2016-11-17 10:44:36.225653653+0000
      	Change: 2016-11-17 10:44:36.225653653+0000
      	Attributes: 0000000000001000 (-------- -------- -------- -------- -------- -------- ---m---- --------)
      Secondly, the result of automounting on that directory.
      	[root@andromeda ~]# /tmp/test-statx /warthog/data
      	statx(/warthog/data) = 0
      	  Size: 4096            Blocks: 8          IO Block: 1048576  directory
      	Device: 00:27           Inode: 2           Links: 125
      	Access: (3777/drwxrwxrwx)  Uid:     0   Gid:  4041
      	Access: 2016-11-24 09:02:12.219699527+0000
      	Modify: 2016-11-17 10:44:36.225653653+0000
      	Change: 2016-11-17 10:44:36.225653653+0000
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  8. 02 Mar, 2017 1 commit
  9. 25 Feb, 2017 1 commit
  10. 21 Feb, 2017 1 commit
    • Tejun Heo's avatar
      kernfs: fix locking around kernfs_ops->release() callback · f83f3c51
      Tejun Heo authored
      The release callback may be called from two places - file release
      operation and kernfs open file draining.  kernfs_open_file->mutex is
      used to synchronize the two callsites.  This unfortunately leads to
      possible circular locking because of->mutex is used to protect the
      usual kernfs operations which may use locking constructs which are
      held while removing and thus draining kernfs files.
      @of->mutex is for synchronizing concurrent kernfs access operations
      and all we need here is synchronization between the releaes and drain
      paths.  As the drain path has to grab kernfs_open_file_mutex anyway,
      let's use the mutex to synchronize the release operation instead.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: default avatarTony Lindgren <tony@atomide.com>
      Fixes: 0e67db2f ("kernfs: add kernfs_ops->open/release() callbacks")
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. 10 Feb, 2017 1 commit
  12. 27 Dec, 2016 2 commits
  13. 09 Dec, 2016 1 commit
  14. 29 Nov, 2016 1 commit
  15. 27 Oct, 2016 1 commit
  16. 08 Oct, 2016 1 commit
  17. 07 Oct, 2016 1 commit
  18. 28 Sep, 2016 1 commit
  19. 27 Sep, 2016 2 commits
    • Miklos Szeredi's avatar
      fs: rename "rename2" i_op to "rename" · 2773bf00
      Miklos Szeredi authored
      Generated patch:
      sed -i "s/\.rename2\t/\.rename\t\t/" `git grep -wl rename2`
      sed -i "s/\brename2\b/rename/g" `git grep -wl rename2`
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
    • Miklos Szeredi's avatar
      fs: make remaining filesystems use .rename2 · 1cd66c93
      Miklos Szeredi authored
      This is trivial to do:
       - add flags argument to foo_rename()
       - check if flags is zero
       - assign foo_rename() to .rename2 instead of .rename
      This doesn't mean it's impossible to support RENAME_NOREPLACE for these
      filesystems, but it is not trivial, like for local filesystems.
      RENAME_NOREPLACE must guarantee atomicity (i.e. it shouldn't be possible
      for a file to be created on one host while it is overwritten by rename on
      another host).
      Filesystems converted:
      9p, afs, ceph, coda, ecryptfs, kernfs, lustre, ncpfs, nfs, ocfs2, orangefs.
      After this, we can get rid of the duplicate interfaces for rename.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: David Howells <dhowells@redhat.com> [AFS]
      Acked-by: default avatarMike Marshall <hubcap@omnibond.com>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ilya Dryomov <idryomov@gmail.com>
      Cc: Jan Harkes <jaharkes@cs.cmu.edu>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Oleg Drokin <oleg.drokin@intel.com>
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Cc: Mark Fasheh <mfasheh@suse.com>
  20. 22 Sep, 2016 1 commit
  21. 31 Aug, 2016 1 commit
    • Tejun Heo's avatar
      kernfs: don't depend on d_find_any_alias() when generating notifications · df6a58c5
      Tejun Heo authored
      kernfs_notify_workfn() sends out file modified events for the
      scheduled kernfs_nodes.  Because the modifications aren't from
      userland, it doesn't have the matching file struct at hand and can't
      use fsnotify_modify().  Instead, it looked up the inode and then used
      d_find_any_alias() to find the dentry and used fsnotify_parent() and
      fsnotify() directly to generate notifications.
      The assumption was that the relevant dentries would have been pinned
      if there are listeners, which isn't true as inotify doesn't pin
      dentries at all and watching the parent doesn't pin the child dentries
      even for dnotify.  This led to, for example, inotify watchers not
      getting notifications if the system is under memory pressure and the
      matching dentries got reclaimed.  It can also be triggered through
      /proc/sys/vm/drop_caches or a remount attempt which involves shrinking
      fsnotify_parent() only uses the dentry to access the parent inode,
      which kernfs can do easily.  Update kernfs_notify_workfn() so that it
      uses fsnotify() directly for both the parent and target inodes without
      going through d_find_any_alias().  While at it, supply the target file
      name to fsnotify() from kernfs_node->name.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarEvgeny Vereshchagin <evvers@ya.ru>
      Fixes: d911d987 ("kernfs: make kernfs_notify() trigger inotify events too")
      Cc: John McCutchan <john@johnmccutchan.com>
      Cc: Robert Love <rlove@rlove.org>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: stable@vger.kernel.org # v3.16+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. 10 Aug, 2016 2 commits
    • Tejun Heo's avatar
      kernfs: remove kernfs_path_len() · bb09c863
      Tejun Heo authored
      It doesn't have any in-kernel user and the same result can be obtained
      from kernfs_path(@kn, NULL, 0).  Remove it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
    • Tejun Heo's avatar
      kernfs: make kernfs_path*() behave in the style of strlcpy() · 3abb1d90
      Tejun Heo authored
      kernfs_path*() functions always return the length of the full path but
      the path content is undefined if the length is larger than the
      provided buffer.  This makes its behavior different from strlcpy() and
      requires error handling in all its users even when they don't care
      about truncation.  In addition, the implementation can actully be
      simplified by making it behave properly in strlcpy() style.
      * Update kernfs_path_from_node_locked() to always fill up the buffer
        with path.  If the buffer is not large enough, the output is
        truncated and terminated.
      * kernfs_path() no longer needs error handling.  Make it a simple
        inline wrapper around kernfs_path_from_node().
      * sysfs_warn_dup()'s use of kernfs_path() doesn't need error handling.
        Updated accordingly.
      * cgroup_path()'s use of kernfs_path() updated to retain the old
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
  23. 23 Jun, 2016 3 commits
    • Eric W. Biederman's avatar
      vfs: Generalize filesystem nodev handling. · a2982cc9
      Eric W. Biederman authored
      Introduce a function may_open_dev that tests MNT_NODEV and a new
      superblock flab SB_I_NODEV.  Use this new function in all of the
      places where MNT_NODEV was previously tested.
      Add the new SB_I_NODEV s_iflag to proc, sysfs, and mqueuefs as those
      filesystems should never support device nodes, and a simple superblock
      flags makes that very hard to get wrong.  With SB_I_NODEV set if any
      device nodes somehow manage to show up on on a filesystem those
      device nodes will be unopenable.
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    • Eric W. Biederman's avatar
      kernfs: The cgroup filesystem also benefits from SB_I_NOEXEC · 29a517c2
      Eric W. Biederman authored
      The cgroup filesystem is in the same boat as sysfs.  No one ever
      permits executables of any kind on the cgroup filesystem, and there is
      no reasonable future case to support executables in the future.
      Therefore move the setting of SB_I_NOEXEC which makes the code proof
      against future mistakes of accidentally creating executables from
      sysfs to kernfs itself.  Making the code simpler and covering the
      sysfs, cgroup, and cgroup2 filesystems.
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    • Eric W. Biederman's avatar
      fs: Add user namespace member to struct super_block · 6e4eab57
      Eric W. Biederman authored
      Start marking filesystems with a user namespace owner, s_user_ns.  In
      this change this is only used for permission checks of who may mount a
      filesystem.  Ultimately s_user_ns will be used for translating ids and
      checking capabilities for filesystems mounted from user namespaces.
      The default policy for setting s_user_ns is implemented in sget(),
      which arranges for s_user_ns to be set to current_user_ns() and to
      ensure that the mounter of the filesystem has CAP_SYS_ADMIN in that
      The guts of sget are split out into another function sget_userns().
      The function sget_userns calls alloc_super with the specified user
      namespace or it verifies the existing superblock that was found
      has the expected user namespace, and fails with EBUSY when it is not.
      This failing prevents users with the wrong privileges mounting a
      The reason for the split of sget_userns from sget is that in some
      cases such as mount_ns and kernfs_mount_ns a different policy for
      permission checking of mounts and setting s_user_ns is necessary, and
      the existence of sget_userns() allows those policies to be
      The helper mount_ns is expected to be used for filesystems such as
      proc and mqueuefs which present per namespace information.  The
      function mount_ns is modified to call sget_userns instead of sget to
      ensure the user namespace owner of the namespace whose information is
      presented by the filesystem is used on the superblock.
      For sysfs and cgroup the appropriate permission checks are already in
      place, and kernfs_mount_ns is modified to call sget_userns so that
      the init_user_ns is the only user namespace used.
      For the cgroup filesystem cgroup namespace mounts are bind mounts of a
      subset of the full cgroup filesystem and as such s_user_ns must be the
      same for all of them as there is only a single superblock.
      Mounts of sysfs that vary based on the network namespace could in principle
      change s_user_ns but it keeps the analysis and implementation of kernfs
      simpler if that is not supported, and at present there appear to be no
      benefits from supporting a different s_user_ns on any sysfs mount.
      Getting the details of setting s_user_ns correct has been
      a long process.  Thanks to Pavel Tikhorirorv who spotted a leak
      in sget_userns.  Thanks to Seth Forshee who has kept the work alive.
      Thanks-to: Seth Forshee <seth.forshee@canonical.com>
      Thanks-to: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Acked-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
  24. 11 Jun, 2016 1 commit
    • Linus Torvalds's avatar
      vfs: make the string hashes salt the hash · 8387ff25
      Linus Torvalds authored
      We always mixed in the parent pointer into the dentry name hash, but we
      did it late at lookup time.  It turns out that we can simplify that
      lookup-time action by salting the hash with the parent pointer early
      instead of late.
      A few other users of our string hashes also wanted to mix in their own
      pointers into the hash, and those are updated to use the same mechanism.
      Hash users that don't have any particular initial salt can just use the
      NULL pointer as a no-salt.
      Cc: Vegard Nossum <vegard.nossum@oracle.com>
      Cc: George Spelvin <linux@sciencehorizons.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  25. 28 May, 2016 1 commit
  26. 12 May, 2016 1 commit
  27. 09 May, 2016 2 commits
    • Serge E. Hallyn's avatar
      cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces · 4f41fc59
      Serge E. Hallyn authored
      Patch summary:
      When showing a cgroupfs entry in mountinfo, show the path of the mount
      root dentry relative to the reader's cgroup namespace root.
      Short explanation (courtesy of mkerrisk):
      If we create a new cgroup namespace, then we want both /proc/self/cgroup
      and /proc/self/mountinfo to show cgroup paths that are correctly
      virtualized with respect to the cgroup mount point.  Previous to this
      patch, /proc/self/cgroup shows the right info, but /proc/self/mountinfo
      does not.
      Long version:
      When a uid 0 task which is in freezer cgroup /a/b, unshares a new cgroup
      namespace, and then mounts a new instance of the freezer cgroup, the new
      mount will be rooted at /a/b.  The root dentry field of the mountinfo
      entry will show '/a/b'.
       cat > /tmp/do1 << EOF
       mount -t cgroup -o freezer freezer /mnt
       grep freezer /proc/self/mountinfo
       unshare -Gm  bash /tmp/do1
       > 330 160 0:34 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer
       > 355 133 0:34 /a/b /mnt rw,relatime - cgroup freezer rw,freezer
      The task's freezer cgroup entry in /proc/self/cgroup will simply show
       grep freezer /proc/self/cgroup
      If instead the same task simply bind mounts the /a/b cgroup directory,
      the resulting mountinfo entry will again show /a/b for the dentry root.
      However in this case the task will find its own cgroup at /mnt/a/b,
      not at /mnt:
       mount --bind /sys/fs/cgroup/freezer/a/b /mnt
       130 25 0:34 /a/b /mnt rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,freezer
      In other words, there is no way for the task to know, based on what is
      in mountinfo, which cgroup directory is its own.
      Example (by mkerrisk):
      First, a little script to save some typing and verbiage:
      echo -e "\t/proc/self/cgroup:\t$(cat /proc/self/cgroup | grep freezer)"
      cat /proc/self/mountinfo | grep freezer |
              awk '{print "\tmountinfo:\t\t" $4 "\t" $5}'
      Create cgroup, place this shell into the cgroup, and look at the state
      of the /proc files:
      2653                         # Our shell
      14254                        # cat(1)
              /proc/self/cgroup:      10:freezer:/a/b
              mountinfo:              /       /sys/fs/cgroup/freezer
      Create a shell in new cgroup and mount namespaces. The act of creating
      a new cgroup namespace causes the process's current cgroups directories
      to become its cgroup root directories. (Here, I'm using my own version
      of the "unshare" utility, which takes the same options as the util-linux
      Look at the state of the /proc files:
              /proc/self/cgroup:      10:freezer:/
              mountinfo:              /       /sys/fs/cgroup/freezer
      The third entry in /proc/self/cgroup (the pathname of the cgroup inside
      the hierarchy) is correctly virtualized w.r.t. the cgroup namespace, which
      is rooted at /a/b in the outer namespace.
      However, the info in /proc/self/mountinfo is not for this cgroup
      namespace, since we are seeing a duplicate of the mount from the
      old mount namespace, and the info there does not correspond to the
      new cgroup namespace. However, trying to create a new mount still
      doesn't show us the right information in mountinfo:
                                            # propagating to other mountns
              /proc/self/cgroup:      7:freezer:/
              mountinfo:              /a/b    /mnt/freezer
      The act of creating a new cgroup namespace caused the process's
      current freezer directory, "/a/b", to become its cgroup freezer root
      directory. In other words, the pathname directory of the directory
      within the newly mounted cgroup filesystem should be "/",
      but mountinfo wrongly shows us "/a/b". The consequence of this is
      that the process in the cgroup namespace cannot correctly construct
      the pathname of its cgroup root directory from the information in
      With this patch, the dentry root field in mountinfo is shown relative
      to the reader's cgroup namespace.  So the same steps as above:
              /proc/self/cgroup:      10:freezer:/a/b
              mountinfo:              /       /sys/fs/cgroup/freezer
              /proc/self/cgroup:      10:freezer:/
              mountinfo:              /../..  /sys/fs/cgroup/freezer
              /proc/self/cgroup:      10:freezer:/
              mountinfo:              /       /mnt/freezer
      cgroup.clone_children  freezer.parent_freezing  freezer.state      tasks
      cgroup.procs           freezer.self_freezing    notify_on_release
      2653                   # First shell that placed in this cgroup
      3164                   # Shell started by 'unshare'
      14197                  # cat(1)
      Signed-off-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Tested-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
      Acked-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
    • Al Viro's avatar
  28. 02 May, 2016 1 commit