1. 29 Feb, 2012 1 commit
  2. 14 Feb, 2012 1 commit
  3. 04 Jan, 2012 2 commits
  4. 01 Nov, 2011 1 commit
    • Christopher Yeoh's avatar
      Cross Memory Attach · fcf63409
      Christopher Yeoh authored
      The basic idea behind cross memory attach is to allow MPI programs doing
      intra-node communication to do a single copy of the message rather than a
      double copy of the message via shared memory.
      The following patch attempts to achieve this by allowing a destination
      process, given an address and size from a source process, to copy memory
      directly from the source process into its own address space via a system
      call.  There is also a symmetrical ability to copy from the current
      process's address space into a destination process's address space.
      - Use of /proc/pid/mem has been considered, but there are issues with
        using it:
        - Does not allow for specifying iovecs for both src and dest, assuming
          preadv or pwritev was implemented either the area read from or
        written to would need to be contiguous.
        - Currently mem_read allows only processes who are currently
        ptrace'ing the target and are still able to ptrace the target to read
        from the target. This check could possibly be moved to the open call,
        but its not clear exactly what race this restriction is stopping
        (reason  appears to have been lost)
        - Having to send the fd of /proc/self/mem via SCM_RIGHTS on unix
        domain socket is a bit ugly from a userspace point of view,
        especially when you may have hundreds if not (eventually) thousands
        of processes  that all need to do this with each other
        - Doesn't allow for some future use of the interface we would like to
        consider adding in the future (see below)
        - Interestingly reading from /proc/pid/mem currently actually
        involves two copies! (But this could be fixed pretty easily)
      As mentioned previously use of vmsplice instead was considered, but has
      problems.  Since you need the reader and writer working co-operatively if
      the pipe is not drained then you block.  Which requires some wrapping to
      do non blocking on the send side or polling on the receive.  In all to all
      communication it requires ordering otherwise you can deadlock.  And in the
      example of many MPI tasks writing to one MPI task vmsplice serialises the
      There are some cases of MPI collectives where even a single copy interface
      does not get us the performance gain we could.  For example in an
      MPI_Reduce rather than copy the data from the source we would like to
      instead use it directly in a mathops (say the reduce is doing a sum) as
      this would save us doing a copy.  We don't need to keep a copy of the data
      from the source.  I haven't implemented this, but I think this interface
      could in the future do all this through the use of the flags - eg could
      specify the math operation and type and the kernel rather than just
      copying the data would apply the specified operation between the source
      and destination and store it in the destination.
      Although we don't have a "second user" of the interface (though I've had
      some nibbles from people who may be interested in using it for intra
      process messaging which is not MPI).  This interface is something which
      hardware vendors are already doing for their custom drivers to implement
      fast local communication.  And so in addition to this being useful for
      OpenMPI it would mean the driver maintainers don't have to fix things up
      when the mm changes.
      There was some discussion about how much faster a true zero copy would
      go. Here's a link back to the email with some testing I did on that:
      There is a basic man page for the proposed interface here:
      This has been implemented for x86 and powerpc, other architecture should
      mainly (I think) just need to add syscall numbers for the process_vm_readv
      and process_vm_writev. There are 32 bit compatibility versions for
      64-bit kernels.
      For arch maintainers there are some simple tests to be able to quickly
      verify that the syscalls are working correctly here:
      http://ozlabs.org/~cyeoh/cma/cma-test-20110718.tgzSigned-off-by: default avatarChris Yeoh <yeohc@au1.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: <linux-man@vger.kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 28 Oct, 2011 1 commit
    • Eric W. Biederman's avatar
      compat: sync compat_stats with statfs. · 1448c721
      Eric W. Biederman authored
      This was found by inspection while tracking a similar
      bug in compat_statfs64, that has been fixed in mainline
      since decemeber.
      - This fixes a bug where not all of the f_spare fields
        were cleared on mips and s390.
      - Add the f_flags field to struct compat_statfs
      - Copy f_flags to userspace in case someone cares.
      - Use __clear_user to copy the f_spare field to userspace
        to ensure that all of the elements of f_spare are cleared.
        On some architectures f_spare is has 5 ints and on some
        architectures f_spare only has 4 ints.  Which makes
        the previous technique of clearing each int individually
      I don't expect anyone actually uses the old statfs system
      call anymore but if they do let them benefit from having
      the compat and the native version working the same.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
  6. 31 Aug, 2011 1 commit
  7. 26 Aug, 2011 1 commit
  8. 15 Jul, 2011 1 commit
    • NeilBrown's avatar
      nfsd: Remove deprecated nfsctl system call and related code. · 49b28684
      NeilBrown authored
      As promised in feature-removal-schedule.txt it is time to
      remove the nfsctl system call.
      Userspace has perferred to not use this call throughout 2.6 and it has been
      excluded in the default configuration since 2.6.36 (9 months ago).
      So this patch removes all the code that was being compiled out.
      There are still references to sys_nfsctl in various arch systemcall tables
      and related code.  These should be cleaned out too, probably in the next
      merge window.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
  9. 09 Apr, 2011 1 commit
  10. 21 Mar, 2011 1 commit
  11. 15 Mar, 2011 1 commit
  12. 14 Mar, 2011 1 commit
    • Al Viro's avatar
      clean statfs-like syscalls up · c8b91acc
      Al Viro authored
      New helpers: user_statfs() and fd_statfs(), taking userland pathname and
      descriptor resp. and filling struct kstatfs.  Syscalls of statfs family
      (native, compat and foreign - osf and hpux on alpha and parisc resp.)
      switched to those.  Removes some boilerplate code, simplifies cleanup
      on errors...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  13. 13 Mar, 2011 2 commits
  14. 17 Jan, 2011 3 commits
  15. 01 Dec, 2010 1 commit
    • Oleg Nesterov's avatar
      exec: copy-and-paste the fixes into compat_do_execve() paths · 114279be
      Oleg Nesterov authored
      Note: this patch targets 2.6.37 and tries to be as simple as possible.
      That is why it adds more copy-and-paste horror into fs/compat.c and
      uglifies fs/exec.c, this will be cleanuped later.
      compat_copy_strings() plays with bprm->vma/mm directly and thus has
      two problems: it lacks the RLIMIT_STACK check and argv/envp memory
      is not visible to oom killer.
      Export acct_arg_size() and get_arg_page(), change compat_copy_strings()
      to use get_arg_page(), change compat_do_execve() to do acct_arg_size(0)
      as do_execve() does.
      Add the fatal_signal_pending/cond_resched checks into compat_count() and
      compat_copy_strings(), this matches the code in fs/exec.c and certainly
      makes sense.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 30 Oct, 2010 1 commit
    • wu zhangjin's avatar
      fs/compat.c: fix build on MIPS/s390 · 504b701b
      wu zhangjin authored
      The definition of PAGE_CACHE_MASK in <linux/pagemap.h> is needed to use
      MAX_RW_COUNT, and on x86-64 that gets done indirectly through the
      architecture header includes.  But on MIPS and s390 that doesn't happen,
      and we need to make sure that fs/compat.c includes pagemap.h explicitly.
      Introduced in commit 435f49a5 ("readv/writev: do the same
      MAX_RW_COUNT truncation that read/write does").
      Reported-by: Sachin Sant <sachinp@in.ibm.com> (S390)
      Reported-by: wu zhangjin <wuzhangjin@gmail.com> (MIPS)
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 29 Oct, 2010 1 commit
  18. 05 Oct, 2010 1 commit
  19. 23 Sep, 2010 1 commit
  20. 22 Sep, 2010 1 commit
  21. 13 Aug, 2010 1 commit
  22. 10 Aug, 2010 1 commit
    • Kevin Winchester's avatar
      vfs: fix warning: 'dirent' is used uninitialized in this function · 85c9fe8f
      Kevin Winchester authored
      	gcc (GCC) 4.5.0 20100610 (prerelease)
      The following warnings appear:
      	fs/readdir.c: In function `filldir64':
      	fs/readdir.c:240:15: warning: `dirent' is used uninitialized in this function
      	fs/readdir.c: In function `filldir':
      	fs/readdir.c:155:15: warning: `dirent' is used uninitialized in this function
      	fs/compat.c: In function `compat_filldir64':
      	fs/compat.c:1071:11: warning: `dirent' is used uninitialized in this function
      	fs/compat.c: In function `compat_filldir':
      	fs/compat.c:984:15: warning: `dirent' is used uninitialized in this function
      The warnings are related to the use of the NAME_OFFSET() macro.  Luckily,
      it appears as though the standard offsetof() macro is what is being
      implemented by NAME_OFFSET(), thus we can fix the warning and use a more
      standard code construct at the same time.
      Signed-off-by: default avatarKevin Winchester <kjwinchester@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  23. 09 Aug, 2010 1 commit
    • Christoph Hellwig's avatar
      pass a struct path to vfs_statfs · ebabe9a9
      Christoph Hellwig authored
      We'll need the path to implement the flags field for statvfs support.
      We do have it available in all callers except:
       - ecryptfs_statfs.  This one doesn't actually need vfs_statfs but just
         needs to do a caller to the lower filesystem statfs method.
       - sys_ustat.  Add a non-exported statfs_by_dentry helper for it which
         doesn't won't be able to fill out the flags field later on.
      In addition rename the helpers for statfs vs fstatfs to do_*statfs instead
      of the misleading vfs prefix.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
  24. 28 Jul, 2010 1 commit
    • Eric Paris's avatar
      fsnotify: pass a file instead of an inode to open, read, and write · 2a12a9d7
      Eric Paris authored
      fanotify, the upcoming notification system actually needs a struct path so it can
      do opens in the context of listeners, and it needs a file so it can get f_flags
      from the original process.  Close was the only operation that already was passing
      a struct file to the notification hook.  This patch passes a file for access,
      modify, and open as well as they are easily available to these hooks.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
  25. 19 Jul, 2010 1 commit
  26. 04 Jun, 2010 1 commit
  27. 27 May, 2010 2 commits
  28. 12 May, 2010 1 commit
    • Robin Holt's avatar
      revert "procfs: provide stack information for threads" and its fixup commits · 34441427
      Robin Holt authored
      Originally, commit d899bf7b ("procfs: provide stack information for
      threads") attempted to introduce a new feature for showing where the
      threadstack was located and how many pages are being utilized by the
      Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
      applied to fix the NO_MMU case.
      Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
      64-bit") was applied to fix a bug in ia32 executables being loaded.
      Commit 9ebd4eba ("procfs: fix /proc/<pid>/stat stack pointer for kernel
      threads") was applied to fix a bug which had kernel threads printing a
      userland stack address.
      Commit 1306d603 ('proc: partially revert "procfs: provide stack
      information for threads"') was then applied to revert the stack pages
      being used to solve a significant performance regression.
      This patch nearly undoes the effect of all these patches.
      The reason for reverting these is it provides an unusable value in
      field 28.  For x86_64, a fork will result in the task->stack_start
      value being updated to the current user top of stack and not the stack
      start address.  This unpredictability of the stack_start value makes
      it worthless.  That includes the intended use of showing how much stack
      space a thread has.
      Other architectures will get different values.  As an example, ia64
      gets 0.  The do_fork() and copy_process() functions appear to treat the
      stack_start and stack_size parameters as architecture specific.
      I only partially reverted c44972f1 ("procfs: disable per-task stack usage
      on NOMMU") .  If I had completely reverted it, I would have had to change
      mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
      configured.  Since I could not test the builds without significant effort,
      I decided to not change mm/Makefile.
      I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
      information for threads on 64-bit") .  I left the KSTK_ESP() change in
      place as that seemed worthwhile.
      Signed-off-by: default avatarRobin Holt <holt@sgi.com>
      Cc: Stefani Seibold <stefani@seibold.net>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  29. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      The script does the followings.
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
      The conversion was done in the following steps.
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
      6. percpu.h was updated not to include slab.h.
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
  30. 12 Mar, 2010 1 commit
  31. 14 Dec, 2009 1 commit
  32. 04 Nov, 2009 1 commit
    • Stefani Seibold's avatar
      x86, fs: Fix x86 procfs stack information for threads on 64-bit · 89240ba0
      Stefani Seibold authored
      This patch fixes two issues in the procfs stack information on
      x86-64 linux.
      The 32 bit loader compat_do_execve did not store stack
      start. (this was figured out by Alexey Dobriyan).
      The stack information on a x64_64 kernel always shows 0 kbyte
      stack usage, because of a missing implementation of the KSTK_ESP
      macro which always returned -1.
      The new implementation now returns the right value.
      Signed-off-by: default avatarStefani Seibold <stefani@seibold.net>
      Cc: Americo Wang <xiyou.wangcong@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <1257240160.4889.24.camel@wall-e>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  33. 24 Sep, 2009 1 commit
    • Vegard Nossum's avatar
      fs: fix overflow in sys_mount() for in-kernel calls · eca6f534
      Vegard Nossum authored
      sys_mount() reads/copies a whole page for its "type" parameter.  When
      do_mount_root() passes a kernel address that points to an object which is
      smaller than a whole page, copy_mount_options() will happily go past this
      memory object, possibly dereferencing "wild" pointers that could be in any
      state (hence the kmemcheck warning, which shows that parts of the next
      page are not even allocated).
      (The likelihood of something going wrong here is pretty low -- first of
      all this only applies to kernel calls to sys_mount(), which are mostly
      found in the boot code.  Secondly, I guess if the page was not mapped,
      exact_copy_from_user() _would_ in fact handle it correctly because of its
      access_ok(), etc.  checks.)
      But it is much nicer to avoid the dubious reads altogether, by stopping as
      soon as we find a NUL byte.  Is there a good reason why we can't do
      something like this, using the already existing strndup_from_user()?
      [akpm@linux-foundation.org: make copy_mount_string() static]
      [AV: fix compat mount breakage, which involves undoing akpm's change above]
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avataral <al@dizzy.pdmi.ras.ru>
  34. 23 Sep, 2009 1 commit
    • Suzuki Poulose's avatar
      fix compat_sys_utimensat() · d7d7561c
      Suzuki Poulose authored
      Compat utimensat() returns EINVAL when the tv_nsec is one of UTIME_OMIT or
      UTIME_NOW and the tv_sec is set to non-zero.  As per man pages, the tv_sec
      field should be ignored.
      sys_utimensat() works fine in this case.
      Test case:
      #define _GNU_SOURCE
      #define _ATFILE_SOURCE
      #include <stdio.h>
      #include <fcntl.h>
      #include <unistd.h>
      #include <sys/stat.h>
      #include <stdlib.h>
      main(int argc, char *argv[])
      	struct timespec ts[2];
      	struct timespec *tsp;
      	if (argc < 2) {
      		fprintf(stderr, "Usage : %s filename\n", argv[0]);
      		exit (-1);
      	ts[0].tv_nsec = ts[1].tv_nsec = UTIME_NOW;
      	ts[0].tv_sec = ts[1].tv_sec = 1;
      	tsp = ts;
      	if (utimensat(AT_FDCWD, argv[1],tsp,0) == -1)
      		fprintf(stdout, "utimensat success\n");
      	return 0;
      mjs22lp5:~ # cc -m64 utimensat-test.c -o utimensat_test64
      mjs22lp5:~ # cc -m32 utimensat-test.c -o utimensat_test32
      mjs22lp5:~ # ./utimensat_test32 /tmp/utimensat_test
      utimensat: Invalid argument
      mjs22lp5:~ # ./utimensat_test64 /tmp/utimensat_test
      utimensat success
      mjs22lp5:~ # uname -r
      With the patch :
      mjs22lp5:~ # ./utimensat_test64 /tmp/utimensat_test
      utimensat success
      mjs22lp5:~ # ./utimensat_test32 /tmp/utimensat_test
      utimensat success
      mjs22lp5:~ # uname -r
      Signed-off-by: default avatarSuzuki K P <suzuki@in.ibm.com>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  35. 05 Sep, 2009 1 commit
    • Oleg Nesterov's avatar
      exec: do not sleep in TASK_TRACED under ->cred_guard_mutex · a2a8474c
      Oleg Nesterov authored
      Tom Horsley reports that his debugger hangs when it tries to read
      /proc/pid_of_tracee/maps, this happens since
      	"mm_for_maps: take ->cred_guard_mutex to fix the race with exec"
      commit in 2.6.31.
      But the root of the problem lies in the fact that do_execve() path calls
      tracehook_report_exec() which can stop if the tracer sets PT_TRACE_EXEC.
      The tracee must not sleep in TASK_TRACED holding this mutex.  Even if we
      remove ->cred_guard_mutex from mm_for_maps() and proc_pid_attr_write(),
      another task doing PTRACE_ATTACH should not hang until it is killed or the
      tracee resumes.
      With this patch do_execve() does not use ->cred_guard_mutex directly and
      we do not hold it throughout, instead:
      	- introduce prepare_bprm_creds() helper, it locks the mutex
      	  and calls prepare_exec_creds() to initialize bprm->cred.
      	- install_exec_creds() drops the mutex after commit_creds(),
      	  and thus before tracehook_report_exec()->ptrace_stop().
      	  or, if exec fails,
      	  free_bprm() drops this mutex when bprm->cred != NULL which
      	  indicates install_exec_creds() was not called.
      Reported-by: default avatarTom Horsley <tom.horsley@att.net>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>