1. 07 Sep, 2014 1 commit
  2. 06 May, 2014 1 commit
  3. 02 Apr, 2014 1 commit
  4. 23 Mar, 2014 1 commit
    • Eric Biggers's avatar
      vfs: Don't let __fdget_pos() get FMODE_PATH files · 99aea681
      Eric Biggers authored
      Commit bd2a31d5 ("get rid of fget_light()") introduced the
      __fdget_pos() function, which returns the resulting file pointer and
      fdput flags combined in an 'unsigned long'.  However, it also changed the
      behavior to return files with FMODE_PATH set, which shouldn't happen
      because read(), write(), lseek(), etc. aren't allowed on such files.
      This commit restores the old behavior.
      This regression actually had no effect on read() and write() since
      FMODE_READ and FMODE_WRITE are not set on file descriptors opened with
      O_PATH, but it did cause lseek() on a file descriptor opened with O_PATH
      to fail with ESPIPE rather than EBADF.
      Signed-off-by: 's avatarEric Biggers <ebiggers3@gmail.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
  5. 10 Mar, 2014 1 commit
  6. 17 Feb, 2014 1 commit
  7. 11 Feb, 2014 1 commit
    • Eric W. Biederman's avatar
      fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem · 96c7a2ff
      Eric W. Biederman authored
      Recently due to a spike in connections per second memcached on 3
      separate boxes triggered the OOM killer from accept.  At the time the
      OOM killer was triggered there was 4GB out of 36GB free in zone 1.  The
      problem was that alloc_fdtable was allocating an order 3 page (32KiB) to
      hold a bitmap, and there was sufficient fragmentation that the largest
      page available was 8KiB.
      I find the logic that PAGE_ALLOC_COSTLY_ORDER can't fail pretty dubious
      but I do agree that order 3 allocations are very likely to succeed.
      There are always pathologies where order > 0 allocations can fail when
      there are copious amounts of free memory available.  Using the pigeon
      hole principle it is easy to show that it requires 1 page more than 50%
      of the pages being free to guarantee an order 1 (8KiB) allocation will
      succeed, 1 page more than 75% of the pages being free to guarantee an
      order 2 (16KiB) allocation will succeed and 1 page more than 87.5% of
      the pages being free to guarantee an order 3 allocate will succeed.
      A server churning memory with a lot of small requests and replies like
      memcached is a common case that if anything can will skew the odds
      against large pages being available.
      Therefore let's not give external applications a practical way to kill
      linux server applications, and specify __GFP_NORETRY to the kmalloc in
      alloc_fdmem.  Unless I am misreading the code and by the time the code
      reaches should_alloc_retry in __alloc_pages_slowpath (where
      __GFP_NORETRY becomes signification).  We have already tried everything
      reasonable to allocate a page and the only thing left to do is wait.  So
      not waiting and falling back to vmalloc immediately seems like the
      reasonable thing to do even if there wasn't a chance of triggering the
      OOM killer.
      Signed-off-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Acked-by: 's avatarDavid Rientjes <rientjes@google.com>
      Cc: Cong Wang <cwang@twopensource.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 25 Jan, 2014 5 commits
  9. 01 May, 2013 1 commit
  10. 19 Feb, 2013 1 commit
  11. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      misc: remove __dev* attributes. · 6ae14171
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      This change removes the last of the __dev* markings from the kernel from
      a variety of different, tiny, places.
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 30 Nov, 2012 1 commit
  13. 29 Nov, 2012 1 commit
  14. 12 Nov, 2012 1 commit
  15. 31 Oct, 2012 1 commit
  16. 10 Oct, 2012 1 commit
    • Richard W.M. Jones's avatar
      dup3: Return an error when oldfd == newfd. · aed97647
      Richard W.M. Jones authored
      I have tested the attached patch to fix the dup3 regression.
      From 0944e30e12dec6544b3602626b60ff412375c78f Mon Sep 17 00:00:00 2001
      From: "Richard W.M. Jones" <rjones@redhat.com>
      Date: Tue, 9 Oct 2012 14:42:45 +0100
      Subject: [PATCH] dup3: Return an error when oldfd == newfd.
      The following commit:
        commit fe17f22d
        Author: Al Viro <viro@zeniv.linux.org.uk>
        Date:   Tue Aug 21 11:48:11 2012 -0400
          take purely descriptor-related stuff from fcntl.c to file.c
      was supposed to be just code motion, but it dropped the following two
        if (unlikely(oldfd == newfd))
                return -EINVAL;
      from the dup3 system call.  dup3 is not specified by POSIX, so Linux
      can do what it likes.  However the POSIX proposal for dup3 [1] states
      that it should return an error if oldfd == newfd.
      [1] http://austingroupbugs.net/view.php?id=411Signed-off-by: 's avatarRichard W.M. Jones <rjones@redhat.com>
      Tested-by: 's avatarRichard W.M. Jones <rjones@redhat.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
  17. 27 Sep, 2012 18 commits
  18. 29 Feb, 2012 1 commit
  19. 24 Feb, 2012 1 commit