1. 13 12月, 2011 1 次提交
    • L
      ipv6: Fix for adding multicast route for loopback device automatically. · 4af04aba
      Li Wei 提交于
      There is no obvious reason to add a default multicast route for loopback
      devices, otherwise there would be a route entry whose dst.error set to
      -ENETUNREACH that would blocking all multicast packets.
      
      ====================
      
      [ more detailed explanation ]
      
      The problem is that the resulting routing table depends on the sequence
      of interface's initialization and in some situation, that would block all
      muticast packets. Suppose there are two interfaces on my computer
      (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
      table(for multicast) would be
      
      # ip -6 route show | grep ff00::
      unreachable ff00::/8 dev lo metric 256 error -101
      ff00::/8 dev eth0 metric 256
      
      When sending multicasting packets, routing subsystem will return the first
      route entry which with a error set to -101(ENETUNREACH).
      
      I know the kernel will set the default ipv6 address for 'lo' when it is up
      and won't set the default multicast route for it, but there is no reason to
      stop 'init' program from setting address for 'lo', and that is exactly what
      systemd did.
      
      I am sure there is something wrong with kernel or systemd, currently I preferred
      kernel caused this problem.
      
      ====================
      Signed-off-by: NLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4af04aba
  2. 02 12月, 2011 1 次提交
  3. 29 11月, 2011 1 次提交
  4. 27 11月, 2011 3 次提交
  5. 24 11月, 2011 3 次提交
  6. 23 11月, 2011 1 次提交
  7. 14 11月, 2011 1 次提交
    • J
      ip6_tunnel: copy parms.name after register_netdevice · 731abb9c
      Josh Boyer 提交于
      Commit 1c5cae81 removed an explicit call to dev_alloc_name in ip6_tnl_create
      because register_netdevice will now create a valid name.  This works for the
      net_device itself.
      
      However the tunnel keeps a copy of the name in the parms structure for the
      ip6_tnl associated with the tunnel.  parms.name is set by copying the net_device
      name in ip6_tnl_dev_init_gen.  That function is called from ip6_tnl_dev_init in
      ip6_tnl_create, but it is done before register_netdevice is called so the name
      is set to a bogus value in the parms.name structure.
      
      This shows up if you do a simple tunnel add, followed by a tunnel show:
      
      [root@localhost ~]# ip -6 tunnel add remote fec0::100 local fec0::200
      [root@localhost ~]# ip -6 tunnel show
      ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
      ip6tnl%d: ipv6/ipv6 remote fec0::100 local fec0::200 encaplimit 4 hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
      [root@localhost ~]#
      
      Fix this by moving the strcpy out of ip6_tnl_dev_init_gen, and calling it after
      register_netdevice has successfully returned.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      731abb9c
  8. 13 11月, 2011 1 次提交
  9. 10 11月, 2011 2 次提交
  10. 09 11月, 2011 1 次提交
  11. 02 11月, 2011 1 次提交
  12. 01 11月, 2011 3 次提交
  13. 30 10月, 2011 1 次提交
    • A
      ipv6: fix route lookup in addrconf_prefix_rcv() · 14ef37b6
      Andreas Hofmeister 提交于
      The route lookup to find a previously auto-configured route for a prefixes used
      to use rt6_lookup(), with the prefix from the RA used as an address. However,
      that kind of lookup ignores routing tables, the prefix length and route flags,
      so when there were other matching routes, even in different tables and/or with
      a different prefix length, the wrong route would be manipulated.
      
      Now, a new function "addrconf_get_prefix_route()" is used for the route lookup,
      which searches in RT6_TABLE_PREFIX and takes the prefix-length and route flags
      into account.
      Signed-off-by: NAndreas Hofmeister <andi@collax.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14ef37b6
  14. 29 10月, 2011 1 次提交
  15. 28 10月, 2011 1 次提交
  16. 27 10月, 2011 1 次提交
  17. 25 10月, 2011 1 次提交
    • A
      ipv6: Do not use routes from locally generated RAs · 9f56220f
      Andreas Hofmeister 提交于
      When hybrid mode is enabled (accept_ra == 2), the kernel also sees RAs
      generated locally. This is useful since it allows the kernel to auto-configure
      its own interface addresses.
      
      However, if 'accept_ra_defrtr' and/or 'accept_ra_rtr_pref' are set and the
      locally generated RAs announce the default route and/or other route information,
      the kernel happily inserts bogus routes with its own address as gateway.
      
      With this patch, adding routes from an RA will be skiped when the RAs source
      address matches any local address, just as if 'accept_ra_defrtr' and
      'accept_ra_rtr_pref' were set to 0.
      Signed-off-by: NAndreas Hofmeister <andi@collax.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9f56220f
  18. 24 10月, 2011 1 次提交
  19. 21 10月, 2011 2 次提交
  20. 20 10月, 2011 1 次提交
  21. 19 10月, 2011 4 次提交
  22. 18 10月, 2011 1 次提交
  23. 14 10月, 2011 1 次提交
    • E
      net: more accurate skb truesize · 87fb4b7b
      Eric Dumazet 提交于
      skb truesize currently accounts for sk_buff struct and part of skb head.
      kmalloc() roundings are also ignored.
      
      Considering that skb_shared_info is larger than sk_buff, its time to
      take it into account for better memory accounting.
      
      This patch introduces SKB_TRUESIZE(X) macro to centralize various
      assumptions into a single place.
      
      At skb alloc phase, we put skb_shared_info struct at the exact end of
      skb head, to allow a better use of memory (lowering number of
      reallocations), since kmalloc() gives us power-of-two memory blocks.
      
      Unless SLUB/SLUB debug is active, both skb->head and skb_shared_info are
      aligned to cache lines, as before.
      
      Note: This patch might trigger performance regressions because of
      misconfigured protocol stacks, hitting per socket or global memory
      limits that were previously not reached. But its a necessary step for a
      more accurate memory accounting.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Andi Kleen <ak@linux.intel.com>
      CC: Ben Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87fb4b7b
  24. 11 10月, 2011 1 次提交
  25. 05 10月, 2011 1 次提交
  26. 29 9月, 2011 1 次提交
  27. 28 9月, 2011 3 次提交