1. 03 6月, 2009 3 次提交
  2. 09 10月, 2008 1 次提交
    • V
      sctp: Rework the tsn map to use generic bitmap. · 8e1ee18c
      Vlad Yasevich 提交于
      The tsn map currently use is 4K large and is stuck inside
      the sctp_association structure making memory references REALLY
      expensive.  What we really need is at most 4K worth of bits
      so the biggest map we would have is 512 bytes.   Also, the
      map is only really usefull when we have gaps to store and
      report.  As such, starting with minimal map of say 32 TSNs (bits)
      should be enough for normal low-loss operations.  We can grow
      the map by some multiple of 32 along with some extra room any
      time we receive the TSN which would put us outside of the map
      boundry.  As we close gaps, we can shift the map to rebase
      it on the latest TSN we've seen.  This saves 4088 bytes per
      association just in the map alone along savings from the now
      unnecessary structure members.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e1ee18c
  3. 19 9月, 2008 1 次提交
    • V
      sctp: Fix oops when INIT-ACK indicates that peer doesn't support AUTH · add52379
      Vlad Yasevich 提交于
      If INIT-ACK is received with SupportedExtensions parameter which
      indicates that the peer does not support AUTH, the packet will be
      silently ignore, and sctp_process_init() do cleanup all of the
      transports in the association.
      When T1-Init timer is expires, OOPS happen while we try to choose
      a different init transport.
      
      The solution is to only clean up the non-active transports, i.e
      the ones that the peer added.  However, that introduces a problem
      with sctp_connectx(), because we don't mark the proper state for
      the transports provided by the user.  So, we'll simply mark
      user-provided transports as ACTIVE.  That will allow INIT
      retransmissions to work properly in the sctp_connectx() context
      and prevent the crash.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      add52379
  4. 26 7月, 2008 1 次提交
  5. 19 7月, 2008 1 次提交
    • F
      sctp: Prevent uninitialized memory access · 6d0ccbac
      Florian Westphal 提交于
      valgrind reports uninizialized memory accesses when running
      sctp inside the network simulation cradle simulator:
      
       Conditional jump or move depends on uninitialised value(s)
          at 0x570E34A: sctp_assoc_sync_pmtu (associola.c:1324)
          by 0x57427DA: sctp_packet_transmit (output.c:403)
          by 0x5710EFF: sctp_outq_flush (outqueue.c:824)
          by 0x5710B88: sctp_outq_uncork (outqueue.c:701)
          by 0x5745262: sctp_cmd_interpreter (sm_sideeffect.c:1548)
          by 0x57444B7: sctp_side_effects (sm_sideeffect.c:976)
          by 0x5744460: sctp_do_sm (sm_sideeffect.c:945)
          by 0x572157D: sctp_primitive_ASSOCIATE (primitive.c:94)
          by 0x5725C04: __sctp_connect (socket.c:1094)
          by 0x57297DC: sctp_connect (socket.c:3297)
      
       Conditional jump or move depends on uninitialised value(s)
          at 0x575D3A5: mod_timer (timer.c:630)
          by 0x5752B78: sctp_cmd_hb_timers_start (sm_sideeffect.c:555)
          by 0x5754133: sctp_cmd_interpreter (sm_sideeffect.c:1448)
          by 0x5753607: sctp_side_effects (sm_sideeffect.c:976)
          by 0x57535B0: sctp_do_sm (sm_sideeffect.c:945)
          by 0x571E9AE: sctp_endpoint_bh_rcv (endpointola.c:474)
          by 0x573347F: sctp_inq_push (inqueue.c:104)
          by 0x572EF93: sctp_rcv (input.c:256)
          by 0x5689623: ip_local_deliver_finish (ip_input.c:230)
          by 0x5689759: ip_local_deliver (ip_input.c:268)
          by 0x5689CAC: ip_rcv_finish (dst.h:246)
      
      #1 is due to "if (t->pmtu_pending)".
      8a479491 "[SCTP] Flag a pmtu change request"
      suggests it should be initialized to 0.
      
      #2 is the heartbeat timer 'expires' value, which is uninizialised, but
      test by mod_timer().
      T3_rtx_timer seems to be affected by the same problem, so initialize it, too.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d0ccbac
  6. 21 6月, 2008 1 次提交
  7. 20 6月, 2008 1 次提交
    • V
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich 提交于
      RFC 4960, Section 11.4. Protection of Non-SCTP-Capable Hosts
      
      When an SCTP stack receives a packet containing multiple control or
      DATA chunks and the processing of the packet requires the sending of
      multiple chunks in response, the sender of the response chunk(s) MUST
      NOT send more than one packet.  If bundling is supported, multiple
      response chunks that fit into a single packet MAY be bundled together
      into one single response packet.  If bundling is not supported, then
      the sender MUST NOT send more than one response chunk and MUST
      discard all other responses.  Note that this rule does NOT apply to a
      SACK chunk, since a SACK chunk is, in itself, a response to DATA and
      a SACK does not require a response of more DATA.
      
      We implement this by not servicing our outqueue until we reach the end
      of the packet.  This enables maximum bundling.  We also identify
      'response' chunks and make sure that we only send 1 packet when sending
      such chunks.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e3216cd
  8. 17 6月, 2008 1 次提交
  9. 05 6月, 2008 1 次提交
  10. 10 5月, 2008 1 次提交
  11. 13 4月, 2008 1 次提交
  12. 06 3月, 2008 1 次提交
  13. 07 2月, 2008 1 次提交
    • W
      [SCTP]: Fix kernel panic while received ASCONF chunk with bad serial number · a8699814
      Wei Yongjun 提交于
      While recevied ASCONF chunk with serial number less then needed, kernel
      will treat this chunk as a retransmitted ASCONF chunk and find cached
      ASCONF-ACK chunk used sctp_assoc_lookup_asconf_ack(). But this function
      will always return NO-NULL. So response with cached ASCONF-ACKs chunk
      will cause kernel panic.
      In function sctp_assoc_lookup_asconf_ack(), if the cached ASCONF-ACKs
      list asconf_ack_list is empty, or if the serial being requested does not
      exists, the function as it currectly stands returns the actuall
      list_head asoc->asconf_ack_list, this is not a cache ASCONF-ACK chunk
      but a bogus pointer.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      a8699814
  14. 05 2月, 2008 1 次提交
  15. 29 1月, 2008 3 次提交
  16. 08 11月, 2007 2 次提交
  17. 11 10月, 2007 3 次提交
  18. 17 9月, 2007 1 次提交
  19. 31 8月, 2007 1 次提交
  20. 14 6月, 2007 1 次提交
  21. 05 5月, 2007 1 次提交
    • V
      [SCTP]: Set assoc_id correctly during INIT collision. · 07d93967
      Vlad Yasevich 提交于
      During the INIT/COOKIE-ACK collision cases, it's possible to get
      into a situation where the association id is not yet set at the time
      of the user event generation.  As a result, user events have an
      association id set to 0 which will confuse applications.
      
      This happens if we hit case B of duplicate cookie processing.
      In the particular example found and provided by Oscar Isaula
      <Oscar.Isaula@motorola.com>, flow looks like this:
      A				B
      ---- INIT------->  (lost)
      	    <---------INIT------
      ---- INIT-ACK--->
      	    <------ Cookie ECHO
      
      When the Cookie Echo is received, we end up trying to update the
      association that was created on A as a result of the (lost) INIT,
      but that association doesn't have the ID set yet.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07d93967
  22. 26 4月, 2007 3 次提交
  23. 20 3月, 2007 2 次提交
  24. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  25. 11 2月, 2007 1 次提交
  26. 14 12月, 2006 1 次提交
  27. 03 12月, 2006 4 次提交