1. 26 6月, 2013 3 次提交
  2. 20 6月, 2013 1 次提交
  3. 18 6月, 2013 2 次提交
  4. 15 6月, 2013 4 次提交
  5. 14 6月, 2013 1 次提交
    • N
      sctp: fully initialize sctp_outq in sctp_outq_init · c5c7774d
      Neil Horman 提交于
      In commit 2f94aabd
      (refactor sctp_outq_teardown to insure proper re-initalization)
      we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
      outq structure.  Steve West recently asked me why I removed the q->error = 0
      initalization from sctp_outq_teardown.  I did so because I was operating under
      the impression that sctp_outq_init would properly initalize that value for us,
      but it doesn't.  sctp_outq_init operates under the assumption that the outq
      struct is all 0's (as it is when called from sctp_association_init), but using
      it in __sctp_outq_teardown violates that assumption. We should do a memset in
      sctp_outq_init to ensure that the entire structure is in a known state there
      instead.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reported-by: N"West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: netdev@vger.kernel.org
      CC: davem@davemloft.net
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5c7774d
  6. 13 6月, 2013 2 次提交
  7. 11 6月, 2013 1 次提交
    • D
      net: sctp: fix NULL pointer dereference in socket destruction · 1abd165e
      Daniel Borkmann 提交于
      While stress testing sctp sockets, I hit the following panic:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
      IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
      PGD 7cead067 PUD 7ce76067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in: sctp(F) libcrc32c(F) [...]
      CPU: 7 PID: 2950 Comm: acc Tainted: GF            3.10.0-rc2+ #1
      Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
      task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
      RIP: 0010:[<ffffffffa0490c4e>]  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
      RSP: 0018:ffff88007b569e08  EFLAGS: 00010292
      RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
      RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
      RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
      R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
      R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
      FS:  00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
       ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
       0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
      Call Trace:
       [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
       [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
       [<ffffffff814df36e>] inet_create+0x2ae/0x350
       [<ffffffff81455a6f>] __sock_create+0x11f/0x240
       [<ffffffff81455bf0>] sock_create+0x30/0x40
       [<ffffffff8145696c>] SyS_socket+0x4c/0xc0
       [<ffffffff815403be>] ? do_page_fault+0xe/0x10
       [<ffffffff8153cb32>] ? page_fault+0x22/0x30
       [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
      Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
            1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
            8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
      RIP  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
       RSP <ffff88007b569e08>
      CR2: 0000000000000020
      ---[ end trace e0d71ec1108c1dd9 ]---
      
      I did not hit this with the lksctp-tools functional tests, but with a
      small, multi-threaded test program, that heavily allocates, binds,
      listens and waits in accept on sctp sockets, and then randomly kills
      some of them (no need for an actual client in this case to hit this).
      Then, again, allocating, binding, etc, and then killing child processes.
      
      This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
      is set. The cause for that is actually very simple: in sctp_endpoint_init()
      we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
      our crypto transforms through crypto_alloc_hash(). In our scenario,
      it then can happen that crypto_alloc_hash() fails with -EINTR from
      crypto_larval_wait(), thus we bail out and release the socket via
      sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
      dereference as soon as we try to access members in the endpoint during
      sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
      if we have that case, we do not need to do any cleanup work and just
      leave the destruction handler.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1abd165e
  8. 31 5月, 2013 1 次提交
  9. 29 5月, 2013 1 次提交
  10. 02 5月, 2013 1 次提交
  11. 30 4月, 2013 1 次提交
  12. 23 4月, 2013 1 次提交
  13. 18 4月, 2013 7 次提交
  14. 17 4月, 2013 1 次提交
    • D
      sctp: Add buffer utilization fields to /proc/net/sctp/assocs · f406c8b9
      Dilip Daya 提交于
      sctp: Add buffer utilization fields to /proc/net/sctp/assocs
      
      This patch adds the following fields to /proc/net/sctp/assocs output:
      
      	- sk->sk_wmem_alloc as "wmema"	(transmit queue bytes committed)
      	- sk->sk_wmem_queued as "wmemq"	(persistent queue size)
      	- sk->sk_sndbuf as "sndbuf"	(size of send buffer in bytes)
      	- sk->sk_rcvbuf as "rcvbuf"	(size of receive buffer in bytes)
      
      When small DATA chunks containing 136 bytes data are sent the TX_QUEUE
      (assoc->sndbuf_used) reaches a maximum of 40.9% of sk_sndbuf value when
      peer.rwnd = 0. This was diagnosed from sk_wmem_alloc value reaching maximum
      value of sk_sndbuf.
      
      TX_QUEUE (assoc->sndbuf_used), sk_wmem_alloc and sk_wmem_queued values are
      incremented in sctp_set_owner_w() for outgoing data chunks. Having access to
      the above values in /proc/net/sctp/assocs will provide a better understanding
      of SCTP buffer management.
      
      With patch applied, example output when peer.rwnd = 0
      
      where:
          ASSOC ffff880132298000 is sender
                ffff880125343000 is receiver
      
       ASSOC           SOCK            STY SST ST  HBKT ASSOC-ID TX_QUEUE RX_QUEUE \
      ffff880132298000 ffff880124a0a0c0 2   1   3  29325    1      214656        0 \
      ffff880125343000 ffff8801237d7700 2   1   3  36210    2           0   524520 \
      
      UID   INODE LPORT  RPORT LADDRS <-> RADDRS       HBINT   INS  OUTS \
        0   25108 3455   3456  *10.4.8.3 <-> *10.5.8.3  7500     2     2 \
        0   27819 3456   3455  *10.5.8.3 <-> *10.4.8.3  7500     2     2 \
      
      MAXRT T1X T2X RTXC   wmema   wmemq  sndbuf  rcvbuf
          4   0   0   72  525633  440320  524288  524288
          4   0   0    0       1       0  524288  524288
      Signed-off-by: NDilip Daya <dilip.daya@hp.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f406c8b9
  15. 16 4月, 2013 2 次提交
  16. 08 4月, 2013 1 次提交
  17. 01 4月, 2013 1 次提交
    • K
      net: add option to enable error queue packets waking select · 7d4c04fc
      Keller, Jacob E 提交于
      Currently, when a socket receives something on the error queue it only wakes up
      the socket on select if it is in the "read" list, that is the socket has
      something to read. It is useful also to wake the socket if it is in the error
      list, which would enable software to wait on error queue packets without waking
      up for regular data on the socket. The main use case is for receiving
      timestamped transmit packets which return the timestamp to the socket via the
      error queue. This enables an application to select on the socket for the error
      queue only instead of for the regular traffic.
      
      -v2-
      * Added the SO_SELECT_ERR_QUEUE socket option to every architechture specific file
      * Modified every socket poll function that checks error queue
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Cc: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Matthew Vick <matthew.vick@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4c04fc
  18. 18 3月, 2013 1 次提交
  19. 13 3月, 2013 2 次提交
  20. 05 3月, 2013 1 次提交
  21. 02 3月, 2013 1 次提交
  22. 01 3月, 2013 4 次提交