1. 10 8月, 2013 1 次提交
  2. 03 8月, 2013 1 次提交
  3. 25 7月, 2013 1 次提交
  4. 02 7月, 2013 1 次提交
    • D
      net: sctp: rework debugging framework to use pr_debug and friends · bb33381d
      Daniel Borkmann 提交于
      We should get rid of all own SCTP debug printk macros and use the ones
      that the kernel offers anyway instead. This makes the code more readable
      and conform to the kernel code, and offers all the features of dynamic
      debbuging that pr_debug() et al has, such as only turning on/off portions
      of debug messages at runtime through debugfs. The runtime cost of having
      CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
      is negligible [1]. If kernel debugging is completly turned off, then these
      statements will also compile into "empty" functions.
      
      While we're at it, we also need to change the Kconfig option as it /now/
      only refers to the ifdef'ed code portions in outqueue.c that enable further
      debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
      was enabled with this Kconfig option and has now been removed, we
      transform those code parts into WARNs resp. where appropriate BUG_ONs so
      that those bugs can be more easily detected as probably not many people
      have SCTP debugging permanently turned on.
      
      To turn on all SCTP debugging, the following steps are needed:
      
       # mount -t debugfs none /sys/kernel/debug
       # echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
      
      This can be done more fine-grained on a per file, per line basis and others
      as described in [2].
      
       [1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
       [2] Documentation/dynamic-debug-howto.txt
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb33381d
  5. 18 6月, 2013 2 次提交
  6. 13 6月, 2013 1 次提交
  7. 29 5月, 2013 1 次提交
  8. 14 2月, 2013 1 次提交
  9. 01 12月, 2012 1 次提交
    • T
      sctp: fix CONFIG_SCTP_DBG_MSG=y null pointer dereference in sctp_v6_get_dst() · ee3f34e8
      Tommi Rantala 提交于
      Trinity (the syscall fuzzer) triggered the following BUG, reproducible
      only when the kernel is configured with CONFIG_SCTP_DBG_MSG=y.
      
      When CONFIG_SCTP_DBG_MSG is not set, the null pointer is never
      dereferenced.
      
      ---[ end trace a4de0bfcb38a3642 ]---
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
      IP: [<ffffffff8136796e>] ip6_string+0x1e/0xa0
      PGD 4eead067 PUD 4e472067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in:
      CPU 3
      Pid: 21324, comm: trinity-child11 Tainted: G        W    3.7.0-rc7+ #61 ASUSTeK Computer INC. EB1012/EB1012
      RIP: 0010:[<ffffffff8136796e>]  [<ffffffff8136796e>] ip6_string+0x1e/0xa0
      RSP: 0018:ffff88004e4637a0  EFLAGS: 00010046
      RAX: ffff88004e4637da RBX: ffff88004e4637da RCX: 0000000000000000
      RDX: ffffffff8246e92a RSI: 0000000000000100 RDI: ffff88004e4637da
      RBP: ffff88004e4637a8 R08: 000000000000ffff R09: 000000000000ffff
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8289d600
      R13: ffffffff8289d230 R14: ffffffff8246e928 R15: ffffffff8289d600
      FS:  00007fed95153700(0000) GS:ffff88005fd80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000100 CR3: 000000004eeac000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process trinity-child11 (pid: 21324, threadinfo ffff88004e462000, task ffff8800524b0000)
      Stack:
       ffff88004e4637da ffff88004e463828 ffffffff81368eee 000000004e4637d8
       ffffffff0000ffff ffff88000000ffff 0000000000000000 000000004e4637f8
       ffffffff826285d8 ffff88004e4637f8 0000000000000000 ffff8800524b06b0
      Call Trace:
       [<ffffffff81368eee>] ip6_addr_string.isra.11+0x3e/0xa0
       [<ffffffff81369183>] pointer.isra.12+0x233/0x2d0
       [<ffffffff810a413a>] ? vprintk_emit+0x1ba/0x450
       [<ffffffff8110953d>] ? trace_hardirqs_on_caller+0x10d/0x1a0
       [<ffffffff81369757>] vsnprintf+0x187/0x5d0
       [<ffffffff81369c62>] vscnprintf+0x12/0x30
       [<ffffffff810a4028>] vprintk_emit+0xa8/0x450
       [<ffffffff81e5cb00>] printk+0x49/0x4b
       [<ffffffff81d17221>] sctp_v6_get_dst+0x731/0x780
       [<ffffffff81d16e15>] ? sctp_v6_get_dst+0x325/0x780
       [<ffffffff81d00a96>] sctp_transport_route+0x46/0x120
       [<ffffffff81cff0f1>] sctp_assoc_add_peer+0x161/0x350
       [<ffffffff81d0fd8d>] sctp_sendmsg+0x6cd/0xcb0
       [<ffffffff81b55bf0>] ? inet_create+0x670/0x670
       [<ffffffff81b55cfb>] inet_sendmsg+0x10b/0x220
       [<ffffffff81b55bf0>] ? inet_create+0x670/0x670
       [<ffffffff81a72a64>] ? sock_update_classid+0xa4/0x2b0
       [<ffffffff81a72ab0>] ? sock_update_classid+0xf0/0x2b0
       [<ffffffff81a6ac1c>] sock_sendmsg+0xdc/0xf0
       [<ffffffff8118e9e5>] ? might_fault+0x85/0x90
       [<ffffffff8118e99c>] ? might_fault+0x3c/0x90
       [<ffffffff81a6e12a>] sys_sendto+0xfa/0x130
       [<ffffffff810a9887>] ? do_setitimer+0x197/0x380
       [<ffffffff81e960d5>] ? sysret_check+0x22/0x5d
       [<ffffffff81e960a9>] system_call_fastpath+0x16/0x1b
      Code: 01 eb 89 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 f8 31 c9 48 89 e5 53 eb 12 0f 1f 40 00 48 83 c1 01 48 83 c0 04 48 83 f9 08 74 70 <0f> b6 3c 4e 89 fb 83 e7 0f c0 eb 04 41 89 d8 41 83 e0 0f 0f b6
      RIP  [<ffffffff8136796e>] ip6_string+0x1e/0xa0
       RSP <ffff88004e4637a0>
      CR2: 0000000000000100
      ---[ end trace a4de0bfcb38a3643 ]---
      Signed-off-by: NTommi Rantala <tt.rantala@gmail.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee3f34e8
  10. 15 8月, 2012 4 次提交
  11. 12 7月, 2012 1 次提交
  12. 23 11月, 2011 1 次提交
  13. 27 10月, 2011 1 次提交
  14. 02 6月, 2011 1 次提交
  15. 08 5月, 2011 1 次提交
  16. 28 4月, 2011 5 次提交
  17. 23 4月, 2011 1 次提交
  18. 13 3月, 2011 2 次提交
  19. 27 8月, 2010 1 次提交
  20. 16 4月, 2010 1 次提交
  21. 04 4月, 2010 1 次提交
  22. 31 3月, 2010 1 次提交
  23. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  24. 21 3月, 2010 1 次提交
  25. 17 2月, 2010 1 次提交
  26. 06 11月, 2009 2 次提交
  27. 15 9月, 2009 1 次提交
  28. 23 6月, 2009 1 次提交
  29. 16 2月, 2009 1 次提交
  30. 23 1月, 2009 1 次提交