1. 17 1月, 2018 4 次提交
  2. 16 1月, 2018 2 次提交
  3. 11 1月, 2018 3 次提交
  4. 09 1月, 2018 2 次提交
    • M
      sctp: fix the handling of ICMP Frag Needed for too small MTUs · b6c5734d
      Marcelo Ricardo Leitner 提交于
      syzbot reported a hang involving SCTP, on which it kept flooding dmesg
      with the message:
      [  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
      low, using default minimum of 512
      
      That happened because whenever SCTP hits an ICMP Frag Needed, it tries
      to adjust to the new MTU and triggers an immediate retransmission. But
      it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
      allowed (512) would not cause the PMTU to change, and issued the
      retransmission anyway (thus leading to another ICMP Frag Needed, and so
      on).
      
      As IPv4 (ip_rt_min_pmtu=556) and IPv6 (IPV6_MIN_MTU=1280) minimum MTU
      are higher than that, sctp_transport_update_pmtu() is changed to
      re-fetch the PMTU that got set after our request, and with that, detect
      if there was an actual change or not.
      
      The fix, thus, skips the immediate retransmission if the received ICMP
      resulted in no change, in the hope that SCTP will select another path.
      
      Note: The value being used for the minimum MTU (512,
      SCTP_DEFAULT_MINSEGMENT) is not right and instead it should be (576,
      SCTP_MIN_PMTU), but such change belongs to another patch.
      
      Changes from v1:
      - do not disable PMTU discovery, in the light of commit
      06ad3919 ("[SCTP] Don't disable PMTU discovery when mtu is small")
      and as suggested by Xin Long.
      - changed the way to break the rtx loop by detecting if the icmp
        resulted in a change or not
      Changes from v2:
      none
      
      See-also: https://lkml.org/lkml/2017/12/22/811Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6c5734d
    • M
      sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled · cc35c3d1
      Marcelo Ricardo Leitner 提交于
      Currently, if PMTU discovery is disabled on a given transport, but the
      configured value is higher than the actual PMTU, it is likely that we
      will get some icmp Frag Needed. The issue is, if PMTU discovery is
      disabled, we won't update the information and will issue a
      retransmission immediately, which may very well trigger another ICMP,
      and another retransmission, leading to a loop.
      
      The fix is to simply not trigger immediate retransmissions if PMTU
      discovery is disabled on the given transport.
      
      Changes from v2:
      - updated stale comment, noticed by Xin Long
      Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc35c3d1
  5. 04 1月, 2018 1 次提交
  6. 03 1月, 2018 2 次提交
    • M
      net: sctp: Remove debug SCTP probe module · fa4475f7
      Masami Hiramatsu 提交于
      Remove SCTP probe module since jprobe has been deprecated.
      That function is now replaced by sctp/sctp_probe and
      sctp/sctp_probe_path trace-events.
      You can use it via ftrace or perftools.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa4475f7
    • M
      net: sctp: Add SCTP ACK tracking trace event · 103d750c
      Masami Hiramatsu 提交于
      Add SCTP ACK tracking trace event to trace the changes of SCTP
      association state in response to incoming packets.
      It is used for debugging SCTP congestion control algorithms,
      and will replace sctp_probe module.
      
      Note that this event a bit tricky. Since this consists of 2
      events (sctp_probe and sctp_probe_path) so you have to enable
      both events as below.
      
        # cd /sys/kernel/debug/tracing
        # echo 1 > events/sctp/sctp_probe/enable
        # echo 1 > events/sctp/sctp_probe_path/enable
      
      Or, you can enable all the events under sctp.
      
        # echo 1 > events/sctp/enable
      
      Since sctp_probe_path event is always invoked from sctp_probe
      event, you can not see any output if you only enable
      sctp_probe_path.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      103d750c
  7. 28 12月, 2017 1 次提交
  8. 21 12月, 2017 1 次提交
  9. 19 12月, 2017 2 次提交
  10. 16 12月, 2017 8 次提交
  11. 12 12月, 2017 13 次提交
  12. 11 12月, 2017 1 次提交
    • T
      rhashtable: Change rhashtable_walk_start to return void · 97a6ec4a
      Tom Herbert 提交于
      Most callers of rhashtable_walk_start don't care about a resize event
      which is indicated by a return value of -EAGAIN. So calls to
      rhashtable_walk_start are wrapped wih code to ignore -EAGAIN. Something
      like this is common:
      
             ret = rhashtable_walk_start(rhiter);
             if (ret && ret != -EAGAIN)
                     goto out;
      
      Since zero and -EAGAIN are the only possible return values from the
      function this check is pointless. The condition never evaluates to true.
      
      This patch changes rhashtable_walk_start to return void. This simplifies
      code for the callers that ignore -EAGAIN. For the few cases where the
      caller cares about the resize event, particularly where the table can be
      walked in mulitple parts for netlink or seq file dump, the function
      rhashtable_walk_start_check has been added that returns -EAGAIN on a
      resize event.
      Signed-off-by: NTom Herbert <tom@quantonium.net>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97a6ec4a