1. 05 2月, 2017 3 次提交
    • D
      net: ipv6: Change notifications for multipath delete to RTA_MULTIPATH · 16a16cd3
      David Ahern 提交于
      If an entire multipath route is deleted using prefix and len (without any
      nexthops), send a single RTM_DELROUTE notification with the full route
      using RTA_MULTIPATH. This is done by generating the skb before the route
      delete when all of the sibling routes are still present but sending it
      after the route has been removed from the FIB. The skip_notify flag
      is used to tell the lower fib code not to send notifications for the
      individual nexthop routes.
      
      If a route is deleted using RTA_MULTIPATH for any nexthops or a single
      nexthop entry is deleted, then the nexthops are deleted one at a time with
      notifications sent as each hop is deleted. This is necessary given that
      IPv6 allows individual hops within a route to be deleted.
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16a16cd3
    • D
      net: ipv6: Change notifications for multipath add to RTA_MULTIPATH · 3b1137fe
      David Ahern 提交于
      Change ip6_route_multipath_add to send one notifciation with the full
      route encoded with RTA_MULTIPATH instead of a series of individual routes.
      This is done by adding a skip_notify flag to the nl_info struct. The
      flag is used to skip sending of the notification in the fib code that
      actually inserts the route. Once the full route has been added, a
      notification is generated with all nexthops.
      
      ip6_route_multipath_add handles 3 use cases: new routes, route replace,
      and route append. The multipath notification generated needs to be
      consistent with the order of the nexthops and it should be consistent
      with the order in a FIB dump which means the route with the first nexthop
      needs to be used as the route reference. For the first 2 cases (new and
      replace), a reference to the route used to send the notification is
      obtained by saving the first route added. For the append case, the last
      route added is used to loop back to its first sibling route which is
      the first nexthop in the multipath route.
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b1137fe
    • D
      net: ipv6: Add support to dump multipath routes via RTA_MULTIPATH attribute · beb1afac
      David Ahern 提交于
      IPv6 returns multipath routes as a series of individual routes making
      their display and handling by userspace different and more complicated
      than IPv4, putting the burden on the user to see that a route is part of
      a multipath route and internally creating a multipath route if desired
      (e.g., libnl does this as of commit 29b71371e764). This patch addresses
      this difference, allowing multipath routes to be returned using the
      RTA_MULTIPATH attribute.
      
      The end result is that IPv6 multipath routes can be treated and displayed
      in a format similar to IPv4:
      
          $ ip -6 ro ls vrf red
          2001:db8:1::/120 dev eth1 proto kernel metric 256  pref medium
          2001:db8:2::/120 dev eth2 proto kernel metric 256  pref medium
          2001:db8:200::/120 metric 1024
      	    nexthop via 2001:db8:1::2  dev eth1 weight 1
      	    nexthop via 2001:db8:2::2  dev eth2 weight 1
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      beb1afac
  2. 02 2月, 2017 1 次提交
  3. 10 9月, 2016 1 次提交
    • G
      ipv6: report NLM_F_CREATE and NLM_F_EXCL flags in RTM_NEWROUTE events · 73483c12
      Guillaume Nault 提交于
      Since commit 37a1d361 ("ipv6: include NLM_F_REPLACE in route
      replace notifications"), RTM_NEWROUTE notifications have their
      NLM_F_REPLACE flag set if the new route replaced a preexisting one.
      However, other flags aren't set.
      
      This patch reports the missing NLM_F_CREATE and NLM_F_EXCL flag bits.
      
      NLM_F_APPEND is not reported, because in ipv6 a NLM_F_CREATE request
      is interpreted as an append request (contrary to ipv4, "prepend" is not
      supported, so if NLM_F_EXCL is not set then NLM_F_APPEND is implicit).
      
      As a result, the possible flag combination can now be reported
      (iproute2's terminology into parentheses):
      
        * NLM_F_CREATE | NLM_F_EXCL: route didn't exist, exclusive creation
          ("add").
        * NLM_F_CREATE: route did already exist, new route added after
          preexisting ones ("append").
        * NLM_F_REPLACE: route did already exist, new route replaced the
          first preexisting one ("change").
      Signed-off-by: NGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73483c12
  4. 06 7月, 2016 1 次提交
  5. 07 5月, 2016 1 次提交
  6. 09 3月, 2016 3 次提交
  7. 23 10月, 2015 1 次提交
  8. 13 10月, 2015 1 次提交
  9. 18 9月, 2015 1 次提交
  10. 16 9月, 2015 2 次提交
    • M
      ipv6: Replace spinlock with seqlock and rcu in ip6_tunnel · 70da5b5c
      Martin KaFai Lau 提交于
      This patch uses a seqlock to ensure consistency between idst->dst and
      idst->cookie.  It also makes dst freeing from fib tree to undergo a
      rcu grace period.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70da5b5c
    • M
      ipv6: Avoid double dst_free · 8e3d5be7
      Martin KaFai Lau 提交于
      It is a prep work to get dst freeing from fib tree undergo
      a rcu grace period.
      
      The following is a common paradigm:
      if (ip6_del_rt(rt))
      	dst_free(rt)
      
      which means, if rt cannot be deleted from the fib tree, dst_free(rt) now.
      1. We don't know the ip6_del_rt(rt) failure is because it
         was not managed by fib tree (e.g. DST_NOCACHE) or it had already been
         removed from the fib tree.
      2. If rt had been managed by the fib tree, ip6_del_rt(rt) failure means
         dst_free(rt) has been called already.  A second
         dst_free(rt) is not always obviously safe.  The rt may have
         been destroyed already.
      3. If rt is a DST_NOCACHE, dst_free(rt) should not be called.
      4. It is a stopper to make dst freeing from fib tree undergo a
         rcu grace period.
      
      This patch is to use a DST_NOCACHE flag to indicate a rt is
      not managed by the fib tree.
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e3d5be7
  11. 21 8月, 2015 1 次提交
  12. 18 8月, 2015 1 次提交
    • M
      ipv6: Fix a potential deadlock when creating pcpu rt · 9c7370a1
      Martin KaFai Lau 提交于
      rt6_make_pcpu_route() is called under read_lock(&table->tb6_lock).
      rt6_make_pcpu_route() calls ip6_rt_pcpu_alloc(rt) which then
      calls dst_alloc().  dst_alloc() _may_ call ip6_dst_gc() which takes
      the write_lock(&tabl->tb6_lock).  A visualized version:
      
      read_lock(&table->tb6_lock);
      rt6_make_pcpu_route();
      => ip6_rt_pcpu_alloc();
      => dst_alloc();
      => ip6_dst_gc();
      => write_lock(&table->tb6_lock); /* oops */
      
      The fix is to do a read_unlock first before calling ip6_rt_pcpu_alloc().
      
      A reported stack:
      
      [141625.537638] INFO: rcu_sched self-detected stall on CPU { 27}  (t=60000 jiffies g=4159086 c=4159085 q=2139)
      [141625.547469] Task dump for CPU 27:
      [141625.550881] mtr             R  running task        0 22121  22081 0x00000008
      [141625.558069]  0000000000000000 ffff88103f363d98 ffffffff8106e488 000000000000001b
      [141625.565641]  ffffffff81684900 ffff88103f363db8 ffffffff810702b0 0000000008000000
      [141625.573220]  ffffffff81684900 ffff88103f363de8 ffffffff8108df9f ffff88103f375a00
      [141625.580803] Call Trace:
      [141625.583345]  <IRQ>  [<ffffffff8106e488>] sched_show_task+0xc1/0xc6
      [141625.589650]  [<ffffffff810702b0>] dump_cpu_task+0x35/0x39
      [141625.595144]  [<ffffffff8108df9f>] rcu_dump_cpu_stacks+0x6a/0x8c
      [141625.601320]  [<ffffffff81090606>] rcu_check_callbacks+0x1f6/0x5d4
      [141625.607669]  [<ffffffff810940c8>] update_process_times+0x2a/0x4f
      [141625.613925]  [<ffffffff8109fbee>] tick_sched_handle+0x32/0x3e
      [141625.619923]  [<ffffffff8109fc2f>] tick_sched_timer+0x35/0x5c
      [141625.625830]  [<ffffffff81094a1f>] __hrtimer_run_queues+0x8f/0x18d
      [141625.632171]  [<ffffffff81094c9e>] hrtimer_interrupt+0xa0/0x166
      [141625.638258]  [<ffffffff8102bf2a>] local_apic_timer_interrupt+0x4e/0x52
      [141625.645036]  [<ffffffff8102c36f>] smp_apic_timer_interrupt+0x39/0x4a
      [141625.651643]  [<ffffffff8140b9e8>] apic_timer_interrupt+0x68/0x70
      [141625.657895]  <EOI>  [<ffffffff81346ee8>] ? dst_destroy+0x7c/0xb5
      [141625.664188]  [<ffffffff813d45b5>] ? fib6_flush_trees+0x20/0x20
      [141625.670272]  [<ffffffff81082b45>] ? queue_write_lock_slowpath+0x60/0x6f
      [141625.677140]  [<ffffffff8140aa33>] _raw_write_lock_bh+0x23/0x25
      [141625.683218]  [<ffffffff813d4553>] __fib6_clean_all+0x40/0x82
      [141625.689124]  [<ffffffff813d45b5>] ? fib6_flush_trees+0x20/0x20
      [141625.695207]  [<ffffffff813d6058>] fib6_clean_all+0xe/0x10
      [141625.700854]  [<ffffffff813d60d3>] fib6_run_gc+0x79/0xc8
      [141625.706329]  [<ffffffff813d0510>] ip6_dst_gc+0x85/0xf9
      [141625.711718]  [<ffffffff81346d68>] dst_alloc+0x55/0x159
      [141625.717105]  [<ffffffff813d09b5>] __ip6_dst_alloc.isra.32+0x19/0x63
      [141625.723620]  [<ffffffff813d1830>] ip6_pol_route+0x36a/0x3e8
      [141625.729441]  [<ffffffff813d18d6>] ip6_pol_route_output+0x11/0x13
      [141625.735700]  [<ffffffff813f02c8>] fib6_rule_action+0xa7/0x1bf
      [141625.741698]  [<ffffffff813d18c5>] ? ip6_pol_route_input+0x17/0x17
      [141625.748043]  [<ffffffff81357c48>] fib_rules_lookup+0xb5/0x12a
      [141625.754050]  [<ffffffff81141628>] ? poll_select_copy_remaining+0xf9/0xf9
      [141625.761002]  [<ffffffff813f0535>] fib6_rule_lookup+0x37/0x5c
      [141625.766914]  [<ffffffff813d18c5>] ? ip6_pol_route_input+0x17/0x17
      [141625.773260]  [<ffffffff813d008c>] ip6_route_output+0x7a/0x82
      [141625.779177]  [<ffffffff813c44c8>] ip6_dst_lookup_tail+0x53/0x112
      [141625.785437]  [<ffffffff813c45c3>] ip6_dst_lookup_flow+0x2a/0x6b
      [141625.791604]  [<ffffffff813ddaab>] rawv6_sendmsg+0x407/0x9b6
      [141625.797423]  [<ffffffff813d7914>] ? do_ipv6_setsockopt.isra.8+0xd87/0xde2
      [141625.804464]  [<ffffffff8139d4b4>] inet_sendmsg+0x57/0x8e
      [141625.810028]  [<ffffffff81329ba3>] sock_sendmsg+0x2e/0x3c
      [141625.815588]  [<ffffffff8132be57>] SyS_sendto+0xfe/0x143
      [141625.821063]  [<ffffffff813dd551>] ? rawv6_setsockopt+0x5e/0x67
      [141625.827146]  [<ffffffff8132c9f8>] ? sock_common_setsockopt+0xf/0x11
      [141625.833660]  [<ffffffff8132c08c>] ? SyS_setsockopt+0x81/0xa2
      [141625.839565]  [<ffffffff8140ac17>] entry_SYSCALL_64_fastpath+0x12/0x6a
      
      Fixes: d52d3997 ("pv6: Create percpu rt6_info")
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Reported-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c7370a1
  13. 27 7月, 2015 1 次提交
  14. 22 7月, 2015 1 次提交
  15. 26 5月, 2015 2 次提交
  16. 21 5月, 2015 1 次提交
    • M
      ipv6: fix ECMP route replacement · 27596472
      Michal Kubeček 提交于
      When replacing an IPv6 multipath route with "ip route replace", i.e.
      NLM_F_CREATE | NLM_F_REPLACE, fib6_add_rt2node() replaces only first
      matching route without fixing its siblings, resulting in corrupted
      siblings linked list; removing one of the siblings can then end in an
      infinite loop.
      
      IPv6 ECMP implementation is a bit different from IPv4 so that route
      replacement cannot work in exactly the same way. This should be a
      reasonable approximation:
      
      1. If the new route is ECMP-able and there is a matching ECMP-able one
      already, replace it and all its siblings (if any).
      
      2. If the new route is ECMP-able and no matching ECMP-able route exists,
      replace first matching non-ECMP-able (if any) or just add the new one.
      
      3. If the new route is not ECMP-able, replace first matching
      non-ECMP-able route (if any) or add the new route.
      
      We also need to remove the NLM_F_REPLACE flag after replacing old
      route(s) by first nexthop of an ECMP route so that each subsequent
      nexthop does not replace previous one.
      
      Fixes: 51ebd318 ("ipv6: add support of equal cost multipath (ECMP)")
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27596472
  17. 01 4月, 2015 1 次提交
  18. 27 1月, 2015 1 次提交
    • H
      ipv6: replacing a rt6_info needs to purge possible propagated rt6_infos too · 6e9e16e6
      Hannes Frederic Sowa 提交于
      Lubomir Rintel reported that during replacing a route the interface
      reference counter isn't correctly decremented.
      
      To quote bug <https://bugzilla.kernel.org/show_bug.cgi?id=91941>:
      | [root@rhel7-5 lkundrak]# sh -x lal
      | + ip link add dev0 type dummy
      | + ip link set dev0 up
      | + ip link add dev1 type dummy
      | + ip link set dev1 up
      | + ip addr add 2001:db8:8086::2/64 dev dev0
      | + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
      | + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
      | + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
      | + ip link del dev0 type dummy
      | Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
      |  kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
      |
      | Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
      |  kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
      
      During replacement of a rt6_info we must walk all parent nodes and check
      if the to be replaced rt6_info got propagated. If so, replace it with
      an alive one.
      
      Fixes: 4a287eba ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag")
      Reported-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Tested-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e9e16e6
  19. 18 1月, 2015 1 次提交
    • J
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg 提交于
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      
      This makes the very common pattern of
      
        if (genlmsg_end(...) < 0) { ... }
      
      be a whole bunch of dead code. Many places also simply do
      
        return nlmsg_end(...);
      
      and the caller is expected to deal with it.
      
      This also commonly (at least for me) causes errors, because it is very
      common to write
      
        if (my_function(...))
          /* error condition */
      
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      053c095a
  20. 06 1月, 2015 2 次提交
  21. 07 10月, 2014 5 次提交
  22. 01 10月, 2014 1 次提交
    • H
      ipv6: remove rt6i_genid · 705f1c86
      Hannes Frederic Sowa 提交于
      Eric Dumazet noticed that all no-nonexthop or no-gateway routes which
      are already marked DST_HOST (e.g. input routes routes) will always be
      invalidated during sk_dst_check. Thus per-socket dst caching absolutely
      had no effect and early demuxing had no effect.
      
      Thus this patch removes rt6i_genid: fn_sernum already gets modified during
      add operations, so we only must ensure we mutate fn_sernum during ipv6
      address remove operations. This is a fairly cost extensive operations,
      but address removal should not happen that often. Also our mtu update
      functions do the same and we heard no complains so far. xfrm policy
      changes also cause a call into fib6_flush_trees. Also plug a hole in
      rt6_info (no cacheline changes).
      
      I verified via tracing that this change has effect.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: YOSHIFUJI Hideaki <hideaki@yoshifuji.org>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Martin Lau <kafai@fb.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      705f1c86
  23. 23 8月, 2014 1 次提交
    • B
      net: ipv6: fib: don't sleep inside atomic lock · 793c3b40
      Benjamin Block 提交于
      The function fib6_commit_metrics() allocates a piece of memory in mode
      GFP_KERNEL while holding an atomic lock from higher up in the stack, in
      the function __ip6_ins_rt(). This produces the following BUG:
      
      > BUG: sleeping function called from invalid context at mm/slub.c:1250
      > in_atomic(): 1, irqs_disabled(): 0, pid: 2909, name: dhcpcd
      > 2 locks held by dhcpcd/2909:
      >  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81978e67>] rtnl_lock+0x17/0x20
      >  #1:  (&tb->tb6_lock){++--+.}, at: [<ffffffff81a6951a>] ip6_route_add+0x65a/0x800
      > CPU: 1 PID: 2909 Comm: dhcpcd Not tainted 3.17.0-rc1 #1
      > Hardware name: ASUS All Series/Q87T, BIOS 0216 10/16/2013
      >  0000000000000008 ffff8800c8f13858 ffffffff81af135a 0000000000000000
      >  ffff880212202430 ffff8800c8f13878 ffffffff810f8d3a ffff880212202c98
      >  0000000000000010 ffff8800c8f138c8 ffffffff8121ad0e 0000000000000001
      > Call Trace:
      >  [<ffffffff81af135a>] dump_stack+0x4e/0x68
      >  [<ffffffff810f8d3a>] __might_sleep+0x10a/0x120
      >  [<ffffffff8121ad0e>] kmem_cache_alloc_trace+0x4e/0x190
      >  [<ffffffff81a6bcd6>] ? fib6_commit_metrics+0x66/0x110
      >  [<ffffffff81a6bcd6>] fib6_commit_metrics+0x66/0x110
      >  [<ffffffff81a6cbf3>] fib6_add+0x883/0xa80
      >  [<ffffffff81a6951a>] ? ip6_route_add+0x65a/0x800
      >  [<ffffffff81a69535>] ip6_route_add+0x675/0x800
      >  [<ffffffff81a68f2a>] ? ip6_route_add+0x6a/0x800
      >  [<ffffffff81a6990c>] inet6_rtm_newroute+0x5c/0x80
      >  [<ffffffff8197cf01>] rtnetlink_rcv_msg+0x211/0x260
      >  [<ffffffff81978e67>] ? rtnl_lock+0x17/0x20
      >  [<ffffffff81119708>] ? lock_release_holdtime+0x28/0x180
      >  [<ffffffff81978e67>] ? rtnl_lock+0x17/0x20
      >  [<ffffffff8197ccf0>] ? __rtnl_unlock+0x20/0x20
      >  [<ffffffff819a989e>] netlink_rcv_skb+0x6e/0xd0
      >  [<ffffffff81978ee5>] rtnetlink_rcv+0x25/0x40
      >  [<ffffffff819a8e59>] netlink_unicast+0xd9/0x180
      >  [<ffffffff819a9600>] netlink_sendmsg+0x700/0x770
      >  [<ffffffff81103735>] ? local_clock+0x25/0x30
      >  [<ffffffff8194e83c>] sock_sendmsg+0x6c/0x90
      >  [<ffffffff811f98e3>] ? might_fault+0xa3/0xb0
      >  [<ffffffff8195ca6d>] ? verify_iovec+0x7d/0xf0
      >  [<ffffffff8194ec3e>] ___sys_sendmsg+0x37e/0x3b0
      >  [<ffffffff8111ef15>] ? trace_hardirqs_on_caller+0x185/0x220
      >  [<ffffffff81af979e>] ? mutex_unlock+0xe/0x10
      >  [<ffffffff819a55ec>] ? netlink_insert+0xbc/0xe0
      >  [<ffffffff819a65e5>] ? netlink_autobind.isra.30+0x125/0x150
      >  [<ffffffff819a6520>] ? netlink_autobind.isra.30+0x60/0x150
      >  [<ffffffff819a84f9>] ? netlink_bind+0x159/0x230
      >  [<ffffffff811f989a>] ? might_fault+0x5a/0xb0
      >  [<ffffffff8194f25e>] ? SYSC_bind+0x7e/0xd0
      >  [<ffffffff8194f8cd>] __sys_sendmsg+0x4d/0x80
      >  [<ffffffff8194f912>] SyS_sendmsg+0x12/0x20
      >  [<ffffffff81afc692>] system_call_fastpath+0x16/0x1b
      
      Fixing this by replacing the mode GFP_KERNEL with GFP_ATOMIC.
      Signed-off-by: NBenjamin Block <bebl@mageta.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      793c3b40
  24. 12 5月, 2014 1 次提交
  25. 25 4月, 2014 1 次提交
  26. 30 3月, 2014 3 次提交
  27. 28 3月, 2014 1 次提交
    • M
      ipv6: do not overwrite inetpeer metrics prematurely · e5fd387a
      Michal Kubeček 提交于
      If an IPv6 host route with metrics exists, an attempt to add a
      new route for the same target with different metrics fails but
      rewrites the metrics anyway:
      
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1000
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  rto_min lock 1s
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1500
      RTNETLINK answers: File exists
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  rto_min lock 1.5s
      
      This is caused by all IPv6 host routes using the metrics in
      their inetpeer (or the shared default). This also holds for the
      new route created in ip6_route_add() which shares the metrics
      with the already existing route and thus ip6_route_add()
      rewrites the metrics even if the new route ends up not being
      used at all.
      
      Another problem is that old metrics in inetpeer can reappear
      unexpectedly for a new route, e.g.
      
      12sp0:~ # ip route add fec0::1 dev eth0 rto_min 1000
      12sp0:~ # ip route del fec0::1
      12sp0:~ # ip route add fec0::1 dev eth0
      12sp0:~ # ip route change fec0::1 dev eth0 hoplimit 10
      12sp0:~ # ip -6 route show
      fe80::/64 dev eth0  proto kernel  metric 256
      fec0::1 dev eth0  metric 1024  hoplimit 10 rto_min lock 1s
      
      Resolve the first problem by moving the setting of metrics down
      into fib6_add_rt2node() to the point we are sure we are
      inserting the new route into the tree. Second problem is
      addressed by introducing new flag DST_METRICS_FORCE_OVERWRITE
      which is set for a new host route in ip6_route_add() and makes
      ipv6_cow_metrics() always overwrite the metrics in inetpeer
      (even if they are not "new"); it is reset after that.
      
      v5: use a flag in _metrics member rather than one in flags
      
      v4: fix a typo making a condition always true (thanks to Hannes
      Frederic Sowa)
      
      v3: rewritten based on David Miller's idea to move setting the
      metrics (and allocation in non-host case) down to the point we
      already know the route is to be inserted. Also rebased to
      net-next as it is quite late in the cycle.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5fd387a