1. 12 Apr, 2018 1 commit
  2. 09 Apr, 2018 1 commit
    • David Howells's avatar
      afs: Implement @sys substitution handling · 6f8880d8
      David Howells authored
      Implement the AFS feature by which @sys at the end of a pathname component
      may be substituted for one of a list of values, typically naming the
      operating system.  Up to 16 alternatives may be specified and these are
      tried in turn until one works.  Each network namespace has[*] a separate
      independent list.
      
      Upon creation of a new network namespace, the list of values is
      initialised[*] to a single OpenAFS-compatible string representing arch type
      plus "_linux26".  For example, on x86_64, the sysname is "amd64_linux26".
      
      [*] Or will, once network namespace support is finalised in kAFS.
      
      The list may be set by:
      
      	# for i in foo bar linux-x86_64; do echo $i; done >/proc/fs/afs/sysname
      
      for which separate writes to the same fd are amalgamated and applied on
      close.  The LF character may be used as a separator to specify multiple
      items in the same write() call.
      
      The list may be cleared by:
      
      	# echo >/proc/fs/afs/sysname
      
      and read by:
      
      	# cat /proc/fs/afs/sysname
      	foo
      	bar
      	linux-x86_64
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      6f8880d8
  3. 06 Apr, 2018 1 commit
  4. 04 Apr, 2018 3 commits
    • Mike Marshall's avatar
      Orangefs: documentation updates · 8e9ba5c4
      Mike Marshall authored
      Signed-off-by: 's avatarMike Marshall <hubcap@omnibond.com>
      8e9ba5c4
    • David Howells's avatar
      fscache: Attach the index key and aux data to the cookie · 402cb8dd
      David Howells authored
      Attach copies of the index key and auxiliary data to the fscache cookie so
      that:
      
       (1) The callbacks to the netfs for this stuff can be eliminated.  This
           can simplify things in the cache as the information is still
           available, even after the cache has relinquished the cookie.
      
       (2) Simplifies the locking requirements of accessing the information as we
           don't have to worry about the netfs object going away on us.
      
       (3) The cache can do lazy updating of the coherency information on disk.
           As long as the cache is flushed before reboot/poweroff, there's no
           need to update the coherency info on disk every time it changes.
      
       (4) Cookies can be hashed or put in a tree as the index key is easily
           available.  This allows:
      
           (a) Checks for duplicate cookies can be made at the top fscache layer
           	 rather than down in the bowels of the cache backend.
      
           (b) Caching can be added to a netfs object that has a cookie if the
           	 cache is brought online after the netfs object is allocated.
      
      A certain amount of space is made in the cookie for inline copies of the
      data, but if it won't fit there, extra memory will be allocated for it.
      
      The downside of this is that live cache operation requires more memory.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Acked-by: 's avatarAnna Schumaker <anna.schumaker@netapp.com>
      Tested-by: 's avatarSteve Dickson <steved@redhat.com>
      402cb8dd
    • Martin Brandenburg's avatar
      orangefs: document package install and xfstests procedure · dd098022
      Martin Brandenburg authored
      Unless one is working on the userspace code, there's no need to compile
      OrangeFS.  The package works just fine.
      
      (But leave the documentation for building from source since not everyone
      uses distributions which include the package.)
      
      Also document the process to run xfstests against OrangeFS.
      Signed-off-by: 's avatarMartin Brandenburg <martin@omnibond.com>
      Signed-off-by: 's avatarMike Marshall <hubcap@omnibond.com>
      dd098022
  5. 02 Apr, 2018 4 commits
  6. 21 Mar, 2018 1 commit
  7. 17 Mar, 2018 2 commits
  8. 12 Mar, 2018 2 commits
  9. 27 Feb, 2018 2 commits
  10. 06 Feb, 2018 1 commit
    • David Howells's avatar
      afs: Support the AFS dynamic root · 4d673da1
      David Howells authored
      Support the AFS dynamic root which is a pseudo-volume that doesn't connect
      to any server resource, but rather is just a root directory that
      dynamically creates mountpoint directories where the name of such a
      directory is the name of the cell.
      
      Such a mount can be created thus:
      
      	mount -t afs none /afs -o dyn
      
      Dynamic root superblocks aren't shared except by bind mounts and
      propagation.  Cell root volumes can then be mounted by referring to them by
      name, e.g.:
      
      	ls /afs/grand.central.org/
      	ls /afs/.grand.central.org/
      
      The kernel will upcall to consult the DNS if the address wasn't supplied
      directly.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      4d673da1
  11. 28 Jan, 2018 1 commit
    • Michael Ellerman's avatar
      powerpc/cell: Remove axonram driver · 1d65b1c8
      Michael Ellerman authored
      The QS21/22 IBM Cell blades had a southbridge chip called Axon. This
      could have DDR DIMMs attached to it, though they were not directly
      usable as RAM, instead they could be used as some sort of buffer, if
      applications were written specifically to use the block device
      provided by the driver.
      
      Although the driver supposedly had direct access support, it was
      apparently never tested (see commit 91117a20 ("axonram: Fix bug in
      direct_access")).
      
      These machines have not been available for over 5 years, and were
      never widely in use. It seems highly unlikely anyone is using this
      driver.
      
      In general we're happy to leave old drivers in the tree, but because
      DAX is involved this driver is caught up in the ongoing work in that
      area, but none of the DAX folks are able to test it.
      
      So remove the driver, if any one *is* using it, we'll be happy to put
      it back.
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      1d65b1c8
  12. 24 Jan, 2018 3 commits
  13. 16 Jan, 2018 1 commit
    • Sergey Senozhatsky's avatar
      kallsyms: remove print_symbol() function · d2279c9d
      Sergey Senozhatsky authored
      No more print_symbol()/__print_symbol() users left, remove these
      symbols.
      
      It was a very old API that encouraged people use continuous lines.
      It had been obsoleted by %pS format specifier in a normal printk()
      call.
      
      Link: http://lkml.kernel.org/r/20180105102538.GC471@jagdpanzerIV
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: LKML <linux-kernel@vger.kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-sh@vger.kernel.org
      Cc: linux-edac@vger.kernel.org
      Cc: x86@kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: 's avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Suggested-by: 's avatarJoe Perches <joe@perches.com>
      [pmladek@suse.com: updated commit message]
      Signed-off-by: 's avatarPetr Mladek <pmladek@suse.com>
      d2279c9d
  14. 13 Jan, 2018 1 commit
  15. 12 Jan, 2018 1 commit
  16. 11 Jan, 2018 1 commit
  17. 01 Jan, 2018 1 commit
  18. 26 Dec, 2017 1 commit
    • NeilBrown's avatar
      VFS: don't keep disconnected dentries on d_anon · f1ee6162
      NeilBrown authored
      The original purpose of the per-superblock d_anon list was to
      keep disconnected dentries in the cache between consecutive
      requests to the NFS server.  Dentries can be disconnected if
      a client holds a file open and repeatedly performs IO on it,
      and if the server drops the dentry, whether due to memory
      pressure, server restart, or "echo 3 > /proc/sys/vm/drop_caches".
      
      This purpose was thwarted by commit 75a6f82a ("freeing unlinked
      file indefinitely delayed") which caused disconnected dentries
      to be freed as soon as their refcount reached zero.
      
      This means that, when a dentry being used by nfsd gets disconnected, a
      new one needs to be allocated for every request (unless requests
      overlap).  As the dentry has no name, no parent, and no children,
      there is little of value to cache.  As small memory allocations are
      typically fast (from per-cpu free lists) this likely has little cost.
      
      This means that the original purpose of s_anon is no longer relevant:
      there is no longer any need to keep disconnected dentries on a list so
      they appear to be hashed.
      
      However, s_anon now has a new use.  When you mount an NFS filesystem,
      the dentry stored in s_root is just a placebo.  The "real" root dentry
      is allocated using d_obtain_root() and so it kept on the s_anon list.
      I don't know the reason for this, but suspect it related to NFSv4
      where a mount of "server:/some/path" require NFS to look up the root
      filehandle on the server, then walk down "/some" and "/path" to get
      the filehandle to mount.
      
      Whatever the reason, NFS depends on the s_anon list and on
      shrink_dcache_for_umount() pruning all dentries on this list.  So we
      cannot simply remove s_anon.
      
      We could just leave the code unchanged, but apart from that being
      potentially confusing, the (unfair) bit-spin-lock which protects
      s_anon can become a bottle neck when lots of disconnected dentries are
      being created.
      
      So this patch renames s_anon to s_roots, and stops storing
      disconnected dentries on the list.  Only dentries obtained with
      d_obtain_root() are now stored on this list.  There are many fewer of
      these (only NFS and NILFS2 use the call, and only during filesystem
      mount) so contention on the bit-lock will not be a problem.
      
      Possibly an alternate solution should be found for NFS and NILFS2, but
      that would require understanding their needs first.
      Signed-off-by: 's avatarNeilBrown <neilb@suse.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      f1ee6162
  19. 21 Dec, 2017 1 commit
  20. 11 Dec, 2017 1 commit
    • Miklos Szeredi's avatar
      ovl: don't follow redirects if redirect_dir=off · 438c84c2
      Miklos Szeredi authored
      Overlayfs is following redirects even when redirects are disabled. If this
      is unintentional (probably the majority of cases) then this can be a
      problem.  E.g. upper layer comes from untrusted USB drive, and attacker
      crafts a redirect to enable read access to otherwise unreadable
      directories.
      
      If "redirect_dir=off", then turn off following as well as creation of
      redirects.  If "redirect_dir=follow", then turn on following, but turn off
      creation of redirects (which is what "redirect_dir=off" does now).
      
      This is a backward incompatible change, so make it dependent on a config
      option.
      Reported-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarMiklos Szeredi <mszeredi@redhat.com>
      438c84c2
  21. 18 Nov, 2017 1 commit
    • Roman Gushchin's avatar
      proc, coredump: add CoreDumping flag to /proc/pid/status · c6434012
      Roman Gushchin authored
      Right now there is no convenient way to check if a process is being
      coredumped at the moment.
      
      It might be necessary to recognize such state to prevent killing the
      process and getting a broken coredump.  Writing a large core might take
      significant time, and the process is unresponsive during it, so it might
      be killed by timeout, if another process is monitoring and
      killing/restarting hanging tasks.
      
      We're getting a significant number of corrupted coredump files on
      machines in our fleet, just because processes are being killed by
      timeout in the middle of the core writing process.
      
      We do have a process health check, and some agent is responsible for
      restarting processes which are not responding for health check requests.
      Writing a large coredump to the disk can easily exceed the reasonable
      timeout (especially on an overloaded machine).
      
      This flag will allow the agent to distinguish processes which are being
      coredumped, extend the timeout for them, and let them produce a full
      coredump file.
      
      To provide an ability to detect if a process is in the state of being
      coredumped, we can expose a boolean CoreDumping flag in
      /proc/pid/status.
      
      Example:
      $ cat core.sh
        #!/bin/sh
      
        echo "|/usr/bin/sleep 10" > /proc/sys/kernel/core_pattern
        sleep 1000 &
        PID=$!
      
        cat /proc/$PID/status | grep CoreDumping
        kill -ABRT $PID
        sleep 1
        cat /proc/$PID/status | grep CoreDumping
      
      $ ./core.sh
        CoreDumping:	0
        CoreDumping:	1
      
      [guro@fb.com: document CoreDumping flag in /proc/<pid>/status]
        Link: http://lkml.kernel.org/r/20170928135357.GA8470@castle.DHCP.thefacebook.com
      Link: http://lkml.kernel.org/r/20170920230634.31572-1-guro@fb.comSigned-off-by: 's avatarRoman Gushchin <guro@fb.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      c6434012
  22. 16 Nov, 2017 1 commit
  23. 13 Nov, 2017 1 commit
  24. 05 Nov, 2017 1 commit
  25. 31 Oct, 2017 1 commit
    • Eric Biggers's avatar
      fscrypt: add a documentation file for filesystem-level encryption · f4f864c1
      Eric Biggers authored
      Perhaps long overdue, add a documentation file for filesystem-level
      encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
      directory.  The new file is based loosely on the latest version of the
      "EXT4 Encryption Design Document (public version)" Google Doc, but with
      many improvements made, including:
      
      - Reflect the reality that it is not specific to ext4 anymore.
      - More thoroughly document the design and user-visible API/behavior.
      - Replace outdated information, such as the outdated explanation of how
        encrypted filenames are hashed for indexed directories and how
        encrypted filenames are presented to userspace without the key.
        (This was changed just before release.)
      
      For now the focus is on the design and user-visible API/behavior, not on
      how to add encryption support to a filesystem --- since the internal API
      is still pretty messy and any standalone documentation for it would
      become outdated as things get refactored over time.
      Reviewed-by: 's avatarMichael Halcrow <mhalcrow@google.com>
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarTheodore Ts'o <tytso@mit.edu>
      f4f864c1
  26. 25 Oct, 2017 1 commit
    • Paul E. McKenney's avatar
      locking/atomics, doc/filesystems: Convert ACCESS_ONCE() references · 3587679d
      Paul E. McKenney authored
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't currently harmful.
      
      However, for some features it is necessary to instrument reads and
      writes separately, which is not possible with ACCESS_ONCE(). This
      distinction is critical to correct operation.
      
      It's possible to transform the bulk of kernel code using the Coccinelle
      script below. However, this doesn't handle documentation, leaving
      references to ACCESS_ONCE() instances which have been removed. As a
      preparatory step, this patch converts the filesystems documentation to
      use {READ,WRITE}_ONCE() consistently.
      
      ----
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: 's avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: 's avatarWill Deacon <will.deacon@arm.com>
      Acked-by: 's avatarMark Rutland <mark.rutland@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Link: http://lkml.kernel.org/r/1508792849-3115-14-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      3587679d
  27. 19 Oct, 2017 1 commit
  28. 18 Oct, 2017 1 commit
  29. 16 Oct, 2017 1 commit
  30. 15 Oct, 2017 1 commit