1. 22 10月, 2009 1 次提交
    • E
      fs: pipe.c null pointer dereference · ad396024
      Earl Chew 提交于
      This patch fixes a null pointer exception in pipe_rdwr_open() which
      generates the stack trace:
      
      > Unable to handle kernel NULL pointer dereference at 0000000000000028 RIP:
      >  [<ffffffff802899a5>] pipe_rdwr_open+0x35/0x70
      >  [<ffffffff8028125c>] __dentry_open+0x13c/0x230
      >  [<ffffffff8028143d>] do_filp_open+0x2d/0x40
      >  [<ffffffff802814aa>] do_sys_open+0x5a/0x100
      >  [<ffffffff8021faf3>] sysenter_do_call+0x1b/0x67
      
      The failure mode is triggered by an attempt to open an anonymous
      pipe via /proc/pid/fd/* as exemplified by this script:
      
      =============================================================
      while : ; do
         { echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
         PID=$!
         OUT=$(ps -efl | grep 'sleep 1' | grep -v grep |
              { read PID REST ; echo $PID; } )
         OUT="${OUT%% *}"
         DELAY=$((RANDOM * 1000 / 32768))
         usleep $((DELAY * 1000 + RANDOM % 1000 ))
         echo n > /proc/$OUT/fd/1                 # Trigger defect
      done
      =============================================================
      
      Note that the failure window is quite small and I could only
      reliably reproduce the defect by inserting a small delay
      in pipe_rdwr_open(). For example:
      
       static int
       pipe_rdwr_open(struct inode *inode, struct file *filp)
       {
             msleep(100);
             mutex_lock(&inode->i_mutex);
      
      Although the defect was observed in pipe_rdwr_open(), I think it
      makes sense to replicate the change through all the pipe_*_open()
      functions.
      
      The core of the change is to verify that inode->i_pipe has not
      been released before attempting to manipulate it. If inode->i_pipe
      is no longer present, return ENOENT to indicate so.
      
      The comment about potentially using atomic_t for i_pipe->readers
      and i_pipe->writers has also been removed because it is no longer
      relevant in this context. The inode->i_mutex lock must be used so
      that inode->i_pipe can be dealt with correctly.
      Signed-off-by: NEarl Chew <earl_chew@agilent.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ad396024
  2. 15 10月, 2009 2 次提交
  3. 14 10月, 2009 9 次提交
    • C
      Btrfs: always pin metadata in discard mode · 444528b3
      Chris Mason 提交于
      We have an optimization in btrfs to allow blocks to be
      immediately freed if they were allocated in this transaction and never
      written.  Otherwise they are pinned and freed when the transaction
      commits.
      
      This isn't optimal for discard mode because immediately freeing
      them means immediately discarding them.  It is better to give the
      block to the pinning code and letting the (slow) discard happen later.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      444528b3
    • C
      Btrfs: enable discard support · 06348574
      Christoph Hellwig 提交于
      The discard support code in btrfs currently is guarded by ifdefs for
      BIO_RW_DISCARD, which is never defines as it's the name of an enum
      memeber.  Just remove the useless ifdefs to actually enable the code.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      06348574
    • C
      Btrfs: add -o discard option · e244a0ae
      Christoph Hellwig 提交于
      Enable discard by default is not a good idea given the the trim speed
      of SSD prototypes we've seen, and the carecteristics for many high-end
      arrays.  Turn of discards by default and require the -o discard option
      to enable them on.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      e244a0ae
    • Y
      Btrfs: properly wait log writers during log sync · 86df7eb9
      Yan, Zheng 提交于
      A recently fsync optimization make btrfs_sync_log skip calling
      wait_for_writer in the single log writer case. This is incorrect
      since the writer count can also be increased by btrfs_pin_log.
      Signed-off-by: NYan Zheng <zheng.yan@oracle.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      86df7eb9
    • J
      Btrfs: fix possible ENOSPC problems with truncate · 5d5e103a
      Josef Bacik 提交于
      There's a problem where we don't do any space reservation for truncates, which
      can cause you to OOPs because you will be allowed to go off in the weeds a bit
      since we don't account for the delalloc bytes that are created as a result of
      the truncate.
      Signed-off-by: NJosef Bacik <jbacik@redhat.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      5d5e103a
    • C
      Btrfs: fix btrfs acl #ifdef checks · 0eda294d
      Chris Mason 提交于
      The btrfs acl code was #ifdefing for a define
      that didn't exist.  This correctly matches it
      to the values used by the Kconfig file.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      0eda294d
    • C
      Btrfs: streamline tree-log btree block writeout · 690587d1
      Chris Mason 提交于
      Syncing the tree log is a 3 phase operation.
      
      1) write and wait for all the tree log blocks for a given root.
      
      2) write and wait for all the tree log blocks for the
      tree of tree log roots.
      
      3) write and wait for the super blocks (barriers here)
      
      This isn't as efficient as it could be because there is
      no requirement to wait for the blocks from step one to hit the disk
      before we start writing the blocks from step two.  This commit
      changes the sequence so that we don't start waiting until
      all the tree blocks from both steps one and two have been sent
      to disk.
      
      We do this by breaking up btrfs_write_wait_marked_extents into
      two functions, which is trivial because it was already broken
      up into two parts.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      690587d1
    • C
      Btrfs: avoid tree log commit when there are no changes · 257c62e1
      Chris Mason 提交于
      rpm has a habit of running fdatasync when the file hasn't
      changed.  We already detect if a file hasn't been changed
      in the current transaction but it might have been sent to
      the tree-log in this transaction and not changed since
      the last call to fsync.
      
      In this case, we want to avoid a tree log sync, which includes
      a number of synchronous writes and barriers.  This commit
      extends the existing tracking of the last transaction to change
      a file to also track the last sub-transaction.
      
      The end result is that rpm -ivh and -Uvh are roughly twice as fast,
      and on par with ext3.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      257c62e1
    • C
      Btrfs: only write one super copy during fsync · 4722607d
      Chris Mason 提交于
      During a tree-log commit for fsync, we've been writing at least
      two copies of the super block and forcing them to disk.
      
      The other filesystems write only one, and this change brings us on
      par with them.  A full transaction commit will write all the super
      copies, so we still have redundant info written on a regular
      basis.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      4722607d
  4. 13 10月, 2009 2 次提交
  5. 12 10月, 2009 2 次提交
  6. 09 10月, 2009 20 次提交
  7. 08 10月, 2009 3 次提交
  8. 07 10月, 2009 1 次提交
    • T
      NFSv4: Fix the referral mount code · 517be09d
      Trond Myklebust 提交于
      Fix a typo which causes try_location() to use the wrong length argument
      when calling nfs_parse_server_name(). This again, causes the initialisation
      of the mount's sockaddr structure to fail.
      
      Also ensure that if nfs4_pathname_string() returns an error, then we pass
      that error back up the stack instead of ENOENT.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      517be09d