1. 25 7月, 2012 1 次提交
  2. 20 1月, 2011 1 次提交
  3. 09 8月, 2010 1 次提交
  4. 13 7月, 2010 1 次提交
    • A
      net: autoconvert trivial BKL users to private mutex · 15fd0cd9
      Arnd Bergmann 提交于
      All these files use the big kernel lock in a trivial
      way to serialize their private file operations,
      typically resulting from an earlier semi-automatic
      pushdown from VFS.
      
      None of these drivers appears to want to lock against
      other code, and they all use the BKL as the top-level
      lock in their file operations, meaning that there
      is no lock-order inversion problem.
      
      Consequently, we can remove the BKL completely,
      replacing it with a per-file mutex in every case.
      Using a scripted approach means we can avoid
      typos.
      
      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>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15fd0cd9
  5. 13 7月, 2009 1 次提交
  6. 27 2月, 2009 1 次提交
    • H
      wanrouter: fix sparse warnings: context imbalance · 9ee62630
      Hannes Eder 提交于
      Impact: Attribute functions with __acquires(...) resp. __releases(...).
      
      Fix this sparse warnings:
        net/wanrouter/wanproc.c:82:13: warning: context imbalance in 'r_start' - wrong count at exit
        net/wanrouter/wanproc.c:103:13: warning: context imbalance in 'r_stop' - unexpected unlock
        net/wanrouter/wanmain.c:765:13: warning: context imbalance in 'lock_adapter_irq' - wrong count at exit
        net/wanrouter/wanmain.c:771:13: warning: context imbalance in 'unlock_adapter_irq' - unexpected unlock
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ee62630
  7. 20 11月, 2008 1 次提交
  8. 24 7月, 2008 2 次提交
  9. 26 5月, 2008 1 次提交
  10. 03 8月, 2007 1 次提交
  11. 04 6月, 2007 1 次提交
  12. 26 4月, 2007 2 次提交
  13. 11 2月, 2007 1 次提交
  14. 09 2月, 2007 1 次提交
  15. 07 12月, 2006 1 次提交
  16. 30 11月, 2006 1 次提交
  17. 22 7月, 2006 1 次提交
  18. 01 7月, 2006 1 次提交
  19. 12 1月, 2006 1 次提交
  20. 09 11月, 2005 1 次提交
  21. 13 7月, 2005 1 次提交
  22. 01 5月, 2005 1 次提交
    • J
      [PATCH] misc verify_area cleanups · e49332bd
      Jesper Juhl 提交于
      There were still a few comments left refering to verify_area, and two
      functions, verify_area_skas & verify_area_tt that just wrap corresponding
      access_ok_skas & access_ok_tt functions, just like verify_area does for
      access_ok - deprecate those.
      
      There was also a few places that still used verify_area in commented-out
      code, fix those up to use access_ok.
      
      After applying this one there should not be anything left but finally
      removing verify_area completely, which will happen after a kernel release
      or two.
      Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e49332bd
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4