1. 11 5月, 2007 1 次提交
  2. 26 4月, 2007 19 次提交
  3. 11 2月, 2007 1 次提交
  4. 09 12月, 2006 1 次提交
  5. 07 12月, 2006 1 次提交
  6. 03 12月, 2006 5 次提交
  7. 23 9月, 2006 8 次提交
  8. 14 8月, 2006 1 次提交
    • H
      [INET]: Use pskb_trim_unique when trimming paged unique skbs · e9fa4f7b
      Herbert Xu 提交于
      The IPv4/IPv6 datagram output path was using skb_trim to trim paged
      packets because they know that the packet has not been cloned yet
      (since the packet hasn't been given to anything else in the system).
      
      This broke because skb_trim no longer allows paged packets to be
      trimmed.  Paged packets must be given to one of the pskb_trim functions
      instead.
      
      This patch adds a new pskb_trim_unique function to cover the IPv4/IPv6
      datagram output path scenario and replaces the corresponding skb_trim
      calls with it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9fa4f7b
  9. 03 8月, 2006 3 次提交
    • W
      [IPV6]: SNMPv2 "ipv6IfStatsOutFragCreates" counter error · dafee490
      Wei Dong 提交于
        When I tested linux kernel 2.6.71.7 about statistics
      "ipv6IfStatsOutFragCreates", and found that it couldn't increase
      correctly. The criteria is RFC 2465:
      
        ipv6IfStatsOutFragCreates OBJECT-TYPE
            SYNTAX      Counter32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
               "The number of output datagram fragments that have
               been generated as a result of fragmentation at
               this output interface."
            ::= { ipv6IfStatsEntry 15 }
      
      I think there are two issues in Linux kernel. 
      1st:
      RFC2465 specifies the counter is "The number of output datagram
      fragments...". I think increasing this counter after output a fragment
      successfully is better. And it should not be increased even though a
      fragment is created but failed to output.
      
      2nd:
      If we send a big ICMP/ICMPv6 echo request to a host, and receive
      ICMP/ICMPv6 echo reply consisted of some fragments. As we know that in
      Linux kernel first fragmentation occurs in ICMP layer(maybe saying
      transport layer is better), but this is not the "real"
      fragmentation,just do some "pre-fragment" -- allocate space for date,
      and form a frag_list, etc. The "real" fragmentation happens in IP layer
      -- set offset and MF flag and so on. So I think in "fast path" for
      ip_fragment/ip6_fragment, if we send a fragment which "pre-fragment" by
      upper layer we should also increase "ipv6IfStatsOutFragCreates".
      Signed-off-by: NWei Dong <weid@nanjing-fnst.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dafee490
    • W
      [IPV6]: SNMPv2 "ipv6IfStatsInHdrErrors" counter error · 32c524d1
      Wei Dong 提交于
        When I tested Linux kernel 2.6.17.7 about statistics
      "ipv6IfStatsInHdrErrors", found that this counter couldn't increase
      correctly. The criteria is RFC2465:
        ipv6IfStatsInHdrErrors OBJECT-TYPE
            SYNTAX     Counter3
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION
               "The number of input datagrams discarded due to
               errors in their IPv6 headers, including version
               number mismatch, other format errors, hop count
               exceeded, errors discovered in processing their
               IPv6 options, etc."
            ::= { ipv6IfStatsEntry 2 }
      
      When I send TTL=0 and TTL=1 a packet to a router which need to be
      forwarded, router just sends an ICMPv6 message to tell the sender that
      TIME_EXCEED and HOPLIMITS, but no increments for this counter(in the
      function ip6_forward).
      Signed-off-by: NWei Dong <weid@nanjing-fnst.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32c524d1
    • H
      [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls · 497c615a
      Herbert Xu 提交于
      The current users of ip6_dst_lookup can be divided into two classes:
      
      1) The caller holds no locks and is in user-context (UDP).
      2) The caller does not want to lookup the dst cache at all.
      
      The second class covers everyone except UDP because most people do
      the cache lookup directly before calling ip6_dst_lookup.  This patch
      adds ip6_sk_dst_lookup for the first class.
      
      Similarly ip6_dst_store users can be divded into those that need to
      take the socket dst lock and those that don't.  This patch adds
      __ip6_dst_store for those (everyone except UDP/datagram) that don't
      need an extra lock.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      497c615a