1. 22 4月, 2018 4 次提交
  2. 20 4月, 2018 5 次提交
    • E
      net/ipv6: Fix ip6_convert_metrics() bug · 263243d6
      Eric Dumazet 提交于
      If ip6_convert_metrics() fails to allocate memory, it should not
      overwrite rt->fib6_metrics or we risk a crash later as syzbot found.
      
      BUG: KASAN: null-ptr-deref in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
      BUG: KASAN: null-ptr-deref in refcount_sub_and_test+0x92/0x330 lib/refcount.c:179
      Read of size 4 at addr 0000000000000044 by task syzkaller832429/4487
      
      CPU: 1 PID: 4487 Comm: syzkaller832429 Not tainted 4.16.0+ #6
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1b9/0x294 lib/dump_stack.c:113
       kasan_report_error mm/kasan/report.c:352 [inline]
       kasan_report.cold.7+0x6d/0x2fe mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
       atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
       refcount_sub_and_test+0x92/0x330 lib/refcount.c:179
       refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212
       fib6_info_destroy+0x2d0/0x3c0 net/ipv6/ip6_fib.c:206
       fib6_info_release include/net/ip6_fib.h:304 [inline]
       ip6_route_info_create+0x677/0x3240 net/ipv6/route.c:3020
       ip6_route_add+0x23/0xb0 net/ipv6/route.c:3030
       inet6_rtm_newroute+0x142/0x160 net/ipv6/route.c:4406
       rtnetlink_rcv_msg+0x466/0xc10 net/core/rtnetlink.c:4648
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4666
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
       sock_sendmsg_nosec net/socket.c:629 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:639
       ___sys_sendmsg+0x805/0x940 net/socket.c:2117
       __sys_sendmsg+0x115/0x270 net/socket.c:2155
       SYSC_sendmsg net/socket.c:2164 [inline]
       SyS_sendmsg+0x29/0x30 net/socket.c:2162
       do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Fixes: d4ead6b3 ("net/ipv6: move metrics from dst to rt6_info")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      263243d6
    • D
      net/ipv6: Remove fib6_idev · dcd1f572
      David Ahern 提交于
      fib6_idev can be obtained from __in6_dev_get on the nexthop device
      rather than caching it in the fib6_info. Remove it.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dcd1f572
    • D
      net/ipv6: Remove unnecessary checks on fib6_idev · eea68cd3
      David Ahern 提交于
      Prior to 4832c30d ("net: ipv6: put host and anycast routes on device
      with address") host routes and anycast routes were installed with the
      device set to loopback (or VRF device once that feature was added). In the
      older code dst.dev was set to loopback (needed for packet tx) and rt6i_idev
      was used to denote the actual interface.
      
      Commit 4832c30d changed the code to have dst.dev pointing to the real
      device with the switch to lo or vrf device done on dst clones. As a
      consequence of this change a couple of device checks during route lookups
      are no longer needed. Remove them.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eea68cd3
    • D
      net/ipv6: Rename addrconf_dst_alloc · 360a9887
      David Ahern 提交于
      addrconf_dst_alloc now returns a fib6_info. Update the name
      and its users to reflect the change.
      
      Rename only; no functional change intended.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      360a9887
    • D
      net/ipv6: Rename fib6_info struct elements · 93c2fb25
      David Ahern 提交于
      Change the prefix for fib6_info struct elements from rt6i_ to fib6_.
      rt6i_pcpu and rt6i_exception_bucket are left as is given that they
      point to rt6_info entries.
      
      Rename only; not functional change intended.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93c2fb25
  3. 18 4月, 2018 18 次提交
  4. 04 4月, 2018 1 次提交
  5. 31 3月, 2018 2 次提交
    • D
      net/ipv6: Fix route leaking between VRFs · b6cdbc85
      David Ahern 提交于
      Donald reported that IPv6 route leaking between VRFs is not working.
      The root cause is the strict argument in the call to rt6_lookup when
      validating the nexthop spec.
      
      ip6_route_check_nh validates the gateway and device (if given) of a
      route spec. It in turn could call rt6_lookup (e.g., lookup in a given
      table did not succeed so it falls back to a full lookup) and if so
      sets the strict argument to 1. That means if the egress device is given,
      the route lookup needs to return a result with the same device. This
      strict requirement does not work with VRFs (IPv4 or IPv6) because the
      oif in the flow struct is overridden with the index of the VRF device
      to trigger a match on the l3mdev rule and force the lookup to its table.
      
      The right long term solution is to add an l3mdev index to the flow
      struct such that the oif is not overridden. That solution will not
      backport well, so this patch aims for a simpler solution to relax the
      strict argument if the route spec device is an l3mdev slave. As done
      in other places, use the FLOWI_FLAG_SKIP_NH_OIF to know that the
      RT6_LOOKUP_F_IFACE flag needs to be removed.
      
      Fixes: ca254490 ("net: Add VRF support to IPv6 stack")
      Reported-by: NDonald Sharp <sharpd@cumulusnetworks.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6cdbc85
    • L
      ipv6: do not set routes if disable_ipv6 has been enabled · 428604fb
      Lorenzo Bianconi 提交于
      Do not allow setting ipv6 routes from userspace if disable_ipv6 has been
      enabled. The issue can be triggered using the following reproducer:
      
      - sysctl net.ipv6.conf.all.disable_ipv6=1
      - ip -6 route add a:b:c:d::/64 dev em1
      - ip -6 route show
        a:b:c:d::/64 dev em1 metric 1024 pref medium
      
      Fix it checking disable_ipv6 value in ip6_route_info_create routine
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      428604fb
  6. 28 3月, 2018 1 次提交
  7. 27 3月, 2018 1 次提交
  8. 24 3月, 2018 1 次提交
    • E
      ipv6: fix possible deadlock in rt6_age_examine_exception() · 1bfa26ff
      Eric Dumazet 提交于
      syzbot reported a LOCKDEP splat [1] in rt6_age_examine_exception()
      
      rt6_age_examine_exception() is called while rt6_exception_lock is held.
      This lock is the lower one in the lock hierarchy, thus we can not
      call dst_neigh_lookup() function, as it can fallback to neigh_create()
      
      We should instead do a pure RCU lookup. As a bonus we avoid
      a pair of atomic operations on neigh refcount.
      
      [1]
      
      WARNING: possible circular locking dependency detected
      4.16.0-rc4+ #277 Not tainted
      
      syz-executor7/4015 is trying to acquire lock:
       (&ndev->lock){++--}, at: [<00000000416dce19>] __ipv6_dev_mc_dec+0x45/0x350 net/ipv6/mcast.c:928
      
      but task is already holding lock:
       (&tbl->lock){++-.}, at: [<00000000b5cb1d65>] neigh_ifdown+0x3d/0x250 net/core/neighbour.c:292
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #3 (&tbl->lock){++-.}:
             __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline]
             _raw_write_lock_bh+0x31/0x40 kernel/locking/spinlock.c:312
             __neigh_create+0x87e/0x1d90 net/core/neighbour.c:528
             neigh_create include/net/neighbour.h:315 [inline]
             ip6_neigh_lookup+0x9a7/0xba0 net/ipv6/route.c:228
             dst_neigh_lookup include/net/dst.h:405 [inline]
             rt6_age_examine_exception net/ipv6/route.c:1609 [inline]
             rt6_age_exceptions+0x381/0x660 net/ipv6/route.c:1645
             fib6_age+0xfb/0x140 net/ipv6/ip6_fib.c:2033
             fib6_clean_node+0x389/0x580 net/ipv6/ip6_fib.c:1919
             fib6_walk_continue+0x46c/0x8a0 net/ipv6/ip6_fib.c:1845
             fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1893
             fib6_clean_tree+0x1e6/0x340 net/ipv6/ip6_fib.c:1970
             __fib6_clean_all+0x1f4/0x3a0 net/ipv6/ip6_fib.c:1986
             fib6_clean_all net/ipv6/ip6_fib.c:1997 [inline]
             fib6_run_gc+0x16b/0x3c0 net/ipv6/ip6_fib.c:2053
             ndisc_netdev_event+0x3c2/0x4a0 net/ipv6/ndisc.c:1781
             notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
             __raw_notifier_call_chain kernel/notifier.c:394 [inline]
             raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
             call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
             call_netdevice_notifiers net/core/dev.c:1725 [inline]
             __dev_notify_flags+0x262/0x430 net/core/dev.c:6960
             dev_change_flags+0xf5/0x140 net/core/dev.c:6994
             devinet_ioctl+0x126a/0x1ac0 net/ipv4/devinet.c:1080
             inet_ioctl+0x184/0x310 net/ipv4/af_inet.c:919
             sock_do_ioctl+0xef/0x390 net/socket.c:957
             sock_ioctl+0x36b/0x610 net/socket.c:1081
             vfs_ioctl fs/ioctl.c:46 [inline]
             do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
             SYSC_ioctl fs/ioctl.c:701 [inline]
             SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
             do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
             entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      -> #2 (rt6_exception_lock){+.-.}:
             __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
             _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
             spin_lock_bh include/linux/spinlock.h:315 [inline]
             rt6_flush_exceptions+0x21/0x210 net/ipv6/route.c:1367
             fib6_del_route net/ipv6/ip6_fib.c:1677 [inline]
             fib6_del+0x624/0x12c0 net/ipv6/ip6_fib.c:1761
             __ip6_del_rt+0xc7/0x120 net/ipv6/route.c:2980
             ip6_del_rt+0x132/0x1a0 net/ipv6/route.c:2993
             __ipv6_dev_ac_dec+0x3b1/0x600 net/ipv6/anycast.c:332
             ipv6_dev_ac_dec net/ipv6/anycast.c:345 [inline]
             ipv6_sock_ac_close+0x2b4/0x3e0 net/ipv6/anycast.c:200
             inet6_release+0x48/0x70 net/ipv6/af_inet6.c:433
             sock_release+0x8d/0x1e0 net/socket.c:594
             sock_close+0x16/0x20 net/socket.c:1149
             __fput+0x327/0x7e0 fs/file_table.c:209
             ____fput+0x15/0x20 fs/file_table.c:243
             task_work_run+0x199/0x270 kernel/task_work.c:113
             exit_task_work include/linux/task_work.h:22 [inline]
             do_exit+0x9bb/0x1ad0 kernel/exit.c:865
             do_group_exit+0x149/0x400 kernel/exit.c:968
             get_signal+0x73a/0x16d0 kernel/signal.c:2469
             do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809
             exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162
             prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
             syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
             do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
             entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      -> #1 (&(&tb->tb6_lock)->rlock){+.-.}:
             __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
             _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
             spin_lock_bh include/linux/spinlock.h:315 [inline]
             __ip6_ins_rt+0x56/0x90 net/ipv6/route.c:1007
             ip6_route_add+0x141/0x190 net/ipv6/route.c:2955
             addrconf_prefix_route+0x44f/0x620 net/ipv6/addrconf.c:2359
             fixup_permanent_addr net/ipv6/addrconf.c:3368 [inline]
             addrconf_permanent_addr net/ipv6/addrconf.c:3391 [inline]
             addrconf_notify+0x1ad2/0x2310 net/ipv6/addrconf.c:3460
             notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
             __raw_notifier_call_chain kernel/notifier.c:394 [inline]
             raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
             call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
             call_netdevice_notifiers net/core/dev.c:1725 [inline]
             __dev_notify_flags+0x15d/0x430 net/core/dev.c:6958
             dev_change_flags+0xf5/0x140 net/core/dev.c:6994
             do_setlink+0xa22/0x3bb0 net/core/rtnetlink.c:2357
             rtnl_newlink+0xf37/0x1a50 net/core/rtnetlink.c:2965
             rtnetlink_rcv_msg+0x57f/0xb10 net/core/rtnetlink.c:4641
             netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2444
             rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4659
             netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
             netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
             netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
             sock_sendmsg_nosec net/socket.c:629 [inline]
             sock_sendmsg+0xca/0x110 net/socket.c:639
             ___sys_sendmsg+0x767/0x8b0 net/socket.c:2047
             __sys_sendmsg+0xe5/0x210 net/socket.c:2081
             SYSC_sendmsg net/socket.c:2092 [inline]
             SyS_sendmsg+0x2d/0x50 net/socket.c:2088
             do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
             entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      -> #0 (&ndev->lock){++--}:
             lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
             __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline]
             _raw_write_lock_bh+0x31/0x40 kernel/locking/spinlock.c:312
             __ipv6_dev_mc_dec+0x45/0x350 net/ipv6/mcast.c:928
             ipv6_dev_mc_dec+0x110/0x1f0 net/ipv6/mcast.c:961
             pndisc_destructor+0x21a/0x340 net/ipv6/ndisc.c:392
             pneigh_ifdown net/core/neighbour.c:695 [inline]
             neigh_ifdown+0x149/0x250 net/core/neighbour.c:294
             rt6_disable_ip+0x537/0x700 net/ipv6/route.c:3874
             addrconf_ifdown+0x14b/0x14f0 net/ipv6/addrconf.c:3633
             addrconf_notify+0x5f8/0x2310 net/ipv6/addrconf.c:3557
             notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
             __raw_notifier_call_chain kernel/notifier.c:394 [inline]
             raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
             call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
             call_netdevice_notifiers net/core/dev.c:1725 [inline]
             __dev_notify_flags+0x262/0x430 net/core/dev.c:6960
             dev_change_flags+0xf5/0x140 net/core/dev.c:6994
             devinet_ioctl+0x126a/0x1ac0 net/ipv4/devinet.c:1080
             inet_ioctl+0x184/0x310 net/ipv4/af_inet.c:919
             packet_ioctl+0x1ff/0x310 net/packet/af_packet.c:4066
             sock_do_ioctl+0xef/0x390 net/socket.c:957
             sock_ioctl+0x36b/0x610 net/socket.c:1081
             vfs_ioctl fs/ioctl.c:46 [inline]
             do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
             SYSC_ioctl fs/ioctl.c:701 [inline]
             SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
             do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
             entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      other info that might help us debug this:
      
      Chain exists of:
        &ndev->lock --> rt6_exception_lock --> &tbl->lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&tbl->lock);
                                     lock(rt6_exception_lock);
                                     lock(&tbl->lock);
        lock(&ndev->lock);
      
       *** DEADLOCK ***
      
      2 locks held by syz-executor7/4015:
       #0:  (rtnl_mutex){+.+.}, at: [<00000000a2f16daa>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
       #1:  (&tbl->lock){++-.}, at: [<00000000b5cb1d65>] neigh_ifdown+0x3d/0x250 net/core/neighbour.c:292
      
      stack backtrace:
      CPU: 0 PID: 4015 Comm: syz-executor7 Not tainted 4.16.0-rc4+ #277
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x24d lib/dump_stack.c:53
       print_circular_bug.isra.38+0x2cd/0x2dc kernel/locking/lockdep.c:1223
       check_prev_add kernel/locking/lockdep.c:1863 [inline]
       check_prevs_add kernel/locking/lockdep.c:1976 [inline]
       validate_chain kernel/locking/lockdep.c:2417 [inline]
       __lock_acquire+0x30a8/0x3e00 kernel/locking/lockdep.c:3431
       lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
       __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline]
       _raw_write_lock_bh+0x31/0x40 kernel/locking/spinlock.c:312
       __ipv6_dev_mc_dec+0x45/0x350 net/ipv6/mcast.c:928
       ipv6_dev_mc_dec+0x110/0x1f0 net/ipv6/mcast.c:961
       pndisc_destructor+0x21a/0x340 net/ipv6/ndisc.c:392
       pneigh_ifdown net/core/neighbour.c:695 [inline]
       neigh_ifdown+0x149/0x250 net/core/neighbour.c:294
       rt6_disable_ip+0x537/0x700 net/ipv6/route.c:3874
       addrconf_ifdown+0x14b/0x14f0 net/ipv6/addrconf.c:3633
       addrconf_notify+0x5f8/0x2310 net/ipv6/addrconf.c:3557
       notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
       call_netdevice_notifiers net/core/dev.c:1725 [inline]
       __dev_notify_flags+0x262/0x430 net/core/dev.c:6960
       dev_change_flags+0xf5/0x140 net/core/dev.c:6994
       devinet_ioctl+0x126a/0x1ac0 net/ipv4/devinet.c:1080
       inet_ioctl+0x184/0x310 net/ipv4/af_inet.c:919
       packet_ioctl+0x1ff/0x310 net/packet/af_packet.c:4066
       sock_do_ioctl+0xef/0x390 net/socket.c:957
       sock_ioctl+0x36b/0x610 net/socket.c:1081
       vfs_ioctl fs/ioctl.c:46 [inline]
       do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
       SYSC_ioctl fs/ioctl.c:701 [inline]
       SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Fixes: c757faa8 ("ipv6: prepare fib6_age() for exception table")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Wei Wang <weiwan@google.com>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Acked-by: NWei Wang <weiwan@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bfa26ff
  9. 23 3月, 2018 1 次提交
    • D
      net/ipv6: Handle onlink flag with multipath routes · 68e2ffde
      David Ahern 提交于
      For multipath routes the ONLINK flag can be specified per nexthop in
      rtnh_flags or globally in rtm_flags. Update ip6_route_multipath_add
      to consider the ONLINK setting coming from rtnh_flags. Each loop over
      nexthops the config for the sibling route is initialized to the global
      config and then per nexthop settings overlayed. The flag is 'or'ed into
      fib6_config to handle the ONLINK flag coming from either rtm_flags or
      rtnh_flags.
      
      Fixes: fc1e64e1 ("net/ipv6: Add support for onlink flag")
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68e2ffde
  10. 16 3月, 2018 2 次提交
    • D
      net/ipv6: Change address check to always take a device argument · 232378e8
      David Ahern 提交于
      ipv6_chk_addr_and_flags determines if an address is a local address and
      optionally if it is an address on a specific device. For example, it is
      called by ip6_route_info_create to determine if a given gateway address
      is a local address. The address check currently does not consider L3
      domains and as a result does not allow a route to be added in one VRF
      if the nexthop points to an address in a second VRF. e.g.,
      
          $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23
          Error: Invalid gateway address.
      
      where 2001:db8:102::23 is an address on an interface in vrf r1.
      
      ipv6_chk_addr_and_flags needs to allow callers to always pass in a device
      with a separate argument to not limit the address to the specific device.
      The device is used used to determine the L3 domain of interest.
      
      To that end add an argument to skip the device check and update callers
      to always pass a device where possible and use the new argument to mean
      any address in the domain.
      
      Update a handful of users of ipv6_chk_addr with a NULL dev argument. This
      patch handles the change to these callers without adding the domain check.
      
      ip6_validate_gw needs to handle 2 cases - one where the device is given
      as part of the nexthop spec and the other where the device is resolved.
      There is at least 1 VRF case where deferring the check to only after
      the route lookup has resolved the device fails with an unintuitive error
      "RTNETLINK answers: No route to host" as opposed to the preferred
      "Error: Gateway can not be a local address." The 'no route to host'
      error is because of the fallback to a full lookup. The check is done
      twice to avoid this error.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      232378e8
    • D
      net/ipv6: Refactor gateway validation on route add · 9fbb704c
      David Ahern 提交于
      Move gateway validation code from ip6_route_info_create into
      ip6_validate_gw. Code move plus adjustments to handle the potential
      reset of dev and idev and to make checkpatch happy.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fbb704c
  11. 12 3月, 2018 1 次提交
  12. 08 3月, 2018 1 次提交
    • S
      ipv6: Reflect MTU changes on PMTU of exceptions for MTU-less routes · e9fa1495
      Stefano Brivio 提交于
      Currently, administrative MTU changes on a given netdevice are
      not reflected on route exceptions for MTU-less routes, with a
      set PMTU value, for that device:
      
       # ip -6 route get 2001:db8::b
       2001:db8::b from :: dev vti_a proto kernel src 2001:db8::a metric 256 pref medium
       # ping6 -c 1 -q -s10000 2001:db8::b > /dev/null
       # ip netns exec a ip -6 route get 2001:db8::b
       2001:db8::b from :: dev vti_a src 2001:db8::a metric 0
           cache expires 571sec mtu 4926 pref medium
       # ip link set dev vti_a mtu 3000
       # ip -6 route get 2001:db8::b
       2001:db8::b from :: dev vti_a src 2001:db8::a metric 0
           cache expires 571sec mtu 4926 pref medium
       # ip link set dev vti_a mtu 9000
       # ip -6 route get 2001:db8::b
       2001:db8::b from :: dev vti_a src 2001:db8::a metric 0
           cache expires 571sec mtu 4926 pref medium
      
      The first issue is that since commit fb56be83 ("net-ipv6: on
      device mtu change do not add mtu to mtu-less routes") we don't
      call rt6_exceptions_update_pmtu() from rt6_mtu_change_route(),
      which handles administrative MTU changes, if the regular route
      is MTU-less.
      
      However, PMTU exceptions should be always updated, as long as
      RTAX_MTU is not locked. Keep the check for MTU-less main route,
      as introduced by that commit, but, for exceptions,
      call rt6_exceptions_update_pmtu() regardless of that check.
      
      Once that is fixed, one problem remains: MTU changes are not
      reflected if the new MTU is higher than the previous one,
      because rt6_exceptions_update_pmtu() doesn't allow that. We
      should instead allow PMTU increase if the old PMTU matches the
      local MTU, as that implies that the old MTU was the lowest in the
      path, and PMTU discovery might lead to different results.
      
      The existing check in rt6_mtu_change_route() correctly took that
      case into account (for regular routes only), so factor it out
      and re-use it also in rt6_exceptions_update_pmtu().
      
      While at it, fix comments style and grammar, and try to be a bit
      more descriptive.
      Reported-by: NXiumei Mu <xmu@redhat.com>
      Fixes: fb56be83 ("net-ipv6: on device mtu change do not add mtu to mtu-less routes")
      Fixes: f5bbe7ee ("ipv6: prepare rt6_mtu_change() for exception table")
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9fa1495
  13. 05 3月, 2018 2 次提交