1. 06 9月, 2013 18 次提交
  2. 05 9月, 2013 19 次提交
    • D
      net: ipv6: mld: document force_mld_version in ip-sysctl.txt · f2127810
      Daniel Borkmann 提交于
      Document force_mld_version parameter in ip-sysctl.txt.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2127810
    • D
      net: ipv6: mld: introduce mld_{gq, ifc, dad}_stop_timer functions · b4af8def
      Daniel Borkmann 提交于
      We already have mld_{gq,ifc,dad}_start_timer() functions, so introduce
      mld_{gq,ifc,dad}_stop_timer() functions to reduce code size and make it
      more readable.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4af8def
    • D
      net: ipv6: mld: refactor query processing into v1/v2 functions · 2b7c121f
      Daniel Borkmann 提交于
      Make igmp6_event_query() a bit easier to read by refactoring code
      parts into mld_process_v1() and mld_process_v2().
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b7c121f
    • D
      net: ipv6: mld: similarly to MLDv2 have min max_delay of 1 · cc7f7ab7
      Daniel Borkmann 提交于
      Similarly as we do in MLDv2 queries, set a forged MLDv1 query with
      0 ms mld_maxdelay to minimum timer shot time of 1 jiffies. This is
      eventually done in igmp6_group_queried() anyway, so we can simplify
      a check there.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc7f7ab7
    • D
      net: ipv6: mld: implement RFC3810 MLDv2 mode only · 58c0ecfd
      Daniel Borkmann 提交于
      RFC3810, 10. Security Considerations says under subsection 10.1.
      Query Message:
      
        A forged Version 1 Query message will put MLDv2 listeners on that
        link in MLDv1 Host Compatibility Mode. This scenario can be avoided
        by providing MLDv2 hosts with a configuration option to ignore
        Version 1 messages completely.
      
      Hence, implement a MLDv2-only mode that will ignore MLDv1 traffic:
      
        echo 2 > /proc/sys/net/ipv6/conf/ethX/force_mld_version  or
        echo 2 > /proc/sys/net/ipv6/conf/all/force_mld_version
      
      Note that <all> device has a higher precedence as it was previously
      also the case in the macro MLD_V1_SEEN() that would "short-circuit"
      if condition on <all> case.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58c0ecfd
    • D
      net: ipv6: mld: get rid of MLDV2_MRC and simplify calculation · e3f5b170
      Daniel Borkmann 提交于
      Get rid of MLDV2_MRC and use our new macros for mantisse and
      exponent to calculate Maximum Response Delay out of the Maximum
      Response Code.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3f5b170
    • D
      net: ipv6: mld: clean up MLD_V1_SEEN macro · 6c567b78
      Daniel Borkmann 提交于
      Replace the macro with a function to make it more readable. GCC will
      eventually decide whether to inline this or not (also, that's not
      fast-path anyway).
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c567b78
    • D
      net: ipv6: mld: fix v1/v2 switchback timeout to rfc3810, 9.12. · 89225d1c
      Daniel Borkmann 提交于
      i) RFC3810, 9.2. Query Interval [QI] says:
      
         The Query Interval variable denotes the interval between General
         Queries sent by the Querier. Default value: 125 seconds. [...]
      
      ii) RFC3810, 9.3. Query Response Interval [QRI] says:
      
        The Maximum Response Delay used to calculate the Maximum Response
        Code inserted into the periodic General Queries. Default value:
        10000 (10 seconds) [...] The number of seconds represented by the
        [Query Response Interval] must be less than the [Query Interval].
      
      iii) RFC3810, 9.12. Older Version Querier Present Timeout [OVQPT] says:
      
        The Older Version Querier Present Timeout is the time-out for
        transitioning a host back to MLDv2 Host Compatibility Mode. When an
        MLDv1 query is received, MLDv2 hosts set their Older Version Querier
        Present Timer to [Older Version Querier Present Timeout].
      
        This value MUST be ([Robustness Variable] times (the [Query Interval]
        in the last Query received)) plus ([Query Response Interval]).
      
      Hence, on *default* the timeout results in:
      
        [RV] = 2, [QI] = 125sec, [QRI] = 10sec
        [OVQPT] = [RV] * [QI] + [QRI] = 260sec
      
      Having that said, we currently calculate [OVQPT] (here given as 'switchback'
      variable) as ...
      
        switchback = (idev->mc_qrv + 1) * max_delay
      
      RFC3810, 9.12. says "the [Query Interval] in the last Query received". In
      section "9.14. Configuring timers", it is said:
      
        This section is meant to provide advice to network administrators on
        how to tune these settings to their network. Ambitious router
        implementations might tune these settings dynamically based upon
        changing characteristics of the network. [...]
      
      iv) RFC38010, 9.14.2. Query Interval:
      
        The overall level of periodic MLD traffic is inversely proportional
        to the Query Interval. A longer Query Interval results in a lower
        overall level of MLD traffic. The value of the Query Interval MUST
        be equal to or greater than the Maximum Response Delay used to
        calculate the Maximum Response Code inserted in General Query
        messages.
      
      I assume that was why switchback is calculated as is (3 * max_delay), although
      this setting seems to be meant for routers only to configure their [QI]
      interval for non-default intervals. So usage here like this is clearly wrong.
      
      Concluding, the current behaviour in IPv6's multicast code is not conform
      to the RFC as switch back is calculated wrongly. That is, it has a too small
      value, so MLDv2 hosts switch back again to MLDv2 way too early, i.e. ~30secs
      instead of ~260secs on default.
      
      Hence, introduce necessary helper functions and fix this up properly as it
      should be.
      
      Introduced in 06da92283 ("[IPV6]: Add MLDv2 support."). Credits to Hannes
      Frederic Sowa who also had a hand in this as well. Also thanks to Hangbin Liu
      who did initial testing.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: David Stevens <dlstevens@us.ibm.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89225d1c
    • Y
      tcp: better comments for RTO initiallization · 52f20e65
      Yuchung Cheng 提交于
      Commit 1b7fdd2a("tcp: do not use cached RTT for RTT estimation")
      removes important comments on how RTO is initialized and updated.
      Hopefully this patch puts those information back.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52f20e65
    • P
      vxlan: Optimize vxlan rcv · 430eda6d
      Pravin B Shelar 提交于
      vxlan-udp-recv function lookup vxlan_sock struct on every packet
      recv by using udp-port number. we can use sk->sk_user_data to
      store vxlan_sock and avoid lookup.
      I have open coded rcu-api to store and read vxlan_sock from
      sk_user_data to avoid sparse warning as sk_user_data is not
      __rcu pointer.
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      430eda6d
    • A
      f8de3104
    • A
      atm: nicstar: re-use native mac_pton() helper · 8390f814
      Andy Shevchenko 提交于
      There is a nice helper to parse MAC. Let's use it and remove custom
      implementation.
      Signed-off-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8390f814
    • S
      driver:stmmac: Adjust time stamp increase for 0.465 ns accurate only when Time... · 0cf91580
      Sonic Zhang 提交于
      driver:stmmac: Adjust time stamp increase for 0.465 ns accurate only when Time stamp binary rollover is set.
      
      The synopsys spec says When TSCRLSSR is cleard, the rollover value of
      sub-second register is 0x7FFFFFFF(0.465 ns per clock).
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0cf91580
    • A
      net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4 · c08751c8
      Alexander Sverdlin 提交于
      net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
      
      Initially the problem was observed with ipsec, but later it became clear that
      SCTP data chunk fragmentation algorithm has problems with MTU values which are
      not multiple of 4. Test program was used which just transmits 2000 bytes long
      packets to other host. tcpdump was used to observe re-fragmentation in IP layer
      after SCTP already fragmented data chunks.
      
      With MTU 1500:
      12:54:34.082904 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 1500)
          10.151.38.153.39303 > 10.151.24.91.54321: sctp (1) [DATA] (B) [TSN: 2366088589] [SID: 0] [SSEQ 1] [PPID 0x0]
      12:54:34.082933 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 596)
          10.151.38.153.39303 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 2366088590] [SID: 0] [SSEQ 1] [PPID 0x0]
      12:54:34.090576 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
          10.151.24.91.54321 > 10.151.38.153.39303: sctp (1) [SACK] [cum ack 2366088590] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
      
      With MTU 1499:
      13:02:49.955220 IP (tos 0x2,ECT(0), ttl 64, id 48215, offset 0, flags [+], proto SCTP (132), length 1492)
          10.151.38.153.39084 > 10.151.24.91.54321: sctp[|sctp]
      13:02:49.955249 IP (tos 0x2,ECT(0), ttl 64, id 48215, offset 1472, flags [none], proto SCTP (132), length 28)
          10.151.38.153 > 10.151.24.91: ip-proto-132
      13:02:49.955262 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 600)
          10.151.38.153.39084 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 404355346] [SID: 0] [SSEQ 1] [PPID 0x0]
      13:02:49.956770 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
          10.151.24.91.54321 > 10.151.38.153.39084: sctp (1) [SACK] [cum ack 404355346] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
      
      Here problem in data portion limit calculation leads to re-fragmentation in IP,
      which is sub-optimal. The problem is max_data initial value, which doesn't take
      into account the fact, that data chunk must be padded to 4-bytes boundary.
      It's enough to correct max_data, because all later adjustments are correctly
      aligned to 4-bytes boundary.
      
      After the fix is applied, everything is fragmented correctly for uneven MTUs:
      15:16:27.083881 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 1496)
          10.151.38.153.53417 > 10.151.24.91.54321: sctp (1) [DATA] (B) [TSN: 3077098183] [SID: 0] [SSEQ 1] [PPID 0x0]
      15:16:27.083907 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 600)
          10.151.38.153.53417 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 3077098184] [SID: 0] [SSEQ 1] [PPID 0x0]
      15:16:27.085640 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
          10.151.24.91.54321 > 10.151.38.153.53417: sctp (1) [SACK] [cum ack 3077098184] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
      
      The bug was there for years already, but
       - is a performance issue, the packets are still transmitted
       - doesn't show up with default MTU 1500, but possibly with ipsec (MTU 1438)
      Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@nsn.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c08751c8
    • J
      drivers:net: delete premature free_irq · 0a171933
      Julia Lawall 提交于
      Free_irq is not needed if there has been no request_irq.  Free_irq is
      removed from both the probe and remove functions.  The correct request_irq
      and free_irq are found in the open and close functions.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression e;
      @@
      
      *e = platform_get_irq(...);
      ... when != request_irq(e,...)
      *free_irq(e,...)
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a171933
    • C
      net: sync some IP headers with glibc · cfd280c9
      Carlos O'Donell 提交于
      Solution:
      =========
      
      - Synchronize linux's `include/uapi/linux/in6.h'
        with glibc's `inet/netinet/in.h'.
      - Synchronize glibc's `inet/netinet/in.h with linux's
        `include/uapi/linux/in6.h'.
      - Allow including the headers in either other.
      - First header included defines the structures and macros.
      
      Details:
      ========
      
      The kernel promises not to break the UAPI ABI so I don't
      see why we can't just have the two userspace headers
      coordinate?
      
      If you include the kernel headers first you get those,
      and if you include the glibc headers first you get those,
      and the following patch arranges a coordination and
      synchronization between the two.
      
      Let's handle `include/uapi/linux/in6.h' from linux,
      and `inet/netinet/in.h' from glibc and ensure they compile
      in any order and preserve the required ABI.
      
      These two patches pass the following compile tests:
      
      cat >> test1.c <<EOF
      int main (void) {
        return 0;
      }
      EOF
      gcc -c test1.c
      
      cat >> test2.c <<EOF
      int main (void) {
        return 0;
      }
      EOF
      gcc -c test2.c
      
      One wrinkle is that the kernel has a different name for one of
      the members in ipv6_mreq. In the kernel patch we create a macro
      to cover the uses of the old name, and while that's not entirely
      clean it's one of the best solutions (aside from an anonymous
      union which has other issues).
      
      I've reviewed the code and it looks to me like the ABI is
      assured and everything matches on both sides.
      
      Notes:
      - You want netinet/in.h to include bits/in.h as early as possible,
        but it needs in_addr so define in_addr early.
      - You want bits/in.h included as early as possible so you can use
        the linux specific code to define __USE_KERNEL_DEFS based on
        the _UAPI_* macro definition and use those to cull in.h.
      - glibc was missing IPPROTO_MH, added here.
      
      Compile tested and inspected.
      Reported-by: NThomas Backlund <tmb@mageia.org>
      Cc: Thomas Backlund <tmb@mageia.org>
      Cc: libc-alpha@sourceware.org
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Cc: David S. Miller <davem@davemloft.net>
      Tested-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NCarlos O'Donell <carlos@redhat.com>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfd280c9
    • D
      sfc: check for allocation failure · 42a5a5c1
      Dan Carpenter 提交于
      It upsets static analyzers when we don't check for allocation failure.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42a5a5c1
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next · b163b42f
      David S. Miller 提交于
      Jeff Kirsher says:
      
      ====================
      This series contains updates to igb only.
      
      Todd provides a fix for igb to not look for a PBA in the iNVM on
      devices that are flashless.
      
      Akeem provides igb patches to add a new PHY id for i354, as well as
      a couple of patches to implement the new PHY id.  He also provides
      several patches to correctly report the appropriate media type as
      well as correctly report advertised/supported link for i354 devices.
      Lastly Akeem implements a 1 second delay mechanism for i210 devices
      to avoid erroneous link issue with the link partner.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b163b42f
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next · 48f8e0af
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      The following batch contains:
      
      * Three fixes for the new synproxy target available in your
        net-next tree, from Jesper D. Brouer and Patrick McHardy.
      
      * One fix for TCPMSS to correctly handling the fragmentation
        case, from Phil Oester. I'll pass this one to -stable.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48f8e0af
  3. 04 9月, 2013 3 次提交