1. 10 8月, 2013 1 次提交
  2. 03 8月, 2013 1 次提交
  3. 28 7月, 2013 1 次提交
  4. 25 7月, 2013 1 次提交
  5. 10 7月, 2013 1 次提交
    • D
      net: sctp: confirm route during forward progress · 8c2f414a
      Daniel Borkmann 提交于
      This fix has been proposed originally by Vlad Yasevich. He says:
      
        When SCTP makes forward progress (receives a SACK that acks new chunks,
        renegs, or answeres 0-window probes) or when HB-ACK arrives, mark
        the route as confirmed so we don't unnecessarily send NUD probes.
      
      Having a simple SCTP client/server that exchange data chunks every 1sec,
      without this patch ARP requests are sent periodically every 40-60sec.
      With this fix applied, an ARP request is only done once right at the
      "session" beginning. Also, when clearing the related ARP cache entry
      manually during the session, a new request is correctly done. I have
      only "backported" this to net-next and tested that it works, so full
      credit goes to Vlad.
      Signed-off-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c2f414a
  6. 03 7月, 2013 1 次提交
    • Y
      sctp: use get_unused_fd_flags(0) instead of get_unused_fd() · 8a59bd3e
      Yann Droneaud 提交于
      Macro get_unused_fd() is used to allocate a file descriptor with
      default flags. Those default flags (0) can be "unsafe":
      O_CLOEXEC must be used by default to not leak file descriptor
      across exec().
      
      Instead of macro get_unused_fd(), functions anon_inode_getfd()
      or get_unused_fd_flags() should be used with flags given by userspace.
      If not possible, flags should be set to O_CLOEXEC to provide userspace
      with a default safe behavor.
      
      In a further patch, get_unused_fd() will be removed so that
      new code start using anon_inode_getfd() or get_unused_fd_flags()
      with correct flags.
      
      This patch replaces calls to get_unused_fd() with equivalent call to
      get_unused_fd_flags(0) to preserve current behavor for existing code.
      
      The hard coded flag value (0) should be reviewed on a per-subsystem basis,
      and, if possible, set to O_CLOEXEC.
      Signed-off-by: NYann Droneaud <ydroneaud@opteya.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a59bd3e
  7. 02 7月, 2013 2 次提交
    • D
      net: sctp: get rid of SCTP_DBG_TSNS entirely · e02010ad
      Daniel Borkmann 提交于
      After having reworked the debugging framework, Neil and Vlad agreed to
      get rid of the leftover SCTP_DBG_TSNS code for a couple of reasons:
      
      We can use systemtap scripts to investigate these things, we now have
      pr_debug() helpers that make life easier, and if we really need anything
      else besides those tools, we will be forced to come up with something
      better than we have there. Therefore, get rid of this ifdef debugging
      code entirely for now.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: Neil Horman <nhorman@tuxdriver.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e02010ad
    • 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
  8. 26 6月, 2013 4 次提交
  9. 20 6月, 2013 1 次提交
  10. 18 6月, 2013 2 次提交
  11. 15 6月, 2013 4 次提交
  12. 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
  13. 13 6月, 2013 2 次提交
  14. 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
  15. 31 5月, 2013 1 次提交
  16. 29 5月, 2013 1 次提交
  17. 02 5月, 2013 1 次提交
  18. 30 4月, 2013 1 次提交
  19. 23 4月, 2013 1 次提交
  20. 18 4月, 2013 7 次提交
  21. 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
  22. 16 4月, 2013 2 次提交
  23. 08 4月, 2013 1 次提交
  24. 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