1. 12 3月, 2011 3 次提交
  2. 10 3月, 2011 1 次提交
  3. 19 1月, 2011 1 次提交
  4. 11 1月, 2011 1 次提交
  5. 21 12月, 2010 1 次提交
  6. 17 12月, 2010 1 次提交
  7. 17 11月, 2010 1 次提交
  8. 10 11月, 2010 1 次提交
    • J
      cciss: fix proc warning on attempt to remove non-existant directory · 90fdb0b9
      Jens Axboe 提交于
      Randy reports that he gets the following stack trace when
      removing the cciss module:
      
      [  109.164277] Pid: 3463, comm: rmmod Not tainted 2.6.37-rc1 #7
      [  109.164280] Call Trace:
      [  109.164292]  [<ffffffff8107eb8d>] warn_slowpath_common+0xc6/0xf3
      [  109.164299]  [<ffffffff8107ecaa>] warn_slowpath_fmt+0x5b/0x6b
      [  109.164307]  [<ffffffff8155175b>] ? _raw_spin_unlock+0x40/0x4b
      [  109.164313]  [<ffffffff8123dd1e>] remove_proc_entry+0x156/0x35e
      [  109.164320]  [<ffffffff812cd91b>] ? do_raw_spin_unlock+0xff/0x10f
      [  109.164327]  [<ffffffff8113823d>] ? trace_hardirqs_on+0x10/0x4a
      [  109.164333]  [<ffffffff8155162d>] ? _raw_spin_unlock_irq+0x4c/0x7b
      [  109.164339]  [<ffffffff8154d4d1>] ? wait_for_common+0x145/0x15e
      [  109.164345]  [<ffffffff81075337>] ? default_wake_function+0x0/0x22
      [  109.164357]  [<ffffffffa0615a8f>] cciss_cleanup+0xa9/0xc7 [cciss]
      [  109.164365]  [<ffffffff810d3cb0>] sys_delete_module+0x2d6/0x368
      [  109.164371]  [<ffffffff8155036b>] ? lockdep_sys_exit_thunk+0x35/0x67
      [  109.164377]  [<ffffffff810fdfaf>] ? audit_syscall_entry+0x172/0x1a5
      [  109.164383]  [<ffffffff815502f5>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  109.164389]  [<ffffffff8100ea72>] system_call_fastpath+0x16/0x1b
      [  109.164394] ---[ end trace 88e8568246ed0b1d ]---
      
      which will happen if you don't actually have an HP CISS adapter,
      since it'll do an uncondional removal of a proc directory it
      never attempted to create in that case.
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Tested-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      90fdb0b9
  9. 28 10月, 2010 2 次提交
  10. 24 10月, 2010 5 次提交
  11. 19 10月, 2010 1 次提交
  12. 05 10月, 2010 1 次提交
    • A
      block: autoconvert trivial BKL users to private mutex · 2a48fc0a
      Arnd Bergmann 提交于
      The block device drivers have all gained new lock_kernel
      calls from a recent pushdown, and some of the drivers
      were already using the BKL before.
      
      This turns the BKL into a set of per-driver mutexes.
      Still need to check whether this is safe to do.
      
      file=$1
      name=$2
      if grep -q lock_kernel ${file} ; then
          if grep -q 'include.*linux.mutex.h' ${file} ; then
                  sed -i '/include.*<linux\/smp_lock.h>/d' ${file}
          else
                  sed -i 's/include.*<linux\/smp_lock.h>.*$/include <linux\/mutex.h>/g' ${file}
          fi
          sed -i ${file} \
              -e "/^#include.*linux.mutex.h/,$ {
                      1,/^\(static\|int\|long\)/ {
                           /^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex);
      
      } }"  \
          -e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
          -e '/[      ]*cycle_kernel_lock();/d'
      else
          sed -i -e '/include.*\<smp_lock.h\>/d' ${file}  \
                      -e '/cycle_kernel_lock()/d'
      fi
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2a48fc0a
  13. 21 9月, 2010 1 次提交
    • D
      cciss: freeing uninitialized data on error path · b0722cb1
      Dan Carpenter 提交于
      The "h->scatter_list" is allocated inside a for loop.  If any of those
      allocations fail, then the rest of the list is uninitialized data.  When
      we free it we should start from the top and free backwards so that we
      don't call kfree() on uninitialized pointers.
      
      Also if the allocation for "h->scatter_list" fails then we would get an
      Oops here.  I should have noticed this when I send: 4ee69851 "cciss:
      handle allocation failure."  but I didn't.  Sorry about that.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      b0722cb1
  14. 10 9月, 2010 13 次提交
  15. 26 8月, 2010 1 次提交
  16. 23 8月, 2010 2 次提交
  17. 08 8月, 2010 4 次提交