kernel/linux.git/include/net/nexthop.h, branch v5.10.257

nexthop: Emit a notification when a nexthop is added

2025-10-02T11:35:46+00:00

[ Upstream commit 732d167bf5f53a8c1e8c53cf7dbffe2a13f63752 ] Emit a notification in the nexthop notification chain when a new nexthop is added (not replaced). The nexthop can either be a new group or a single nexthop. The notification is sent after the nexthop is inserted into the red-black tree, as listeners might need to callback into the nexthop code with the nexthop ID in order to mark the nexthop as offloaded. A 'REPLACE' notification is emitted instead of 'ADD' as the distinction between the two is not important for in-kernel listeners. In case the listener is not familiar with the encoded nexthop ID, it can simply treat it as a new one. This is also consistent with the route offload API. Changes since RFC: * Reword commit message Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski Stable-dep-of: 390b3a300d78 ("nexthop: Forbid FDB status change while nexthop is in a group") Signed-off-by: Sasha Levin

net: ipv4: Fix rtnexthop len when RTA_FLOW is present

2021-10-06T13:55:53+00:00

[ Upstream commit 597aa16c782496bf74c5dc3b45ff472ade6cee64 ] Multipath RTA_FLOW is embedded in nexthop. Dump it in fib_add_nexthop() to get the length of rtnexthop correct. Fixes: b0f60193632e ("ipv4: Refactor nexthop attributes in fib_dump_info") Signed-off-by: Xiao Liang Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

ipv6: fix suspecious RCU usage warning

2021-03-30T12:31:57+00:00

[ Upstream commit 28259bac7f1dde06d8ba324e222bbec9d4e92f2b ] Syzbot reported the suspecious RCU usage in nexthop_fib6_nh() when called from ipv6_route_seq_show(). The reason is ipv6_route_seq_start() calls rcu_read_lock_bh(), while nexthop_fib6_nh() calls rcu_dereference_rtnl(). The fix proposed is to add a variant of nexthop_fib6_nh() to use rcu_dereference_bh_rtnl() for ipv6_route_seq_show(). The reported trace is as follows: ./include/net/nexthop.h:416 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.0/17895: at: seq_read+0x71/0x12a0 fs/seq_file.c:169 at: seq_file_net include/linux/seq_file_net.h:19 [inline] at: ipv6_route_seq_start+0xaf/0x300 net/ipv6/ip6_fib.c:2616 stack backtrace: CPU: 1 PID: 17895 Comm: syz-executor.0 Not tainted 4.15.0-syzkaller #0 Call Trace: [] __dump_stack lib/dump_stack.c:17 [inline] [] dump_stack+0xd8/0x147 lib/dump_stack.c:53 [] lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5745 [] nexthop_fib6_nh include/net/nexthop.h:416 [inline] [] ipv6_route_native_seq_show net/ipv6/ip6_fib.c:2488 [inline] [] ipv6_route_seq_show+0x436/0x7a0 net/ipv6/ip6_fib.c:2673 [] seq_read+0xccf/0x12a0 fs/seq_file.c:276 [] proc_reg_read+0x10c/0x1d0 fs/proc/inode.c:231 [] do_loop_readv_writev fs/read_write.c:714 [inline] [] do_loop_readv_writev fs/read_write.c:701 [inline] [] do_iter_read+0x49e/0x660 fs/read_write.c:935 [] vfs_readv+0xfb/0x170 fs/read_write.c:997 [] kernel_readv fs/splice.c:361 [inline] [] default_file_splice_read+0x487/0x9c0 fs/splice.c:416 [] do_splice_to+0x129/0x190 fs/splice.c:879 [] splice_direct_to_actor+0x256/0x890 fs/splice.c:951 [] do_splice_direct+0x1dd/0x2b0 fs/splice.c:1060 [] do_sendfile+0x597/0xce0 fs/read_write.c:1459 [] SYSC_sendfile64 fs/read_write.c:1520 [inline] [] SyS_sendfile64+0x155/0x170 fs/read_write.c:1506 [] do_syscall_64+0x1ff/0x310 arch/x86/entry/common.c:305 [] entry_SYSCALL_64_after_hwframe+0x42/0xb7 Fixes: f88d8ea67fbdb ("ipv6: Plumb support for nexthop object in a fib6_info") Reported-by: syzbot Signed-off-by: Wei Wang Cc: David Ahern Cc: Ido Schimmel Cc: Petr Machata Cc: Eric Dumazet Reviewed-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

nexthop: Remove NEXTHOP_EVENT_ADD

2020-09-15T23:31:11+00:00

Not used anywhere. Signed-off-by: Ido Schimmel Suggested-by: David Ahern Signed-off-by: David S. Miller

nexthop: Remove unused function declaration from header file

2020-09-15T23:31:03+00:00

Not used or implemented anywhere. Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller

vxlan: Remove access to nexthop group struct

2020-06-10T20:20:20+00:00

vxlan driver should be using helpers to access nexthop struct internals. Remove open check if whether nexthop is multipath in favor of the existing nexthop_is_multipath helper. Add a new helper, nexthop_has_v4, to cover the need to check has_v4 in a group. Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Cc: Roopa Prabhu Signed-off-by: David Ahern Signed-off-by: David S. Miller

nexthop: Fix fdb labeling for groups

2020-06-10T20:18:40+00:00

fdb nexthops are marked with a flag. For standalone nexthops, a flag was added to the nh_info struct. For groups that flag was added to struct nexthop when it should have been added to the group information. Fix by removing the flag from the nexthop struct and adding a flag to nh_group that mirrors nh_info and is really only a caching of the individual types. Add a helper, nexthop_is_fdb, for use by the vxlan code and fixup the internal code to use the flag from either nh_info or nh_group. v2 - propagate fdb_nh in remove_nh_grp_entry Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops") Cc: Roopa Prabhu Signed-off-by: David Ahern Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-06-01T00:48:46+00:00

xdp_umem.c had overlapping changes between the 64-bit math fix for the calculation of npgs and the removal of the zerocopy memory type which got rid of the chunk_size_nohdr member. The mlx5 Kconfig conflict is a case where we just take the net-next copy of the Kconfig entry dependency as it takes on the ESWITCH dependency by one level of indirection which is what the 'net' conflicting change is trying to ensure. Signed-off-by: David S. Miller

ipv4: nexthop version of fib_info_nh_uses_dev

2020-05-26T23:06:07+00:00

Similar to the last path, need to fix fib_info_nh_uses_dev for external nexthops to avoid referencing multiple nh_grp structs. Move the device check in fib_info_nh_uses_dev to a helper and create a nexthop version that is called if the fib_info uses an external nexthop. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

ipv4: Refactor nhc evaluation in fib_table_lookup

2020-05-26T23:06:07+00:00

FIB lookups can return an entry that references an external nexthop. While walking the nexthop struct we do not want to make multiple calls into the nexthop code which can result in 2 different structs getting accessed - one returning the number of paths the rest of the loop seeing a different nh_grp struct. If the nexthop group shrunk, the result is an attempt to access a fib_nh_common that does not exist for the new nh_grp struct but did for the old one. To fix that move the device evaluation code to a helper that can be used for inline fib_nh path as well as external nexthops. Update the existing check for fi->nh in fib_table_lookup to call a new helper, nexthop_get_nhc_lookup, which walks the external nexthop with a single rcu dereference. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller