1. 20 Mar, 2013 31 commits
  2. 06 Mar, 2013 9 commits
    • Ben Hutchings's avatar
      Linux 3.2.40 · 733c7943
      Ben Hutchings authored
      733c7943
    • Theodore Ts'o's avatar
      ext4: fix kernel BUG on large-scale rm -rf commands · 933ef2d5
      Theodore Ts'o authored
      commit 89a4e48f upstream.
      
      Commit 968dee77: "ext4: fix hole punch failure when depth is greater
      than 0" introduced a regression in v3.5.1/v3.6-rc1 which caused kernel
      crashes when users ran run "rm -rf" on large directory hierarchy on
      ext4 filesystems on RAID devices:
      
          BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      
          Process rm (pid: 18229, threadinfo ffff8801276bc000, task ffff880123631710)
          Call Trace:
           [<ffffffff81236483>] ? __ext4_handle_dirty_metadata+0x83/0x110
           [<ffffffff812353d3>] ext4_ext_truncate+0x193/0x1d0
           [<ffffffff8120a8cf>] ? ext4_mark_inode_dirty+0x7f/0x1f0
           [<ffffffff81207e05>] ext4_truncate+0xf5/0x100
           [<ffffffff8120cd51>] ext4_evict_inode+0x461/0x490
           [<ffffffff811a1312>] evict+0xa2/0x1a0
           [<ffffffff811a1513>] iput+0x103/0x1f0
           [<ffffffff81196d84>] do_unlinkat+0x154/0x1c0
           [<ffffffff8118cc3a>] ? sys_newfstatat+0x2a/0x40
           [<ffffffff81197b0b>] sys_unlinkat+0x1b/0x50
           [<ffffffff816135e9>] system_call_fastpath+0x16/0x1b
          Code: 8b 4d 20 0f b7 41 02 48 8d 04 40 48 8d 04 81 49 89 45 18 0f b7 49 02 48 83 c1 01 49 89 4d 00 e9 ae f8 ff ff 0f 1f 00 49 8b 45 28 <48> 8b 40 28 49 89 45 20 e9 85 f8 ff ff 0f 1f 80 00 00 00
      
          RIP  [<ffffffff81233164>] ext4_ext_remove_space+0xa34/0xdf0
      
      This could be reproduced as follows:
      
      The problem in commit 968dee77 was that caused the variable 'i' to
      be left uninitialized if the truncate required more space than was
      available in the journal.  This resulted in the function
      ext4_ext_truncate_extend_restart() returning -EAGAIN, which caused
      ext4_ext_remove_space() to restart the truncate operation after
      starting a new jbd2 handle.
      Reported-by: default avatarMaciej Żenczykowski <maze@google.com>
      Reported-by: default avatarMarti Raudsepp <marti@juffo.org>
      Tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      933ef2d5
    • Ashish Sangwan's avatar
      ext4: fix hole punch failure when depth is greater than 0 · e5a563d1
      Ashish Sangwan authored
      commit 968dee77 upstream.
      
      Whether to continue removing extents or not is decided by the return
      value of function ext4_ext_more_to_rm() which checks 2 conditions:
      a) if there are no more indexes to process.
      b) if the number of entries are decreased in the header of "depth -1".
      
      In case of hole punch, if the last block to be removed is not part of
      the last extent index than this index will not be deleted, hence the
      number of valid entries in the extent header of "depth - 1" will
      remain as it is and ext4_ext_more_to_rm will return 0 although the
      required blocks are not yet removed.
      
      This patch fixes the above mentioned problem as instead of removing
      the extents from the end of file, it starts removing the blocks from
      the particular extent from which removing blocks is actually required
      and continue backward until done.
      Signed-off-by: default avatarAshish Sangwan <ashish.sangwan2@gmail.com>
      Signed-off-by: default avatarNamjae Jeon <linkinjeon@gmail.com>
      Reviewed-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e5a563d1
    • Lukas Czerner's avatar
      ext4: rewrite punch hole to use ext4_ext_remove_space() · 00fa8c8d
      Lukas Czerner authored
      commit 5f95d21f upstream.
      
      This commit rewrites ext4 punch hole implementation to use
      ext4_ext_remove_space() instead of its home gown way of doing this via
      ext4_ext_map_blocks(). There are several reasons for changing this.
      
      Firstly it is quite non obvious that punching hole needs to
      ext4_ext_map_blocks() to punch a hole, especially given that this
      function should map blocks, not unmap it. It also required a lot of new
      code in ext4_ext_map_blocks().
      
      Secondly the design of it is not very effective. The reason is that we
      are trying to punch out blocks in ext4_ext_punch_hole() in opposite
      direction than in ext4_ext_rm_leaf() which causes the ext4_ext_rm_leaf()
      to iterate through the whole tree from the end to the start to find the
      requested extent for every extent we are going to punch out.
      
      And finally the current implementation does not use the existing code,
      but bring a lot of new code, which is IMO unnecessary since there
      already is some infrastructure we can use. Specifically
      ext4_ext_remove_space().
      
      This commit changes ext4_ext_remove_space() to accept 'end' parameter so
      we can not only truncate to the end of file, but also remove the space
      in the middle of the file (punch a hole). Moreover, because the last
      block to punch out, might be in the middle of the extent, we have to
      split the extent at 'end + 1' so ext4_ext_rm_leaf() can easily either
      remove the whole fist part of split extent, or change its size.
      
      ext4_ext_remove_space() is then used to actually remove the space
      (extents) from within the hole, instead of ext4_ext_map_blocks().
      
      Note that this also fix the issue with punch hole, where we would forget
      to remove empty index blocks from the extent tree, resulting in double
      free block error and file system corruption. This is simply because we
      now use different code path, where this problem does not exist.
      
      This has been tested with fsx running for several days and xfstests,
      plus xfstest #251 with '-o discard' run on the loop image (which
      converts discard requestes into punch hole to the backing file). All of
      it on 1K and 4K file system block size.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      [bwh: Backported to 3.2.y: move EXT4_EXT_DATA_VALID{1,2} along with the
       other extent splitting flags]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      00fa8c8d
    • Justin Lecher's avatar
      fs: cachefiles: add support for large files in filesystem caching · 55a058d4
      Justin Lecher authored
      commit 98c350cd upstream.
      
      Support the caching of large files.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=31182Signed-off-by: default avatarJustin Lecher <jlec@gentoo.org>
      Signed-off-by: default avatarSuresh Jayaraman <sjayaraman@suse.com>
      Tested-by: default avatarSuresh Jayaraman <sjayaraman@suse.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.2:
       - Adjust context
       - dentry_open() takes dentry and vfsmount pointers, not a path pointer]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      55a058d4
    • Kees Cook's avatar
      exec: use -ELOOP for max recursion depth · 511d07bc
      Kees Cook authored
      commit d7402698 upstream.
      
      To avoid an explosion of request_module calls on a chain of abusive
      scripts, fail maximum recursion with -ELOOP instead of -ENOEXEC. As soon
      as maximum recursion depth is hit, the error will fail all the way back
      up the chain, aborting immediately.
      
      This also has the side-effect of stopping the user's shell from attempting
      to reexecute the top-level file as a shell script. As seen in the
      dash source:
      
              if (cmd != path_bshell && errno == ENOEXEC) {
                      *argv-- = cmd;
                      *argv = cmd = path_bshell;
                      goto repeat;
              }
      
      The above logic was designed for running scripts automatically that lacked
      the "#!" header, not to re-try failed recursion. On a legitimate -ENOEXEC,
      things continue to behave as the shell expects.
      
      Additionally, when tracking recursion, the binfmt handlers should not be
      involved. The recursion being tracked is the depth of calls through
      search_binary_handler(), so that function should be exclusively responsible
      for tracking the depth.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: halfdog <me@halfdog.net>
      Cc: P J P <ppandit@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      511d07bc
    • Oleg Nesterov's avatar
      kmod: make __request_module() killable · d0820f80
      Oleg Nesterov authored
      commit 1cc684ab upstream.
      
      As Tetsuo Handa pointed out, request_module() can stress the system
      while the oom-killed caller sleeps in TASK_UNINTERRUPTIBLE.
      
      The task T uses "almost all" memory, then it does something which
      triggers request_module().  Say, it can simply call sys_socket().  This
      in turn needs more memory and leads to OOM.  oom-killer correctly
      chooses T and kills it, but this can't help because it sleeps in
      TASK_UNINTERRUPTIBLE and after that oom-killer becomes "disabled" by the
      TIF_MEMDIE task T.
      
      Make __request_module() killable.  The only necessary change is that
      call_modprobe() should kmalloc argv and module_name, they can't live in
      the stack if we use UMH_KILLABLE.  This memory is freed via
      call_usermodehelper_freeinfo()->cleanup.
      Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d0820f80
    • Oleg Nesterov's avatar
      kmod: introduce call_modprobe() helper · 95b467ca
      Oleg Nesterov authored
      commit 3e63a93b upstream.
      
      No functional changes.  Move the call_usermodehelper code from
      __request_module() into the new simple helper, call_modprobe().
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      95b467ca
    • Oleg Nesterov's avatar
      usermodehelper: ____call_usermodehelper() doesn't need do_exit() · 9aa0f9b3
      Oleg Nesterov authored
      commit 5b9bd473 upstream.
      
      Minor cleanup.  ____call_usermodehelper() can simply return, no need to
      call do_exit() explicitely.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9aa0f9b3