1. 21 1月, 2013 2 次提交
  2. 19 1月, 2013 2 次提交
  3. 07 1月, 2013 1 次提交
  4. 05 1月, 2013 1 次提交
    • Y
      ndisc: Remove unused space at tail of skb for ndisc messages. (TAKE 3) · b7dc8c39
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      Currently, the size of skb allocated for NDISC is MAX_HEADER +
      LL_RESERVED_SPACE(dev) + packet length + dev->needed_tailroom,
      but only LL_RESERVED_SPACE(dev) bytes is "reserved" for headers.
      As a result, the skb looks like this (after construction of the
      message):
      
      head       data                   tail                       end
      +--------------------------------------------------------------+
      +           |                      |          |                |
      +--------------------------------------------------------------+
      |<-hlen---->|<---ipv6 packet------>|<--tlen-->|<--MAX_HEADER-->|
          =LL_                               = dev
           RESERVED_                           ->needed_
           SPACE(dev)                            tailroom
      
      As the name implies, "MAX_HEADER" is used for headers, and should
      be "reserved" in prior to packet construction.  Or, if some space
      is really required at the tail of ther skb, it should be
      explicitly documented.
      
      We have several option after construction of NDISC message:
      
      Option 1:
      
      head       data                   tail       end
      +---------------------------------------------+
      +           |                      |          |
      +---------------------------------------------+
      |<-hlen---->|<---ipv6 packet------>|<--tlen-->|
         =LL_                                = dev
          RESERVED_                           ->needed_
          SPACE(dev)                            tailroom
      
      Option 2:
      
      head            data                   tail       end
      +--------------------------------------------------+
      +                |                      |          |
      +--------------------------------------------------+
      |<--MAX_HEADER-->|<---ipv6 packet------>|<--tlen-->|
                                                  = dev
                                                   ->needed_
                                                     tailroom
      
      Option 3:
      
      head                        data                   tail       end
      +--------------------------------------------------------------+
      +                |           |                      |          |
      +--------------------------------------------------------------+
      |<--MAX_HEADER-->|<-hlen---->|<---ipv6 packet------>|<--tlen-->|
                          =LL_                                = dev
                           RESERVED_                          ->needed_
                           SPACE(dev)                           tailroom
      
      Our tunnel drivers try expanding headroom and the space for tunnel
      encapsulation was not a mandatory space -- so we are not seeing
      bugs here --, but just for optimization for performance critial
      situations.
      
      Since NDISC messages are not performance critical unlike TCP,
      and as we know outgoing device, LL_RESERVED_SPACE(dev) should be
      just enough for the device in most (if not all) cases:
        LL_RESERVED_SPACE(dev) <= LL_MAX_HEADER <= MAX_HEADER
      Note that LL_RESERVED_SPACE(dev) is also enough for NDISC over
      SIT (e.g., ISATAP).
      
      So, I think Option 1 is just fine here.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7dc8c39
  5. 15 12月, 2012 1 次提交
  6. 14 12月, 2012 1 次提交
  7. 13 12月, 2012 1 次提交
  8. 02 12月, 2012 1 次提交
  9. 14 11月, 2012 1 次提交
  10. 13 11月, 2012 1 次提交
  11. 10 11月, 2012 1 次提交
  12. 08 11月, 2012 1 次提交
  13. 04 11月, 2012 1 次提交
  14. 12 7月, 2012 3 次提交
  15. 11 7月, 2012 1 次提交
  16. 09 6月, 2012 1 次提交
  17. 19 5月, 2012 1 次提交
  18. 17 5月, 2012 1 次提交
  19. 16 5月, 2012 2 次提交
  20. 14 4月, 2012 1 次提交
    • G
      ipv6: fix problem with expired dst cache · 1716a961
      Gao feng 提交于
      If the ipv6 dst cache which copy from the dst generated by ICMPV6 RA packet.
      this dst cache will not check expire because it has no RTF_EXPIRES flag.
      So this dst cache will always be used until the dst gc run.
      
      Change the struct dst_entry,add a union contains new pointer from and expires.
      When rt6_info.rt6i_flags has no RTF_EXPIRES flag,the dst.expires has no use.
      we can use this field to point to where the dst cache copy from.
      The dst.from is only used in IPV6.
      
      rt6_check_expired check if rt6_info.dst.from is expired.
      
      ip6_rt_copy only set dst.from when the ort has flag RTF_ADDRCONF
      and RTF_DEFAULT.then hold the ort.
      
      ip6_dst_destroy release the ort.
      
      Add some functions to operate the RTF_EXPIRES flag and expires(from) together.
      and change the code to use these new adding functions.
      
      Changes from v5:
      modify ip6_route_add and ndisc_router_discovery to use new adding functions.
      
      Only set dst.from when the ort has flag RTF_ADDRCONF
      and RTF_DEFAULT.then hold the ort.
      Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1716a961
  21. 13 4月, 2012 1 次提交
  22. 02 4月, 2012 1 次提交
  23. 23 2月, 2012 1 次提交
  24. 28 1月, 2012 2 次提交
  25. 05 1月, 2012 1 次提交
    • N
      ipv6: Check RA for sllao when configuring optimistic ipv6 address (v2) · e6bff995
      Neil Horman 提交于
      Recently Dave noticed that a test we did in ipv6_add_addr to see if we next hop
      route for the interface we're adding an addres to was wrong (see commit
      7ffbcecb).  for one, it never triggers, and two,
      it was completely wrong to begin with.  This test was meant to cover this
      section of RFC 4429:
      
      3.3 Modifications to RFC 2462 Stateless Address Autoconfiguration
      
         * (modifies section 5.5) A host MAY choose to configure a new address
              as an Optimistic Address.  A host that does not know the SLLAO
              of its router SHOULD NOT configure a new address as Optimistic.
              A router SHOULD NOT configure an Optimistic Address.
      
      This patch should bring us into proper compliance with the above clause.  Since
      we only add a SLAAC address after we've received a RA which may or may not
      contain a source link layer address option, we can pass a pointer to that option
      to addrconf_prefix_rcv (which may be null if the option is not present), and
      only set the optimistic flag if the option was found in the RA.
      
      Change notes:
      (v2) modified the new parameter to addrconf_prefix_rcv to be a bool rather than
      a pointer to make its use more clear as per request from davem.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6bff995
  26. 29 12月, 2011 2 次提交
  27. 07 12月, 2011 1 次提交
  28. 06 12月, 2011 1 次提交
  29. 01 12月, 2011 1 次提交
  30. 23 11月, 2011 2 次提交
  31. 19 11月, 2011 1 次提交
    • H
      ipv6: Remove all uses of LL_ALLOCATED_SPACE · a7ae1992
      Herbert Xu 提交于
      ipv6: Remove all uses of LL_ALLOCATED_SPACE
      
      The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
      alignment to the sum of needed_headroom and needed_tailroom.  As
      the amount that is then reserved for head room is needed_headroom
      with alignment, this means that the tail room left may be too small.
      
      This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv6
      with the macro LL_RESERVED_SPACE and direct reference to
      needed_tailroom.
      
      This also fixes the problem with needed_headroom changing between
      allocating the skb and reserving the head room.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7ae1992
  32. 14 11月, 2011 1 次提交
    • E
      neigh: new unresolved queue limits · 8b5c171b
      Eric Dumazet 提交于
      Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
      > From: David Miller <davem@davemloft.net>
      > Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
      >
      > > From: Eric Dumazet <eric.dumazet@gmail.com>
      > > Date: Wed, 09 Nov 2011 12:14:09 +0100
      > >
      > >> unres_qlen is the number of frames we are able to queue per unresolved
      > >> neighbour. Its default value (3) was never changed and is responsible
      > >> for strange drops, especially if IP fragments are used, or multiple
      > >> sessions start in parallel. Even a single tcp flow can hit this limit.
      > >  ...
      > >
      > > Ok, I've applied this, let's see what happens :-)
      >
      > Early answer, build fails.
      >
      > Please test build this patch with DECNET enabled and resubmit.  The
      > decnet neigh layer still refers to the removed ->queue_len member.
      >
      > Thanks.
      
      Ouch, this was fixed on one machine yesterday, but not the other one I
      used this morning, sorry.
      
      [PATCH V5 net-next] neigh: new unresolved queue limits
      
      unres_qlen is the number of frames we are able to queue per unresolved
      neighbour. Its default value (3) was never changed and is responsible
      for strange drops, especially if IP fragments are used, or multiple
      sessions start in parallel. Even a single tcp flow can hit this limit.
      
      $ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
      8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5c171b