1. 01 May, 2010 7 commits
    • Frederic Weisbecker's avatar
      hw-breakpoints: Get the number of available registers on boot dynamically · feef47d0
      Frederic Weisbecker authored
      The breakpoint generic layer assumes that archs always know in advance
      the static number of address registers available to host breakpoints
      through the HBP_NUM macro.
      
      However this is not true for every archs. For example Arm needs to get
      this information dynamically to handle the compatiblity between
      different versions.
      
      To solve this, this patch proposes to drop the static HBP_NUM macro
      and let the arch provide the number of available slots through a
      new hw_breakpoint_slots() function. For archs that have
      CONFIG_HAVE_MIXED_BREAKPOINTS_REGS selected, it will be called once
      as the number of registers fits for instruction and data breakpoints
      together.
      For the others it will be called first to get the number of
      instruction breakpoint registers and another time to get the
      data breakpoint registers, the targeted type is given as a
      parameter of hw_breakpoint_slots().
      Reported-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      feef47d0
    • Frederic Weisbecker's avatar
      hw-breakpoints: Handle breakpoint weight in allocation constraints · f93a2054
      Frederic Weisbecker authored
      Depending on their nature and on what an arch supports, breakpoints
      may consume more than one address register. For example a simple
      absolute address match usually only requires one address register.
      But an address range match may consume two registers.
      
      Currently our slot allocation constraints, that tend to reflect the
      limited arch's resources, always consider that a breakpoint consumes
      one slot.
      
      Then provide a way for archs to tell us the weight of a breakpoint
      through a new hw_breakpoint_weight() helper. This weight will be
      computed against the generic allocation constraints instead of
      a constant value.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      f93a2054
    • Frederic Weisbecker's avatar
      hw-breakpoints: Separate constraint space for data and instruction breakpoints · 0102752e
      Frederic Weisbecker authored
      There are two outstanding fashions for archs to implement hardware
      breakpoints.
      
      The first is to separate breakpoint address pattern definition
      space between data and instruction breakpoints. We then have
      typically distinct instruction address breakpoint registers
      and data address breakpoint registers, delivered with
      separate control registers for data and instruction breakpoints
      as well. This is the case of PowerPc and ARM for example.
      
      The second consists in having merged breakpoint address space
      definition between data and instruction breakpoint. Address
      registers can host either instruction or data address and
      the access mode for the breakpoint is defined in a control
      register. This is the case of x86 and Super H.
      
      This patch adds a new CONFIG_HAVE_MIXED_BREAKPOINTS_REGS config
      that archs can select if they belong to the second case. Those
      will have their slot allocation merged for instructions and
      data breakpoints.
      
      The others will have a separate slot tracking between data and
      instruction breakpoints.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      0102752e
    • Frederic Weisbecker's avatar
      hw-breakpoints: Change/Enforce some breakpoints policies · b2812d03
      Frederic Weisbecker authored
      The current policies of breakpoints in x86 and SH are the following:
      
      - task bound breakpoints can only break on userspace addresses
      - cpu wide breakpoints can only break on kernel addresses
      
      The former rule prevents ptrace breakpoints to be set to trigger on
      kernel addresses, which is good. But as a side effect, we can't
      breakpoint on kernel addresses for task bound breakpoints.
      
      The latter rule simply makes no sense, there is no reason why we
      can't set breakpoints on userspace while performing cpu bound
      profiles.
      
      We want the following new policies:
      
      - task bound breakpoint can set userspace address breakpoints, with
      no particular privilege required.
      - task bound breakpoints can set kernelspace address breakpoints but
      must be privileged to do that.
      - cpu bound breakpoints can do what they want as they are privileged
      already.
      
      To implement these new policies, this patch checks if we are dealing
      with a kernel address breakpoint, if so and if the exclude_kernel
      parameter is set, we tell the user that the breakpoint is invalid,
      which makes a good generic ptrace protection.
      If we don't have exclude_kernel, ensure the user has the right
      privileges as kernel breakpoints are quite sensitive (risk of
      trap recursion attacks and global performance impacts).
      
      [ Paul Mundt: keep addr space check for sh signal delivery and fix
        double function declaration]
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      b2812d03
    • Frederic Weisbecker's avatar
      hw-breakpoints: Check disabled breakpoints again · 87e9b202
      Frederic Weisbecker authored
      We stopped checking disabled breakpoints because we weren't
      allowing breakpoints on NULL addresses. And gdb tends to set
      NULL addresses on inactive breakpoints.
      
      But refusing NULL addresses was actually a regression that has
      been fixed now. There is no reason anymore to not validate
      inactive breakpoint settings.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      87e9b202
    • Frederic Weisbecker's avatar
      hw-breakpoints: Tag ptrace breakpoint as exclude_kernel · 73266fc1
      Frederic Weisbecker authored
      Tag ptrace breakpoints with the exclude_kernel attribute set. This
      will make it easier to set generic policies on breakpoints, when it
      comes to ensure nobody unpriviliged try to breakpoint on the kernel.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Cc: K. Prasad <prasad@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      73266fc1
    • Frederic Weisbecker's avatar
      perf: Fix warning while reading ring buffer headers · d00a47cc
      Frederic Weisbecker authored
      commit e9e94e3b
      "perf trace: Ignore "overwrite" field if present in
      /events/header_page" makes perf trace launching spurious warnings
      about unexpected tokens read:
      
      	Warning: Error: expected type 6 but read 4
      
      This change tries to handle the overcommit field in the header_page
      file whenever this field is present or not.
      
      The problem is that if this field is not present, we try to find it
      and give up in the middle of the line when we realize we are actually
      dealing with another field, which is the "data" one. And this failure
      abandons the file pointer in the middle of the "data" description
      line:
      
      	field: u64 timestamp;	offset:0;	size:8;	signed:0;
      	field: local_t commit;	offset:8;	size:8;	signed:1;
      	field: char data;	offset:16;	size:4080;	signed:1;
                            ^^^
                            Here
      
      What happens next is that we want to read this line to parse the data
      field, but we fail because the pointer is not in the beginning of the
      line.
      
      We could probably fix that by rewinding the pointer. But in fact we
      don't care much about these headers that only concern the ftrace
      ring-buffer. We don't use them from perf.
      
      Just skip this part of perf.data, but don't remove it from recording
      to stay compatible with olders perf.data
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      d00a47cc
  2. 30 Apr, 2010 10 commits
  3. 29 Apr, 2010 12 commits
  4. 28 Apr, 2010 11 commits
    • Colin Tuckley's avatar
      ARM: 5957/1: ARM: RealView SD/MMC Card detection and write-protect using GPIOLIB · b56ba8aa
      Colin Tuckley authored
      The switch to using GPIOLIB broke the sd/mmc card detection on the
      RealView development boards if GPIO_PL061 was not selected.
      This patch selects GPIO_PL061 if GPIOLIB is selected.
      The sense of the return value from mmc_status has also changed
      and is corrected.
      Signed-off-by: default avatarColin Tuckley <colin.tuckley@arm.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b56ba8aa
    • Linus Torvalds's avatar
      1d16b0f2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · 032b734d
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (27 commits)
        sfc: Change falcon_probe_board() to fail for unsupported boards
        sfc: Always close net device at the end of a disabling reset
        sfc: Wait at most 10ms for the MC to finish reading out MAC statistics
        sctp: Fix oops when sending queued ASCONF chunks
        sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set
        sctp: per_cpu variables should be in bh_disabled section
        sctp: fix potential reference of a freed pointer
        sctp: avoid irq lock inversion while call sk->sk_data_ready()
        Revert "tcp: bind() fix when many ports are bound"
        net/usb: add sierra_net.c driver
        cdc_ether: fix autosuspend for mbm devices
        bluetooth: handle l2cap_create_connless_pdu() errors
        gianfar: Wait for both RX and TX to stop
        ipheth: potential null dereferences on error path
        smc91c92_cs: spin_unlock_irqrestore before calling smc_interrupt()
        drivers/usb/net/kaweth.c: add device "Allied Telesyn AT-USB10 USB Ethernet Adapter"
        bnx2: Update version to 2.0.9.
        bnx2: Prevent "scheduling while atomic" warning with cnic, bonding and vlan.
        bnx2: Fix lost MSI-X problem on 5709 NICs.
        cxgb3: Wait longer for control packets on initialization
        ...
      032b734d
    • Ben Hutchings's avatar
      sfc: Change falcon_probe_board() to fail for unsupported boards · e41c11ee
      Ben Hutchings authored
      The driver needs specific PHY and board support code for each SFC4000
      board; there is no point trying to continue if it is missing.
      Currently unsupported boards can trigger an 'oops'.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e41c11ee
    • Ben Hutchings's avatar
      sfc: Always close net device at the end of a disabling reset · f49a4589
      Ben Hutchings authored
      This fixes a regression introduced by commit
      eb9f6744 "sfc: Implement ethtool
      reset operation".
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f49a4589
    • Ben Hutchings's avatar
      sfc: Wait at most 10ms for the MC to finish reading out MAC statistics · aabc5649
      Ben Hutchings authored
      The original code would wait indefinitely if MAC stats DMA failed.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aabc5649
    • Vlad Yasevich's avatar
      sctp: Fix oops when sending queued ASCONF chunks · c0786693
      Vlad Yasevich authored
      When we finish processing ASCONF_ACK chunk, we try to send
      the next queued ASCONF.  This action runs the sctp state
      machine recursively and it's not prepared to do so.
      
      kernel BUG at kernel/timer.c:790!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/module/ipv6/initstate
      Modules linked in: sha256_generic sctp libcrc32c ipv6 dm_multipath
      uinput 8139too i2c_piix4 8139cp mii i2c_core pcspkr virtio_net joydev
      floppy virtio_blk virtio_pci [last unloaded: scsi_wait_scan]
      
      Pid: 0, comm: swapper Not tainted 2.6.34-rc4 #15 /Bochs
      EIP: 0060:[<c044a2ef>] EFLAGS: 00010286 CPU: 0
      EIP is at add_timer+0xd/0x1b
      EAX: cecbab14 EBX: 000000f0 ECX: c0957b1c EDX: 03595cf4
      ESI: cecba800 EDI: cf276f00 EBP: c0957aa0 ESP: c0957aa0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=c0956000 task=c0988ba0 task.ti=c0956000)
      Stack:
       c0957ae0 d1851214 c0ab62e4 c0ab5f26 0500ffff 00000004 00000005 00000004
      <0> 00000000 d18694fd 00000004 1666b892 cecba800 cecba800 c0957b14
      00000004
      <0> c0957b94 d1851b11 ceda8b00 cecba800 cf276f00 00000001 c0957b14
      000000d0
      Call Trace:
       [<d1851214>] ? sctp_side_effects+0x607/0xdfc [sctp]
       [<d1851b11>] ? sctp_do_sm+0x108/0x159 [sctp]
       [<d1863386>] ? sctp_pname+0x0/0x1d [sctp]
       [<d1861a56>] ? sctp_primitive_ASCONF+0x36/0x3b [sctp]
       [<d185657c>] ? sctp_process_asconf_ack+0x2a4/0x2d3 [sctp]
       [<d184e35c>] ? sctp_sf_do_asconf_ack+0x1dd/0x2b4 [sctp]
       [<d1851ac1>] ? sctp_do_sm+0xb8/0x159 [sctp]
       [<d1863334>] ? sctp_cname+0x0/0x52 [sctp]
       [<d1854377>] ? sctp_assoc_bh_rcv+0xac/0xe1 [sctp]
       [<d1858f0f>] ? sctp_inq_push+0x2d/0x30 [sctp]
       [<d186329d>] ? sctp_rcv+0x797/0x82e [sctp]
      Tested-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarYuansong Qiao <ysqiao@research.ait.ie>
      Signed-off-by: default avatarShuaijun Zhang <szhang@research.ait.ie>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0786693
    • Wei Yongjun's avatar
      sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set · a8170c35
      Wei Yongjun authored
      When calculating the INIT/INIT-ACK chunk length, we should not
      only account the length of parameters, but also the parameters
      zero padding length, such as AUTH HMACS parameter and CHUNKS
      parameter. Without the parameters zero padding length we may get
      following oops.
      
      skb_over_panic: text:ce2068d2 len:130 put:6 head:cac3fe00 data:cac3fe00 tail:0xcac3fe82 end:0xcac3fe80 dev:<NULL>
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:127!
      invalid opcode: 0000 [#2] SMP
      last sysfs file: /sys/module/aes_generic/initstate
      Modules linked in: authenc ......
      
      Pid: 4102, comm: sctp_darn Tainted: G      D    2.6.34-rc2 #6
      EIP: 0060:[<c0607630>] EFLAGS: 00010282 CPU: 0
      EIP is at skb_over_panic+0x37/0x3e
      EAX: 00000078 EBX: c07c024b ECX: c07c02b9 EDX: cb607b78
      ESI: 00000000 EDI: cac3fe7a EBP: 00000002 ESP: cb607b74
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process sctp_darn (pid: 4102, ti=cb607000 task=cabdc990 task.ti=cb607000)
      Stack:
       c07c02b9 ce2068d2 00000082 00000006 cac3fe00 cac3fe00 cac3fe82 cac3fe80
      <0> c07c024b cac3fe7c cac3fe7a c0608dec ca986e80 ce2068d2 00000006 0000007a
      <0> cb8120ca ca986e80 cb812000 00000003 cb8120c4 ce208a25 cb8120ca cadd9400
      Call Trace:
       [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp]
       [<c0608dec>] ? skb_put+0x2e/0x32
       [<ce2068d2>] ? sctp_addto_chunk+0x45/0x85 [sctp]
       [<ce208a25>] ? sctp_make_init+0x279/0x28c [sctp]
       [<c0686a92>] ? apic_timer_interrupt+0x2a/0x30
       [<ce1fdc0b>] ? sctp_sf_do_prm_asoc+0x2b/0x7b [sctp]
       [<ce202823>] ? sctp_do_sm+0xa0/0x14a [sctp]
       [<ce2133b9>] ? sctp_pname+0x0/0x14 [sctp]
       [<ce211d72>] ? sctp_primitive_ASSOCIATE+0x2b/0x31 [sctp]
       [<ce20f3cf>] ? sctp_sendmsg+0x7a0/0x9eb [sctp]
       [<c064eb1e>] ? inet_sendmsg+0x3b/0x43
       [<c04244b7>] ? task_tick_fair+0x2d/0xd9
       [<c06031e1>] ? sock_sendmsg+0xa7/0xc1
       [<c0416afe>] ? smp_apic_timer_interrupt+0x6b/0x75
       [<c0425123>] ? dequeue_task_fair+0x34/0x19b
       [<c0446abb>] ? sched_clock_local+0x17/0x11e
       [<c052ea87>] ? _copy_from_user+0x2b/0x10c
       [<c060ab3a>] ? verify_iovec+0x3c/0x6a
       [<c06035ca>] ? sys_sendmsg+0x186/0x1e2
       [<c042176b>] ? __wake_up_common+0x34/0x5b
       [<c04240c2>] ? __wake_up+0x2c/0x3b
       [<c057e35c>] ? tty_wakeup+0x43/0x47
       [<c04430f2>] ? remove_wait_queue+0x16/0x24
       [<c0580c94>] ? n_tty_read+0x5b8/0x65e
       [<c042be02>] ? default_wake_function+0x0/0x8
       [<c0604e0e>] ? sys_socketcall+0x17f/0x1cd
       [<c040264c>] ? sysenter_do_call+0x12/0x22
      Code: 0f 45 de 53 ff b0 98 00 00 00 ff b0 94 ......
      EIP: [<c0607630>] skb_over_panic+0x37/0x3e SS:ESP 0068:cb607b74
      
      To reproduce:
      
      # modprobe sctp
      # echo 1 > /proc/sys/net/sctp/addip_enable
      # echo 1 > /proc/sys/net/sctp/auth_enable
      # sctp_test -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 800 -l
      # sctp_darn -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 900 -h 192.168.0.21 -p 800 -I -s -t
      sctp_darn ready to send...
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.0.21
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.1.21
      3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> snd=10
      
      ------------------------------------------------------------------
      eth0 has addresses: 3ffe:501:ffff:100:20c:29ff:fe4d:f37e and 192.168.0.21
      eth1 has addresses: 192.168.1.21
      ------------------------------------------------------------------
      Reported-by: default avatarGeorge Cheimonidis <gchimon@gmail.com>
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8170c35
    • Vlad Yasevich's avatar
      sctp: per_cpu variables should be in bh_disabled section · 81419d86
      Vlad Yasevich authored
      Since the change of the atomics to percpu variables, we now
      have to disable BH in process context when touching percpu variables.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81419d86
    • Vlad Yasevich's avatar
      sctp: fix potential reference of a freed pointer · 0c42749c
      Vlad Yasevich authored
      When sctp attempts to update an assocition, it removes any
      addresses that were not in the updated INITs.  However, the loop
      may attempt to refrence a transport with address after removing it.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c42749c
    • Wei Yongjun's avatar
      sctp: avoid irq lock inversion while call sk->sk_data_ready() · 561b1733
      Wei Yongjun authored
      sk->sk_data_ready() of sctp socket can be called from both BH and non-BH
      contexts, but the default sk->sk_data_ready(), sock_def_readable(), can
      not be used in this case. Therefore, we have to make a new function
      sctp_data_ready() to grab sk->sk_data_ready() with BH disabling.
      
      =========================================================
      [ INFO: possible irq lock inversion dependency detected ]
      2.6.33-rc6 #129
      ---------------------------------------------------------
      sctp_darn/1517 just changed the state of lock:
       (clock-AF_INET){++.?..}, at: [<c06aab60>] sock_def_readable+0x20/0x80
      but this lock took another, SOFTIRQ-unsafe lock in the past:
       (slock-AF_INET){+.-...}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
      1 lock held by sctp_darn/1517:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<cdfe363d>] sctp_sendmsg+0x23d/0xc00 [sctp]
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      561b1733