1. 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>
  2. 25 Feb, 2017 1 commit
  3. 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>
  4. 10 Feb, 2017 1 commit
  5. 27 Dec, 2016 2 commits
  6. 09 Dec, 2016 1 commit
  7. 29 Nov, 2016 1 commit
  8. 27 Oct, 2016 1 commit
  9. 08 Oct, 2016 1 commit
  10. 07 Oct, 2016 1 commit
  11. 28 Sep, 2016 1 commit
  12. 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>
  13. 22 Sep, 2016 1 commit
  14. 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>
  15. 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>
  16. 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>
  17. 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>
  18. 28 May, 2016 1 commit
  19. 12 May, 2016 1 commit
  20. 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
  21. 02 May, 2016 2 commits
    • Al Viro's avatar
      kernfs: use lookup_one_len_unlocked() · 779b8391
      Al Viro authored
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Serge Hallyn's avatar
      kernfs_path_from_node_locked: don't overwrite nlen · e99ed4de
      Serge Hallyn authored
      We've calculated @len to be the bytes we need for '/..' entries from
      @kn_from to the common ancestor, and calculated @nlen to be the extra
      bytes we need to get from the common ancestor to @kn_to.  We use them
      as such at the end.  But in the loop copying the actual entries, we
      overwrite @nlen.  Use a temporary variable for that instead.
      Without this, the return length, when the buffer is large enough, is
      wrong.  (When the buffer is NULL or too small, the returned value is
      correct. The buffer contents are also correct.)
      Interestingly, no callers of this function are affected by this as of
      yet.  However the upcoming cgroup_show_path() will be.
      Signed-off-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
  22. 30 Apr, 2016 1 commit
    • Chris Wilson's avatar
      kernfs: Move faulting copy_user operations outside of the mutex · e4234a1f
      Chris Wilson authored
      A fault in a user provided buffer may lead anywhere, and lockdep warns
      that we have a potential deadlock between the mm->mmap_sem and the
      kernfs file mutex:
      [   82.811702] ======================================================
      [   82.811705] [ INFO: possible circular locking dependency detected ]
      [   82.811709] 4.5.0-rc4-gfxbench+ #1 Not tainted
      [   82.811711] -------------------------------------------------------
      [   82.811714] kms_setmode/5859 is trying to acquire lock:
      [   82.811717]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffff8150d9c1>] drm_gem_mmap+0x1a1/0x270
      [   82.811731]
      but task is already holding lock:
      [   82.811734]  (&mm->mmap_sem){++++++}, at: [<ffffffff8117b364>] vm_mmap_pgoff+0x44/0xa0
      [   82.811745]
      which lock already depends on the new lock.
      [   82.811749]
      the existing dependency chain (in reverse order) is:
      [   82.811752]
      -> #3 (&mm->mmap_sem){++++++}:
      [   82.811761]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.811766]        [<ffffffff8118bc65>] __might_fault+0x75/0xa0
      [   82.811771]        [<ffffffff8124da4a>] kernfs_fop_write+0x8a/0x180
      [   82.811787]        [<ffffffff811d1023>] __vfs_write+0x23/0xe0
      [   82.811792]        [<ffffffff811d1d74>] vfs_write+0xa4/0x190
      [   82.811797]        [<ffffffff811d2c14>] SyS_write+0x44/0xb0
      [   82.811801]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.811807]
      -> #2 (s_active#6){++++.+}:
      [   82.811814]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.811819]        [<ffffffff8124c070>] __kernfs_remove+0x210/0x2f0
      [   82.811823]        [<ffffffff8124d040>] kernfs_remove_by_name_ns+0x40/0xa0
      [   82.811828]        [<ffffffff8124e9e0>] sysfs_remove_file_ns+0x10/0x20
      [   82.811832]        [<ffffffff815318d4>] device_del+0x124/0x250
      [   82.811837]        [<ffffffff81531a19>] device_unregister+0x19/0x60
      [   82.811841]        [<ffffffff8153c051>] cpu_cache_sysfs_exit+0x51/0xb0
      [   82.811846]        [<ffffffff8153c628>] cacheinfo_cpu_callback+0x38/0x70
      [   82.811851]        [<ffffffff8109ae89>] notifier_call_chain+0x39/0xa0
      [   82.811856]        [<ffffffff8109aef9>] __raw_notifier_call_chain+0x9/0x10
      [   82.811860]        [<ffffffff810786de>] cpu_notify+0x1e/0x40
      [   82.811865]        [<ffffffff81078779>] cpu_notify_nofail+0x9/0x20
      [   82.811869]        [<ffffffff81078ac3>] _cpu_down+0x233/0x340
      [   82.811874]        [<ffffffff81079019>] disable_nonboot_cpus+0xc9/0x350
      [   82.811878]        [<ffffffff810d2e11>] suspend_devices_and_enter+0x5a1/0xb50
      [   82.811883]        [<ffffffff810d3903>] pm_suspend+0x543/0x8d0
      [   82.811888]        [<ffffffff810d1b77>] state_store+0x77/0xe0
      [   82.811892]        [<ffffffff813fa68f>] kobj_attr_store+0xf/0x20
      [   82.811897]        [<ffffffff8124e740>] sysfs_kf_write+0x40/0x50
      [   82.811902]        [<ffffffff8124dafc>] kernfs_fop_write+0x13c/0x180
      [   82.811906]        [<ffffffff811d1023>] __vfs_write+0x23/0xe0
      [   82.811910]        [<ffffffff811d1d74>] vfs_write+0xa4/0x190
      [   82.811914]        [<ffffffff811d2c14>] SyS_write+0x44/0xb0
      [   82.811918]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.811923]
      -> #1 (cpu_hotplug.lock){+.+.+.}:
      [   82.811929]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.811933]        [<ffffffff817b6f72>] mutex_lock_nested+0x62/0x3b0
      [   82.811940]        [<ffffffff810784c1>] get_online_cpus+0x61/0x80
      [   82.811944]        [<ffffffff811170eb>] stop_machine+0x1b/0xe0
      [   82.811949]        [<ffffffffa0178edd>] gen8_ggtt_insert_entries__BKL+0x2d/0x30 [i915]
      [   82.812009]        [<ffffffffa017d3a6>] ggtt_bind_vma+0x46/0x70 [i915]
      [   82.812045]        [<ffffffffa017eb70>] i915_vma_bind+0x140/0x290 [i915]
      [   82.812081]        [<ffffffffa01862b9>] i915_gem_object_do_pin+0x899/0xb00 [i915]
      [   82.812117]        [<ffffffffa0186555>] i915_gem_object_pin+0x35/0x40 [i915]
      [   82.812154]        [<ffffffffa019a23e>] intel_init_pipe_control+0xbe/0x210 [i915]
      [   82.812192]        [<ffffffffa0197312>] intel_logical_rings_init+0xe2/0xde0 [i915]
      [   82.812232]        [<ffffffffa0186fe3>] i915_gem_init+0xf3/0x130 [i915]
      [   82.812278]        [<ffffffffa02097ed>] i915_driver_load+0xf2d/0x1770 [i915]
      [   82.812318]        [<ffffffff81512474>] drm_dev_register+0xa4/0xb0
      [   82.812323]        [<ffffffff8151467e>] drm_get_pci_dev+0xce/0x1e0
      [   82.812328]        [<ffffffffa01472cf>] i915_pci_probe+0x2f/0x50 [i915]
      [   82.812360]        [<ffffffff8143f907>] pci_device_probe+0x87/0xf0
      [   82.812366]        [<ffffffff81535f89>] driver_probe_device+0x229/0x450
      [   82.812371]        [<ffffffff81536233>] __driver_attach+0x83/0x90
      [   82.812375]        [<ffffffff81533c61>] bus_for_each_dev+0x61/0xa0
      [   82.812380]        [<ffffffff81535879>] driver_attach+0x19/0x20
      [   82.812384]        [<ffffffff8153535f>] bus_add_driver+0x1ef/0x290
      [   82.812388]        [<ffffffff81536e9b>] driver_register+0x5b/0xe0
      [   82.812393]        [<ffffffff8143e83b>] __pci_register_driver+0x5b/0x60
      [   82.812398]        [<ffffffff81514866>] drm_pci_init+0xd6/0x100
      [   82.812402]        [<ffffffffa027c094>] 0xffffffffa027c094
      [   82.812406]        [<ffffffff810003de>] do_one_initcall+0xae/0x1d0
      [   82.812412]        [<ffffffff811595a0>] do_init_module+0x5b/0x1cb
      [   82.812417]        [<ffffffff81106160>] load_module+0x1c20/0x2480
      [   82.812422]        [<ffffffff81106bae>] SyS_finit_module+0x7e/0xa0
      [   82.812428]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.812433]
      -> #0 (&dev->struct_mutex){+.+.+.}:
      [   82.812439]        [<ffffffff810cbe59>] __lock_acquire+0x1fc9/0x20f0
      [   82.812443]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.812456]        [<ffffffff8150d9e7>] drm_gem_mmap+0x1c7/0x270
      [   82.812460]        [<ffffffff81196a14>] mmap_region+0x334/0x580
      [   82.812466]        [<ffffffff81196fc4>] do_mmap+0x364/0x410
      [   82.812470]        [<ffffffff8117b38d>] vm_mmap_pgoff+0x6d/0xa0
      [   82.812474]        [<ffffffff811950f4>] SyS_mmap_pgoff+0x184/0x220
      [   82.812479]        [<ffffffff8100a0fd>] SyS_mmap+0x1d/0x20
      [   82.812484]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.812489]
      other info that might help us debug this:
      [   82.812493] Chain exists of:
        &dev->struct_mutex --> s_active#6 --> &mm->mmap_sem
      [   82.812502]  Possible unsafe locking scenario:
      [   82.812506]        CPU0                    CPU1
      [   82.812508]        ----                    ----
      [   82.812510]   lock(&mm->mmap_sem);
      [   82.812514]                                lock(s_active#6);
      [   82.812519]                                lock(&mm->mmap_sem);
      [   82.812522]   lock(&dev->struct_mutex);
      [   82.812526]
       *** DEADLOCK ***
      [   82.812531] 1 lock held by kms_setmode/5859:
      [   82.812533]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8117b364>] vm_mmap_pgoff+0x44/0xa0
      [   82.812541]
      stack backtrace:
      [   82.812547] CPU: 0 PID: 5859 Comm: kms_setmode Not tainted 4.5.0-rc4-gfxbench+ #1
      [   82.812550] Hardware name:                  /NUC5CPYB, BIOS PYBSWCEL.86A.0040.2015.0814.1353 08/14/2015
      [   82.812553]  0000000000000000 ffff880079407bf0 ffffffff813f8505 ffffffff825fb270
      [   82.812560]  ffffffff825c4190 ffff880079407c30 ffffffff810c84ac ffff880079407c90
      [   82.812566]  ffff8800797ed328 ffff8800797ecb00 0000000000000001 ffff8800797ed350
      [   82.812573] Call Trace:
      [   82.812578]  [<ffffffff813f8505>] dump_stack+0x67/0x92
      [   82.812582]  [<ffffffff810c84ac>] print_circular_bug+0x1fc/0x310
      [   82.812586]  [<ffffffff810cbe59>] __lock_acquire+0x1fc9/0x20f0
      [   82.812590]  [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.812594]  [<ffffffff8150d9c1>] ? drm_gem_mmap+0x1a1/0x270
      [   82.812599]  [<ffffffff8150d9e7>] drm_gem_mmap+0x1c7/0x270
      [   82.812603]  [<ffffffff8150d9c1>] ? drm_gem_mmap+0x1a1/0x270
      [   82.812608]  [<ffffffff81196a14>] mmap_region+0x334/0x580
      [   82.812612]  [<ffffffff81196fc4>] do_mmap+0x364/0x410
      [   82.812616]  [<ffffffff8117b38d>] vm_mmap_pgoff+0x6d/0xa0
      [   82.812629]  [<ffffffff811950f4>] SyS_mmap_pgoff+0x184/0x220
      [   82.812633]  [<ffffffff8100a0fd>] SyS_mmap+0x1d/0x20
      [   82.812637]  [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      Highly unlikely though this scenario is, we can avoid the issue entirely
      by moving the copy operation from out under the kernfs_get_active()
      tracking by assigning the preallocated buffer its own mutex. The
      temporary buffer allocation doesn't require mutex locking as it is
      entirely local.
      The locked section was extended by the addition of the preallocated buf
      to speed up md user operations in
      commit 2b75869b
      Author: NeilBrown <neilb@suse.de>
      Date:   Mon Oct 13 16:41:28 2014 +1100
          sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: NeilBrown <neilb@suse.de>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  23. 11 Apr, 2016 1 commit
  24. 04 Apr, 2016 1 commit
    • Kirill A. Shutemov's avatar
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov authored
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      This promise never materialized.  And unlikely will.
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      Let's stop pretending that pages in page cache are special.  They are
      The changes are pretty straight-forward:
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
       - page_cache_get() -> get_page();
       - page_cache_release() -> put_page();
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      virtual patch
      expression E;
      + E
      expression E;
      + E
      + PAGE_SHIFT
      + PAGE_SIZE
      + PAGE_MASK
      expression E;
      + PAGE_ALIGN(E)
      expression E;
      - page_cache_get(E)
      + get_page(E)
      expression E;
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  25. 29 Mar, 2016 1 commit
    • Deepa Dinamani's avatar
      fs: kernfs: Replace CURRENT_TIME by current_fs_time() · 3a3a5fec
      Deepa Dinamani authored
      This is in preparation for the series that transitions
      filesystem timestamps to use 64 bit time and hence make
      them y2038 safe.
      CURRENT_TIME macro will be deleted before merging the
      aforementioned series.
      Use current_fs_time() instead of CURRENT_TIME for inode
      struct kernfs_node is associated with a sysfs file/ directory.
      Truncate the values to appropriate time granularity when
      writing to inode timestamps of the files.
      ktime_get_real_ts() is used to obtain times for
      struct kernfs_iattrs. Since these times are later assigned to
      inode times using timespec_truncate() for all filesystem based
      operations, we can save the supers list traversal time here by
      using ktime_get_real_ts() directly.
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  26. 16 Feb, 2016 2 commits
  27. 08 Feb, 2016 1 commit
  28. 22 Jan, 2016 1 commit
    • Al Viro's avatar
      wrappers for ->i_mutex access · 5955102c
      Al Viro authored
      parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
      inode_foo(inode) being mutex_foo(&inode->i_mutex).
      Please, use those for access to ->i_mutex; over the coming cycle
      ->i_mutex will become rwsem, with ->lookup() done with it held
      only shared.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  29. 15 Jan, 2016 1 commit
    • Vladimir Davydov's avatar
      Revert "kernfs: do not account ino_ida allocations to memcg" · b2a209ff
      Vladimir Davydov authored
      Currently, all kmem allocations (namely every kmem_cache_alloc, kmalloc,
      alloc_kmem_pages call) are accounted to memory cgroup automatically.
      Callers have to explicitly opt out if they don't want/need accounting
      for some reason.  Such a design decision leads to several problems:
       - kmalloc users are highly sensitive to failures, many of them
         implicitly rely on the fact that kmalloc never fails, while memcg
         makes failures quite plausible.
       - A lot of objects are shared among different containers by design.
         Accounting such objects to one of containers is just unfair.
         Moreover, it might lead to pinning a dead memcg along with its kmem
         caches, which aren't tiny, which might result in noticeable increase
         in memory consumption for no apparent reason in the long run.
       - There are tons of short-lived objects. Accounting them to memcg will
         only result in slight noise and won't change the overall picture, but
         we still have to pay accounting overhead.
      For more info, see
       - http://lkml.kernel.org/r/20151105144002.GB15111%40dhcp22.suse.cz
       - http://lkml.kernel.org/r/20151106090555.GK29259@esperanza
      Therefore this patchset switches to the white list policy.  Now kmalloc
      users have to explicitly opt in by passing __GFP_ACCOUNT flag.
      Currently, the list of accounted objects is quite limited and only
      includes those allocations that (1) are known to be easily triggered
      from userspace and (2) can fail gracefully (for the full list see patch
      no.  6) and it still misses many object types.  However, accounting only
      those objects should be a satisfactory approximation of the behavior we
      used to have for most sane workloads.
      This patch (of 6):
      Revert 499611ed ("kernfs: do not account ino_ida allocations
      to memcg").
      Black-list kmem accounting policy (aka __GFP_NOACCOUNT) turned out to be
      fragile and difficult to maintain, because there seem to be many more
      allocations that should not be accounted than those that should be.
      Besides, false accounting an allocation might result in much worse
      consequences than not accounting at all, namely increased memory
      consumption due to pinned dead kmem caches.
      So it was decided to switch to the white-list policy.  This patch reverts
      bits introducing the black-list policy.  The white-list policy will be
      introduced later in the series.
      Signed-off-by: default avatarVladimir Davydov <vdavydov@virtuozzo.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  30. 30 Dec, 2015 1 commit
  31. 29 Dec, 2015 1 commit
  32. 09 Dec, 2015 1 commit
    • Al Viro's avatar
      replace ->follow_link() with new method that could stay in RCU mode · 6b255391
      Al Viro authored
      new method: ->get_link(); replacement of ->follow_link().  The differences
      	* inode and dentry are passed separately
      	* might be called both in RCU and non-RCU mode;
      the former is indicated by passing it a NULL dentry.
      	* when called that way it isn't allowed to block
      and should return ERR_PTR(-ECHILD) if it needs to be called
      in non-RCU mode.
      It's a flagday change - the old method is gone, all in-tree instances
      converted.  Conversion isn't hard; said that, so far very few instances
      do not immediately bail out when called in RCU mode.  That'll change
      in the next commits.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>