1. 07 3月, 2017 1 次提交
  2. 03 3月, 2017 2 次提交
  3. 02 3月, 2017 4 次提交
    • I
      sched/headers: Prepare to move signal wakeup & sigpending methods from... · 174cd4b1
      Ingo Molnar 提交于
      sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>
      
      Fix up affected files that include this signal functionality via sched.h.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      174cd4b1
    • E
      ipv6: orphan skbs in reassembly unit · 48cac18e
      Eric Dumazet 提交于
      Andrey reported a use-after-free in IPv6 stack.
      
      Issue here is that we free the socket while it still has skb
      in TX path and in some queues.
      
      It happens here because IPv6 reassembly unit messes skb->truesize,
      breaking skb_set_owner_w() badly.
      
      We fixed a similar issue for IPV4 in commit 8282f274 ("inet: frag:
      Always orphan skbs inside ip_defrag()")
      Acked-by: NJoe Stringer <joe@ovn.org>
      
      ==================================================================
      BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
      Read of size 8 at addr ffff880062da0060 by task a.out/4140
      
      page:ffffea00018b6800 count:1 mapcount:0 mapping:          (null)
      index:0x0 compound_mapcount: 0
      flags: 0x100000000008100(slab|head)
      raw: 0100000000008100 0000000000000000 0000000000000000 0000000180130013
      raw: dead000000000100 dead000000000200 ffff88006741f140 0000000000000000
      page dumped because: kasan: bad access detected
      
      CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15
       dump_stack+0x292/0x398 lib/dump_stack.c:51
       describe_address mm/kasan/report.c:262
       kasan_report_error+0x121/0x560 mm/kasan/report.c:370
       kasan_report mm/kasan/report.c:392
       __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
       sock_flag ./arch/x86/include/asm/bitops.h:324
       sock_wfree+0x118/0x120 net/core/sock.c:1631
       skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
       skb_release_all+0x15/0x60 net/core/skbuff.c:668
       __kfree_skb+0x15/0x20 net/core/skbuff.c:684
       kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
       inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
       inet_frag_put ./include/net/inet_frag.h:133
       nf_ct_frag6_gather+0x1125/0x38b0 net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn ./include/linux/netfilter.h:102
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook ./include/linux/netfilter.h:212
       __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
       ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
       ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
       ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
       rawv6_push_pending_frames net/ipv6/raw.c:613
       rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x620 net/socket.c:848
       new_sync_write fs/read_write.c:499
       __vfs_write+0x483/0x760 fs/read_write.c:512
       vfs_write+0x187/0x530 fs/read_write.c:560
       SYSC_write fs/read_write.c:607
       SyS_write+0xfb/0x230 fs/read_write.c:599
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      RIP: 0033:0x7ff26e6f5b79
      RSP: 002b:00007ff268e0ed98 EFLAGS: 00000206 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00007ff268e0f9c0 RCX: 00007ff26e6f5b79
      RDX: 0000000000000010 RSI: 0000000020f50fe1 RDI: 0000000000000003
      RBP: 00007ff26ebc1220 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
      R13: 00007ff268e0f9c0 R14: 00007ff26efec040 R15: 0000000000000003
      
      The buggy address belongs to the object at ffff880062da0000
       which belongs to the cache RAWv6 of size 1504
      The buggy address ffff880062da0060 is located 96 bytes inside
       of 1504-byte region [ffff880062da0000, ffff880062da05e0)
      
      Freed by task 4113:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
       slab_free_hook mm/slub.c:1352
       slab_free_freelist_hook mm/slub.c:1374
       slab_free mm/slub.c:2951
       kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
       sk_prot_free net/core/sock.c:1377
       __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sk_free+0x23/0x30 net/core/sock.c:1479
       sock_put ./include/net/sock.h:1638
       sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
       rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
       sock_release+0x8d/0x1e0 net/socket.c:599
       sock_close+0x16/0x20 net/socket.c:1063
       __fput+0x332/0x7f0 fs/file_table.c:208
       ____fput+0x15/0x20 fs/file_table.c:244
       task_work_run+0x19b/0x270 kernel/task_work.c:116
       exit_task_work ./include/linux/task_work.h:21
       do_exit+0x186b/0x2800 kernel/exit.c:839
       do_group_exit+0x149/0x420 kernel/exit.c:943
       SYSC_exit_group kernel/exit.c:954
       SyS_exit_group+0x1d/0x20 kernel/exit.c:952
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Allocated by task 4115:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:544
       slab_post_alloc_hook mm/slab.h:432
       slab_alloc_node mm/slub.c:2708
       slab_alloc mm/slub.c:2716
       kmem_cache_alloc+0x1af/0x250 mm/slub.c:2721
       sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1334
       sk_alloc+0x105/0x1010 net/core/sock.c:1396
       inet6_create+0x44d/0x1150 net/ipv6/af_inet6.c:183
       __sock_create+0x4f6/0x880 net/socket.c:1199
       sock_create net/socket.c:1239
       SYSC_socket net/socket.c:1269
       SyS_socket+0xf9/0x230 net/socket.c:1249
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Memory state around the buggy address:
       ffff880062d9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880062d9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff880062da0000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880062da0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880062da0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48cac18e
    • L
      net: route: add missing nla_policy entry for RTA_MARK attribute · 3b45a410
      Liping Zhang 提交于
      This will add stricter validating for RTA_MARK attribute.
      Signed-off-by: NLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b45a410
    • F
      net/ipv6: avoid possible dead locking on addr_gen_mode sysctl · 8c171d6c
      Felix Jia 提交于
      The addr_gen_mode variable can be accessed by both sysctl and netlink.
      Repleacd rtnl_lock() with rtnl_trylock() protect the sysctl operation to
      avoid the possbile dead lock.`
      Signed-off-by: NFelix Jia <felix.jia@alliedtelesis.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c171d6c
  4. 28 2月, 2017 1 次提交
  5. 27 2月, 2017 1 次提交
  6. 25 2月, 2017 1 次提交
  7. 23 2月, 2017 1 次提交
    • A
      tcp: setup timestamp offset when write_seq already set · 00355fa5
      Alexey Kodanev 提交于
      Found that when randomized tcp offsets are enabled (by default)
      TCP client can still start new connections without them. Later,
      if server does active close and re-uses sockets in TIME-WAIT
      state, new SYN from client can be rejected on PAWS check inside
      tcp_timewait_state_process(), because either tw_ts_recent or
      rcv_tsval doesn't really have an offset set.
      
      Here is how to reproduce it with LTP netstress tool:
          netstress -R 1 &
          netstress -H 127.0.0.1 -lr 1000000 -a1
      
          [...]
          < S  seq 1956977072 win 43690 TS val 295618 ecr 459956970
          > .  ack 1956911535 win 342 TS val 459967184 ecr 1547117608
          < R  seq 1956911535 win 0 length 0
      +1. < S  seq 1956977072 win 43690 TS val 296640 ecr 459956970
          > S. seq 657450664 ack 1956977073 win 43690 TS val 459968205 ecr 296640
      
      Fixes: 95a22cae ("tcp: randomize tcp timestamp offsets for each connection")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      00355fa5
  8. 19 2月, 2017 1 次提交
  9. 15 2月, 2017 5 次提交
  10. 12 2月, 2017 1 次提交
  11. 10 2月, 2017 1 次提交
  12. 09 2月, 2017 7 次提交
    • F
      37b10383
    • F
      xfrm: policy: remove family field · a2817d8b
      Florian Westphal 提交于
      Only needed it to register the policy backend at init time.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      a2817d8b
    • F
      xfrm: policy: remove garbage_collect callback · 3d7d25a6
      Florian Westphal 提交于
      Just call xfrm_garbage_collect_deferred() directly.
      This gets rid of a write to afinfo in register/unregister and allows to
      constify afinfo later on.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      3d7d25a6
    • F
      xfrm: input: constify xfrm_input_afinfo · 960fdfde
      Florian Westphal 提交于
      Nothing writes to these structures (the module owner was not used).
      
      While at it, size xfrm_input_afinfo[] by the highest existing xfrm family
      (INET6), not AF_MAX.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      960fdfde
    • E
      gro_cells: move to net/core/gro_cells.c · 97e219b7
      Eric Dumazet 提交于
      We have many gro cells users, so lets move the code to avoid
      duplication.
      
      This creates a CONFIG_GRO_CELLS option.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97e219b7
    • W
      sit: fix a double free on error path · d7426c69
      WANG Cong 提交于
      Dmitry reported a double free in sit_init_net():
      
        kernel BUG at mm/percpu.c:689!
        invalid opcode: 0000 [#1] SMP KASAN
        Dumping ftrace buffer:
           (ftrace buffer empty)
        Modules linked in:
        CPU: 0 PID: 15692 Comm: syz-executor1 Not tainted 4.10.0-rc6-next-20170206 #1
        Hardware name: Google Google Compute Engine/Google Compute Engine,
        BIOS Google 01/01/2011
        task: ffff8801c9cc27c0 task.stack: ffff88017d1d8000
        RIP: 0010:pcpu_free_area+0x68b/0x810 mm/percpu.c:689
        RSP: 0018:ffff88017d1df488 EFLAGS: 00010046
        RAX: 0000000000010000 RBX: 00000000000007c0 RCX: ffffc90002829000
        RDX: 0000000000010000 RSI: ffffffff81940efb RDI: ffff8801db841d94
        RBP: ffff88017d1df590 R08: dffffc0000000000 R09: 1ffffffff0bb3bdd
        R10: dffffc0000000000 R11: 00000000000135dd R12: ffff8801db841d80
        R13: 0000000000038e40 R14: 00000000000007c0 R15: 00000000000007c0
        FS:  00007f6ea608f700(0000) GS:ffff8801dbe00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 000000002000aff8 CR3: 00000001c8d44000 CR4: 00000000001426f0
        DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
        Call Trace:
         free_percpu+0x212/0x520 mm/percpu.c:1264
         ipip6_dev_free+0x43/0x60 net/ipv6/sit.c:1335
         sit_init_net+0x3cb/0xa10 net/ipv6/sit.c:1831
         ops_init+0x10a/0x530 net/core/net_namespace.c:115
         setup_net+0x2ed/0x690 net/core/net_namespace.c:291
         copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396
         create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106
         unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
         SYSC_unshare kernel/fork.c:2281 [inline]
         SyS_unshare+0x64e/0xfc0 kernel/fork.c:2231
         entry_SYSCALL_64_fastpath+0x1f/0xc2
      
      This is because when tunnel->dst_cache init fails, we free dev->tstats
      once in ipip6_tunnel_init() and twice in sit_init_net(). This looks
      redundant but its ndo_uinit() does not seem enough to clean up everything
      here. So avoid this by setting dev->tstats to NULL after the first free,
      at least for -net.
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d7426c69
    • M
      ipv6: addrconf: fix generation of new temporary addresses · a11a7f71
      Marcus Huewe 提交于
      Under some circumstances it is possible that no new temporary addresses
      will be generated.
      
      For instance, addrconf_prefix_rcv_add_addr() indirectly calls
      ipv6_create_tempaddr(), which creates a tentative temporary address and
      starts dad. Next, addrconf_prefix_rcv_add_addr() indirectly calls
      addrconf_verify_rtnl(). Now, assume that the previously created temporary
      address has the least preferred lifetime among all existing addresses and
      is still tentative (that is, dad is still running). Hence, the next run of
      addrconf_verify_rtnl() is performed when the preferred lifetime of the
      temporary address ends. If dad succeeds before the next run, the temporary
      address becomes deprecated during the next run, but no new temporary
      address is generated.
      
      In order to fix this, schedule the next addrconf_verify_rtnl() run slightly
      before the temporary address becomes deprecated, if dad succeeded.
      Signed-off-by: NMarcus Huewe <suse-tux@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a11a7f71
  13. 08 2月, 2017 5 次提交
  14. 07 2月, 2017 1 次提交
    • L
      ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches · a088d1d7
      Linus Lüssing 提交于
      When for instance a mobile Linux device roams from one access point to
      another with both APs sharing the same broadcast domain and a
      multicast snooping switch in between:
      
      1)    (c) <~~~> (AP1) <--[SSW]--> (AP2)
      
      2)              (AP1) <--[SSW]--> (AP2) <~~~> (c)
      
      Then currently IPv6 multicast packets will get lost for (c) until an
      MLD Querier sends its next query message. The packet loss occurs
      because upon roaming the Linux host so far stayed silent regarding
      MLD and the snooping switch will therefore be unaware of the
      multicast topology change for a while.
      
      This patch fixes this by always resending MLD reports when an interface
      change happens, for instance from NO-CARRIER to CARRIER state.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a088d1d7
  15. 06 2月, 2017 2 次提交
  16. 05 2月, 2017 5 次提交
    • D
      net: ipv6: Use compressed IPv6 addresses showing route replace error · 7d4d5065
      David Ahern 提交于
      ip6_print_replace_route_err logs an error if a route replace fails with
      IPv6 addresses in the full format. e.g,:
      
      IPv6: IPV6: multipath route replace failed (check consistency of installed routes): 2001:0db8:0200:0000:0000:0000:0000:0000 nexthop 2001:0db8:0001:0000:0000:0000:0000:0016 ifi 0
      
      Change the message to dump the addresses in the compressed format.
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d4d5065
    • 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
    • D
      net: ipv6: Allow shorthand delete of all nexthops in multipath route · 0ae81335
      David Ahern 提交于
      IPv4 allows multipath routes to be deleted using just the prefix and
      length. For example:
          $ ip ro ls vrf red
          unreachable default metric 8192
          1.1.1.0/24
              nexthop via 10.100.1.254  dev eth1 weight 1
              nexthop via 10.11.200.2  dev eth11.200 weight 1
          10.11.200.0/24 dev eth11.200 proto kernel scope link src 10.11.200.3
          10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.3
      
          $ ip ro del 1.1.1.0/24 vrf red
      
          $ ip ro ls vrf red
          unreachable default metric 8192
          10.11.200.0/24 dev eth11.200 proto kernel scope link src 10.11.200.3
          10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.3
      
      The same notation does not work with IPv6 because of how multipath routes
      are implemented for IPv6. For IPv6 only the first nexthop of a multipath
      route is deleted if the request contains only a prefix and length. This
      leads to unnecessary complexity in userspace dealing with IPv6 multipath
      routes.
      
      This patch allows all nexthops to be deleted without specifying each one
      in the delete request. Internally, this is done by walking the sibling
      list of the route matching the specifications given (prefix, length,
      metric, protocol, etc).
      
          $  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 via 2001:db8:1::2 dev eth1 metric 1024  pref medium
          2001:db8:200::/120 via 2001:db8:2::2 dev eth2 metric 1024  pref medium
          ...
      
          $ ip -6 ro del vrf red 2001:db8:200::/120
      
          $ 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
          ...
      
      Because IPv6 allows individual nexthops to be deleted without deleting
      the entire route, the ip6_route_multipath_del and non-multipath code
      path (ip6_route_del) have to be discriminated so that all nexthops are
      only deleted for the latter case. This is done by making the existing
      fc_type in fib6_config a u16 and then adding a new u16 field with
      fc_delete_all_nh as the first bit.
      Suggested-by: NDinesh Dutt <ddutt@cumulusnetworks.com>
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ae81335
  17. 04 2月, 2017 1 次提交
    • D
      net: ipv6: Set protocol to kernel for local routes · 94b5e0f9
      David Ahern 提交于
      IPv6 stack does not set the protocol for local routes, so those routes show
      up with proto "none":
          $ ip -6 ro ls table local
          local ::1 dev lo proto none metric 0  pref medium
          local 2100:3:: dev lo proto none metric 0  pref medium
          local 2100:3::4 dev lo proto none metric 0  pref medium
          local fe80:: dev lo proto none metric 0  pref medium
          ...
      
      Set rt6i_protocol to RTPROT_KERNEL for consistency with IPv4. Now routes
      show up with proto "kernel":
          $ ip -6 ro ls table local
          local ::1 dev lo proto kernel metric 0  pref medium
          local 2100:3:: dev lo proto kernel metric 0  pref medium
          local 2100:3::4 dev lo proto kernel metric 0  pref medium
          local fe80:: dev lo proto kernel metric 0  pref medium
          ...
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94b5e0f9