1. 03 8月, 2011 1 次提交
  2. 22 7月, 2011 1 次提交
  3. 18 7月, 2011 1 次提交
  4. 17 7月, 2011 2 次提交
  5. 14 7月, 2011 1 次提交
    • D
      net: Embed hh_cache inside of struct neighbour. · f6b72b62
      David S. Miller 提交于
      Now that there is a one-to-one correspondance between neighbour
      and hh_cache entries, we no longer need:
      
      1) dynamic allocation
      2) attachment to dst->hh
      3) refcounting
      
      Initialization of the hh_cache entry is indicated by hh_len
      being non-zero, and such initialization is always done with
      the neighbour's lock held as a writer.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6b72b62
  6. 07 5月, 2011 1 次提交
  7. 23 4月, 2011 1 次提交
  8. 16 4月, 2011 1 次提交
  9. 31 3月, 2011 1 次提交
  10. 13 3月, 2011 2 次提交
  11. 03 3月, 2011 1 次提交
  12. 02 3月, 2011 7 次提交
  13. 01 3月, 2011 1 次提交
  14. 26 2月, 2011 1 次提交
  15. 05 2月, 2011 1 次提交
  16. 13 1月, 2011 1 次提交
  17. 20 12月, 2010 1 次提交
  18. 24 9月, 2010 1 次提交
  19. 22 9月, 2010 1 次提交
    • E
      ip: fix truesize mismatch in ip fragmentation · 3d13008e
      Eric Dumazet 提交于
      Special care should be taken when slow path is hit in ip_fragment() :
      
      When walking through frags, we transfert truesize ownership from skb to
      frags. Then if we hit a slow_path condition, we must undo this or risk
      uncharging frags->truesize twice, and in the end, having negative socket
      sk_wmem_alloc counter, or even freeing socket sooner than expected.
      
      Many thanks to Nick Bowler, who provided a very clean bug report and
      test program.
      
      Thanks to Jarek for reviewing my first patch and providing a V2
      
      While Nick bisection pointed to commit 2b85a34e (net: No more
      expensive sock_hold()/sock_put() on each tx), underlying bug is older
      (2.6.12-rc5)
      
      A side effect is to extend work done in commit b2722b1c
      (ip_fragment: also adjust skb->truesize for packets not owned by a
      socket) to ipv6 as well.
      Reported-and-bisected-by: NNick Bowler <nbowler@elliptictech.com>
      Tested-by: NNick Bowler <nbowler@elliptictech.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Jarek Poplawski <jarkao2@gmail.com>
      CC: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d13008e
  20. 23 8月, 2010 1 次提交
  21. 11 6月, 2010 1 次提交
  22. 28 5月, 2010 1 次提交
  23. 11 5月, 2010 1 次提交
    • P
      ipv6: ip6mr: support multiple tables · d1db275d
      Patrick McHardy 提交于
      This patch adds support for multiple independant multicast routing instances,
      named "tables".
      
      Userspace multicast routing daemons can bind to a specific table instance by
      issuing a setsockopt call using a new option MRT6_TABLE. The table number is
      stored in the raw socket data and affects all following ip6mr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
      is created with a default routing rule pointing to it. Newly created pim6reg
      devices have the table number appended ("pim6regX"), with the exception of
      devices created in the default table, which are named just "pim6reg" for
      compatibility reasons.
      
      Packets are directed to a specific table instance using routing rules,
      similar to how regular routing rules work. Currently iif, oif and mark
      are supported as keys, source and destination addresses could be supported
      additionally.
      
      Example usage:
      
      - bind pimd/xorp/... to a specific table:
      
      uint32_t table = 123;
      setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip -6 mrule add iif eth0 lookup 123
      # ip -6 mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d1db275d
  24. 01 5月, 2010 1 次提交
  25. 24 4月, 2010 2 次提交
  26. 22 4月, 2010 1 次提交
    • S
      ipv6: allow to send packet after receiving ICMPv6 Too Big message with MTU... · f2228f78
      Shan Wei 提交于
      ipv6: allow to send packet after receiving ICMPv6 Too Big message with MTU field less than IPV6_MIN_MTU
      
      According to RFC2460, PMTU is set to the IPv6 Minimum Link
      MTU (1280) and a fragment header should always be included
      after a node receiving Too Big message reporting PMTU is
      less than the IPv6 Minimum Link MTU.
      
      After receiving a ICMPv6 Too Big message reporting PMTU is
      less than the IPv6 Minimum Link MTU, sctp *can't* send any
      data/control chunk that total length including IPv6 head
      and IPv6 extend head is less than IPV6_MIN_MTU(1280 bytes).
      
      The failure occured in p6_fragment(), about reason
      see following(take SHUTDOWN chunk for example):
      sctp_packet_transmit (SHUTDOWN chunk, len=16 byte)
      |------sctp_v6_xmit (local_df=0)
         |------ip6_xmit
             |------ip6_output (dst_allfrag is ture)
                 |------ip6_fragment
      
      In ip6_fragment(), for local_df=0, drops the the packet
      and returns EMSGSIZE.
      
      The patch fixes it with adding check length of skb->len.
      In this case, Ipv6 not to fragment upper protocol data,
      just only add a fragment header before it.
      Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2228f78
  27. 19 4月, 2010 2 次提交
  28. 16 4月, 2010 3 次提交