1. 01 Oct, 2014 1 commit
  2. 23 Jul, 2014 1 commit
  3. 11 Jul, 2014 1 commit
    • Michael Ellerman's avatar
      powerpc/cell: Fix compilation with CONFIG_COREDUMP=n · e623fbf1
      Michael Ellerman authored
      Commit 046d662f
       "coredump: make core dump functionality optional"
      made the coredump optional, but didn't update the spufs code that
      depends on it. That leads to build errors such as:
        arch/powerpc/platforms/built-in.o: In function `.spufs_arch_write_note':
        coredump.c:(.text+0x22cd4): undefined reference to `.dump_emit'
        coredump.c:(.text+0x22cf4): undefined reference to `.dump_emit'
        coredump.c:(.text+0x22d0c): undefined reference to `.dump_align'
        coredump.c:(.text+0x22d48): undefined reference to `.dump_emit'
        coredump.c:(.text+0x22e7c): undefined reference to `.dump_skip'
      Fix it by adding some ifdefs in the cell code.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
  4. 24 Jun, 2014 1 commit
  5. 11 Jun, 2014 1 commit
  6. 23 Apr, 2014 1 commit
  7. 09 Apr, 2014 1 commit
  8. 11 Mar, 2014 1 commit
    • Johannes Weiner's avatar
      mm: fix GFP_THISNODE callers and clarify · e97ca8e5
      Johannes Weiner authored
      GFP_THISNODE is for callers that implement their own clever fallback to
      remote nodes.  It restricts the allocation to the specified node and
      does not invoke reclaim, assuming that the caller will take care of it
      when the fallback fails, e.g.  through a subsequent allocation request
      without GFP_THISNODE set.
      However, many current GFP_THISNODE users only want the node exclusive
      aspect of the flag, without actually implementing their own fallback or
      triggering reclaim if necessary.  This results in things like page
      migration failing prematurely even when there is easily reclaimable
      memory available, unless kswapd happens to be running already or a
      concurrent allocation attempt triggers the necessary reclaim.
      Convert all callsites that don't implement their own fallback strategy
      to __GFP_THISNODE.  This restricts the allocation a single node too, but
      at the same time allows the allocator to enter the slowpath, wake
      kswapd, and invoke direct reclaim if necessary, to make the allocation
      happen when memory is full.
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Cc: Jan Stancek <jstancek@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  9. 05 Mar, 2014 2 commits
  10. 11 Feb, 2014 1 commit
  11. 30 Dec, 2013 2 commits
  12. 09 Dec, 2013 1 commit
  13. 09 Nov, 2013 3 commits
  14. 24 Oct, 2013 4 commits
  15. 21 Aug, 2013 1 commit
  16. 14 Aug, 2013 2 commits
  17. 29 Jun, 2013 1 commit
  18. 21 Jun, 2013 1 commit
  19. 20 Jun, 2013 1 commit
  20. 10 Jun, 2013 1 commit
  21. 06 May, 2013 2 commits
  22. 30 Apr, 2013 3 commits
  23. 24 Apr, 2013 2 commits
  24. 10 Apr, 2013 1 commit
  25. 09 Apr, 2013 1 commit
  26. 02 Apr, 2013 1 commit
  27. 04 Mar, 2013 1 commit
    • Eric W. Biederman's avatar
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman authored
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  28. 23 Feb, 2013 1 commit