Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-17-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-16-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-15-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-14-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-13-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-12-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-11-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-10-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-9-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-8-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-7-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Acked-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-6-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-5-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-4-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-3-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-2-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Daniel Zahka says:
====================
psp: make tx key ops optional for drivers
This is the first of two series which together implement rekeying PSP
protected tcp connections. Here are both series together on github:
https://github.com/danieldzahka/linux/commits/psp-rekey-split/
This first series is mostly non-functional changes, except for the minor
difference that netdevsim driver implements tx key ops. Its tx key ops
were basically NOPs, and in the future PSP core can subsume the assoc
counting that it was doing.
The purpose of the refactors is to make code reusable from paths that
will be added to the code in the rekeying series.
Patch 1 exists to setup two paths for tx key deletion, one where keys
are deleted as they are now in psp_assoc_free() when the assoc refcount
drops to 0, and a different path in series two, where the keys will get
put onto a queue for deferred deletion.
Patch 2 exists to allow tx assoc state to be set either from the
connection setup path, or in series two, from a tx rekeying path.
Patch 3 makes implementing tx_key_add and tx_key_del optional for
drivers. These callbacks only make sense for devices that utilize a tx
SADB. This distinction is important once rekeying is involved, because
an SADB implies a race between in flight tx packets and key deletion,
that does not exist for non-SADB implementations.
Patch 4 removes the unnecessary tx key ops in netdevsim.
No new tests are added to this series. There is no real user visible
change of behavior.
====================
Link: https://patch.msgid.link/20260903-psp-prep-v1-0-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netdevsim has no SADB. The usage of psp_assoc_drv_data() was always
obsolete given psp_validate_xmit(), so we can remove nsim_assoc_add()
and nsim_assoc_del(). netdevsim::assoc_cnt can also be removed. PSP core
can track the balance of tx_key_add vs tx_key_del calls in a future
change.
Delete psp_assoc_drv_data() because there are no more callers left in
the tree. mlx5 accesses pas->drv_data directly.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-4-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drivers that don't use an SADB for tx key storage don't have a use
for psp_dev_ops::tx_key_add and psp_dev_ops::tx_key_del.
Allowing drivers to leave these as NULL gives PSP core a simple way to
determine whether a driver utilizes an SADB, which in turn could
affect how PSP core chooses to handle certain situations.
For example:
- deciding if tx key deletion needs to be delayed during a rekeying
event to avoid in-flight packets using old key handles.
- choosing whether or not to report device stats like SADB usage to
userspace, which only make sense if the driver uses on-device key
storage.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-3-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
No functional changes.
Lift code that needs to be called from both initial tx establishment
and tx rekeying into functions that can be reused in both paths.
The plaintext in recv queue checks and mss adjustment only run on
initial tx keying. The dummy psp_assoc machinery will be used in both
paths.
psp_dev_tx_key_add() absorbs the dummy assoc machinery, as its main
purpose is to populate the device specific psp_assoc:drv_data.
psp_assoc_set_tx() exists so that a future change can allow
psp_dev_tx_key_add() to be skipped entirely for devices that don't use
an SADB, while copying of the tx spi and key into the assoc needs to
happen regardless of SADB vs. no SADB.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-2-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
No functional changes.
Lift the list deletion and tx spi validation code into
callers. Deferred key deletion code paths will need similar checks
that a tx key needs removal from the underlying device, but will
diverge when it comes to list handling and when to call
psp_dev_ops::tx_key_del().
Also, move the predicate for tx key deletion into a helper for
readability and reuse in later patches.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260903-psp-prep-v1-1-d47e9c4c375d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dma_*() barriers are specifically for ordering writes to DMA
coherent memory that is accessible to both the CPU and DMA capable
devices.
The dma_wmb() barrier is lighter than wmb() on some architectures
because it only ensures ordering for DMA writes, not for all writes
including MMIO accesses.
In the MLX5 driver, completion queue (CQ) doorbell records are
allocated as DMA coherent memory via mlx5_dma_zalloc_coherent_node().
The CQ update pattern is:
1. Update CQ space (device reads via DMA)
2. Update doorbell record (device reads via DMA)
3. Memory barrier
4. Enable more CQEs
Since only DMA coherent memory accesses are involved (no MMIO accesses
follow), we can safely use dma_wmb() instead of wmb().
This change improves performance slightly on architectures where
dma_wmb() is lighter than wmb().
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260902023429.1717-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jinjie Ruan says:
====================
8021q: publish vlan_devices_arrays entries with acquire/release
This series fixes a speculative lockless data race in the 8021q
VLAN receive fast-path, and publish vlan_devices_arrays entries
with acquire/release for better performance.
====================
Link: https://patch.msgid.link/20260902073334.397685-1-ruanjinjie@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace the smp_wmb()/smp_rmb() barrier pair with
smp_store_release()/smp_load_acquire() on
vg->vlan_devices_arrays[pidx][vidx].
vlan_group_prealloc_vid() publishes the array pointer via release;
__vlan_group_get_device() acquires it before accessing the array,
ensuring the allocated entries are visible.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A plain C read and assignment of the net_device pointer
in the vlan_devices_arrays leaf entries lack proper atomicity
and ordering barriers. A concurrent lockless reader on the packet
receive fast-path could observe a torn or partially initialized
net_device pointer, leading to a potential out-of-bounds read or kernel
panic.
The data race occurs between the netlink/ioctl configuration paths
(holding the per-netns rtnl_nets_lock or RTNL lock) and the softirq
receive fast-path (holding rcu_read_lock()):
CPU 0 (Writer, rtnl_nets_lock/RTNL) CPU 1 (Reader, rcu_read_lock())
----------------------------------- -------------------------------
rtnetlink_rcv_msg()
// RTM_NEWLINK handler with RTNL_FLAG_DOIT_PERNET
rtnl_newlink()
ops->newlink() == vlan_newlink()
OR
vlan_ioctl_handler()
[ADD_VLAN_CMD] -> register_vlan_device()
register_vlan_dev()
vlan_group_set_device()
netif_receive_skb_core()
vlan_do_receive()
vlan_find_dev()
__vlan_group_get_device()
// Speculative / torn read
[Loads bad net_device *]
[Plain C store]
array[vlan_id] = dev;
// Dereferences bad pointer
// during device status check
vlan_dev->flags (PANIC!)
Fix this by using rcu_assign_pointer() in vlan_group_set_device()
and rcu_dereference_raw() in __vlan_group_get_device() to enforce
proper ordering and memory atomicity for the leaf entry traversal.
Link: https://sashiko.dev/#/patchset/20260825095422.3166067-1-ruanjinjie%40huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Chia-Yu Chang says:
====================
Explicit TSO segment count
This series replaces the existing min_tso_segs() congestion control
callback with a new tso_segs() callback that allows congestion control
algorithms to provide an explicit TSO segment count for each data burst.
To support BPF congestion controls, the series also exposes
tcp_tso_autosize() as a BPF kfunc, allowing BPF implementations to
reuse the kernel TSO autosizing logic while implementing custom
tso_segs() callbacks.
====================
Link: https://patch.msgid.link/20260831165230.2696893-1-chia-yu.chang@nokia-bell-labs.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Expose tcp_tso_autosize() as a BPF kfunc and register it in the TCP
congestion-control kfunc set. This allows BPF congestion controls to
reuse the kernel TSO autosizing logic while applying their own
minimum TSO segment policy.
To make the kfunc robust against BPF-provided inputs, min_tso_segs is
sanitized to at least 1 and mss_now == 0 returns the sanitized minimum
value instead of performing autosizing.
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch replaces the existing min_tso_segs() callback with a new
tso_segs() callback, allowing congestion control algorithms to provide
an explicit TSO segment count for each data burst and bypass
tcp_tso_autosize(). The resulting tso_segs value is clamped to
[1, sk->sk_gso_max_segs], preventing congestion-control implementations
from returning an invalid zero-segment value.
This change has the following impacts on BPF struct_ops users:
- The callback is renamed from min_tso_segs() to tso_segs()
- The signature gains an extra u32 mss_now argument
- The return value semantics is changed from "floor value passed into
tcp_tso_autosize()" to "final tso_segs value", bypassing autosizing
As a result, existing BPF programs must be updated, because returning a
small constant will now directly limit the final tso_segs value instead
of specifying the minimum value passed to tcp_tso_autosize().
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Signed-off-by: Ilpo Järvinen <ij@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netvsc_run_xdp() in drivers/net/hyperv/netvsc_bpf.c has handled
XDP_REDIRECT since commit 1cb9d3b618 ("hv_netvsc: Add support for
XDP_REDIRECT"), and netvsc_drv.c advertises NETDEV_XDP_ACT_REDIRECT
in xdp_features. Remove the stale note.
Link: https://patch.msgid.link/20260831200357.45390-1-chrismelnu@gmail.com
Signed-off-by: Christian Melendez <chrismelnu@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2026-09-01 (i40e)
Kohei Enju adds support for XDP metadata of Rx hash and VLAN tag.
Chris Packham reduces messaging when Rx filters are exhausted, and
promiscuous mode is enabled, to occur once when the mode is enabled
rather than repeated messaging for each filter.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
i40e: Avoid repeating RX filter warning
i40e: add support for bpf_xdp_metadata_rx_vlan_tag()
i40e: add support for bpf_xdp_metadata_rx_hash()
i40e: prepare for XDP metadata ops support
====================
Link: https://patch.msgid.link/20260901211752.1922993-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bind_wildcard picks an ephemeral port by binding fd[0] with port 0, reads
it back with getsockname(), and then reuses that exact port number for the
other addresses/families in fd[1..7]. This all happens in the default
network namespace, so unrelated processes on the same host are drawing from
the very same ephemeral port range (net.ipv4.ip_local_port_range) at the
same time.
Such a process can independently get assigned that exact port number on a
different, non-conflicting address in the short window between fd[0]'s
bind() and fd[1]'s, making fd[1]'s bind() fail with EADDRINUSE for reasons
that have nothing to do with the wildcard-bind behavior under test, e.g.:
# bind_wildcard.c:775:plain:Expected ret (-1) == 0 (0)
# plain: Test terminated by assertion
not ok N bind_wildcard.v6_local_v4_local.plain
Fix it the same way so_incoming_cpu.c, tcp_port_share.c and
reuseport_dualstack.c already do: unshare into a fresh network namespace
and bring lo up, so there is nobody else to race with for the port.
Signed-off-by: Ricardo B. Marlière (SUSE) <ricardo@marliere.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Show the number of packets dropped by DMAC filters in the CGX/RPM
debugfs mac_filter entry.
CGX uses RX_STAT4 for this counter, while RPM/RPM2 use RX_STAT2.
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Link: https://patch.msgid.link/20260901042503.1182121-1-nshettyj@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If the currently dumped device disappears while we were mid-dump
we will get the next device without resetting the sub-object ID.
This is quite unlikely, it was reported by an AI tool not a real
user. Let's fix it for better dump consistency.
We only intend to cover the case where device A disappears
and we skip over sub-objects of device B which was stable (B existed
before and after the dump). We don't intend to provide stable
results for any device that gets created or deleted during
the dump.
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260903221154.3359889-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The download loop streams the blob into the MCU as 32-bit words and
reads the last word past the end of a blob whose size is not a multiple
of four. The shipped blobs happen to be aligned, so the overread never
showed; a truncated or foreign file would carry up to three bytes of
whatever follows it into the MCU. Reject it before the first write
instead.
Cc: stable+noautosel@kernel.org # needs real net-admin (non-ns)
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20260903123650.23855-1-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Virtual network devices (ipvlan, macvlan, bonding) can enter legitimate
transmit recursion when combined with packet forwarding configurations
such as IPVS NAT. The existing XMIT_RECURSION_LIMIT (8) in
__dev_queue_xmit() detects and breaks these loops, but the allowed
depth is too high for KASAN-instrumented kernels: each recursion level
consumes significantly more stack due to KASAN inline instrumentation,
and the cumulative usage overflows the kernel stack before the limit
fires.
On x86_64, CONFIG_KASAN_GENERIC doubles THREAD_SIZE from 16KB to 32KB
(KASAN_STACK_ORDER=1), but KASAN per-access checks inflate individual
function frames by roughly 2-3x. For an ipvlan L3 + IPVS NAT routing
loop, objdump measurements on a non-KASAN kernel show ~1.4KB of stack
consumed per recursion level (across 17 functions from __dev_queue_xmit
through the full IP output path and back). At KASAN ~2.3x inflation
factor that becomes ~3.3KB per level. Eight levels -- the current
limit -- consume ~26KB plus the initial call chain (~8KB), which
exceeds the 32KB KASAN stack. The overflow hits the VMAP_STACK guard
page and causes a non-recoverable kernel panic (BUG: stack guard page
was hit).
On non-KASAN kernels the same loop is safely caught by the existing
limit: the "Dead loop on virtual device" message fires and the packet
is dropped without any stack overflow.
Reduce XMIT_RECURSION_LIMIT to 4 when CONFIG_KASAN is enabled.
The deepest legitimate transmit recursion observed in the kernel
selftests is 5 levels of __dev_queue_xmit nesting, in VXLAN symmetric
routing topologies with VRF (vxlan_symmetric, vxlan_asymmetric):
__dev_queue_xmit(vrf) depth 1
__dev_queue_xmit(vlan-svi) depth 2
__dev_queue_xmit(bridge) depth 3
__dev_queue_xmit(vxlan) depth 4
__dev_queue_xmit(veth) depth 5
Since the recursion check fires when the counter exceeds the limit
(strictly greater than), a limit of 4 permits 5 levels of nesting
while blocking the 6th. At ~3.3KB per level, five levels consume
~16.5KB; combined with the ~8KB initial call chain, total usage is
~24.5KB -- well within the 32KB KASAN stack with ~7.5KB of margin.
A limit of 3 (v2/v3 of this patch) allows only 4 levels, which broke
the VXLAN symmetric selftests: the 5th __dev_queue_xmit call was
incorrectly dropped, as reported by Jakub Kicinski and the kernel test
robot.
The recursion path triggering this is:
__dev_queue_xmit -> dev_hard_start_xmit -> ipvlan_start_xmit
-> ipvlan_queue_xmit -> ipvlan_process_outbound -> ip_local_out
-> nf_hook (IPVS) -> ip_vs_in_hook -> ip_vs_nat_xmit -> ip_output
-> ip_finish_output2 -> neigh_resolve_output -> __dev_queue_xmit
Tested:
- KASAN kernel (6.8.12 x86_64): panic before fix, "Dead loop"
drop after fix (at recursion level 4 instead of 8).
- Non-KASAN kernel (6.8.12 x86_64): "Dead loop" drop both before
and after fix (no behavior change for production kernels).
- Measured max __dev_queue_xmit nesting depth via bpftrace in a
VXLAN symmetric cross-VLAN topology (VRF + VLAN + bridge + VXLAN +
veth underlay): 5 levels, confirming limit=4 is sufficient.
Cc: stable+noautosel@kernel.org # KASAN is non-production
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
Link: https://patch.msgid.link/20260902123040.2172805-1-tristmd@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mana_bpf() has a trailing 'return ret;' after a switch statement whose
every case (XDP_SETUP_PROG and default) already returns unconditionally.
The statement is therefore unreachable and 'ret' is never used.
Remove both. No functional change intended.
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Reviewed-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Link: https://patch.msgid.link/3d8b67307df6fefdc18743274cef3de4fca0e7de.1788339612.git.falakreyaz@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- dat: fix printing of unknown 4addr subtype
- drop direction in _batadv_is_ap_isolated kernel-doc
- bat_v: fix bonding candidate selection
- clarify cut-off in batadv_v_neigh_is_sob kernel-doc
- use more descriptive var names for is_similar_or_better
- ensure u16 aligned mac addresses in structs and arrays (2 patches)
- translation table (tt) fixes/cleanups, 8 patches:
- remove only the entry which was looked up from the hash
- extract code handling a roam on add
- simplify NEW flag transition code
- drop unnecessary cleanup goto in helpers
- use protected flag modifications
- transition NEW local entries only under lock
- don't uncount never committed clients on pending purge
- decrement count for committed client on local_remove
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAmqVhkgWHHN3QHNpbW9u
d3VuZGVybGljaC5kZQAKCRChK+OYQpKeoTzCD/sElNaBC21gsWRftb38WkCzVUbK
666dxk0F80KDpUnf4NtoGTVz3c/qUYep1IXkb35e414YuoBfAMbqxRTKQ5PFsZTu
mIj1BU05P1X2gzruLM1OUncG3hHNBZn9j+1oxfrHTUQSTLfXxiEJFL/pOSXfmaL4
DPXqJRtavW7vvBKr+1PSCg97wSsnTzmXY6uECNC/MMqUFurAVtpvT/E3+DjfWAgO
VJluq6H3vtOv1qzqiXkHTH9TPSX36ktSbxE45Ubjaayw53y/Xq0amsfkVAvVJq02
mtNJ8AckiJD9AgyFO432uI4PH4SB60qSxFRLzinJHSjFLUYIaO2VQEYEVqiknLs9
9DlvEhaCNjDxxN7OP8Urcl8+/OJCE4Uh2HqhQu0AJ6v5cH8qS5hOGa0q0QP5/pQB
/rCASm2LWN1v803iNB1mwdAA06AjOdzyKpZhEomtIRd4aoPYbZmCczxP+fAS5By4
R77thSlm37kNhXJ3piKF0yozpy+0dApBZdf9ULqVjLVsc6kertUdwJL65WDP+tCt
wwdpW+uwgBWdK+RgUPNe/aCaDQVz1Hazvy1C6HpmtkBxMJtxPsjQNmgyja2PnlPa
KNRXkfPE5efv5mwEO7O5I0smQusx1N4zuSuHhtu3a6yvuOGlCwjk/BE4/Os9vSLv
AFJWgK4K+l4I1KkuBA==
=iAJC
-----END PGP SIGNATURE-----
Merge tag 'batadv-next-pullrequest-20260831' of https://git.open-mesh.org/batadv
Simon Wunderlich says:
====================
This cleanup patchset includes the following patches, all by Sven Eckelmann:
- dat: fix printing of unknown 4addr subtype
- drop direction in _batadv_is_ap_isolated kernel-doc
- bat_v: fix bonding candidate selection
- clarify cut-off in batadv_v_neigh_is_sob kernel-doc
- use more descriptive var names for is_similar_or_better
- ensure u16 aligned mac addresses in structs and arrays (2 patches)
- translation table (tt) fixes/cleanups, 8 patches:
- remove only the entry which was looked up from the hash
- extract code handling a roam on add
- simplify NEW flag transition code
- drop unnecessary cleanup goto in helpers
- use protected flag modifications
- transition NEW local entries only under lock
- don't uncount never committed clients on pending purge
- decrement count for committed client on local_remove
* tag 'batadv-next-pullrequest-20260831' of https://git.open-mesh.org/batadv:
batman-adv: tt: decrement count for committed client on local_remove
batman-adv: tt: don't uncount never committed clients on pending purge
batman-adv: tt: transition NEW local entries only under lock
batman-adv: tt: use protected flag modifications
batman-adv: tt: drop unnecessary cleanup goto in helpers
batman-adv: tt: simplify NEW flag transition code
batman-adv: tt: extract code handling a roam on add
batman-adv: tt: remove only the entry which was looked up from the hash
batman-adv: ensure u16 aligned mac address in structs
batman-adv: ensure u16 aligned mac address arrays on stack
batman-adv: use more descriptive var names for is_similar_or_better
batman-adv: clarify cut-off in batadv_v_neigh_is_sob kernel-doc
batman-adv: bat_v: fix bonding candidate selection
batman-adv: drop direction in _batadv_is_ap_isolated kernel-doc
batman-adv: dat: fix printing of unknown 4addr subtype
====================
Link: https://patch.msgid.link/20260831135117.574836-1-sw@simonwunderlich.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kuniyuki Iwashima says:
====================
neighbour: Namespacify arp_tbl and nd_tbl.
The neighbour subsystem is almost ready to drop RTNL.
However, the control paths are serialised by the global
per-table lock.
This series converts arp_tbl and nd_tbl to per-netns table.
With the series, /proc/sys/net/ipv{4,6}/neigh/default/ can
be configured per netns, which was only configurable in
init_net.
To avoid potential regression, all the settings are inherited
from init_net by default, and this behaviour is controlled by
a new sysctl knob, net.core.neigh_inherit_init_net:
# sysctl net.core.neigh_inherit_init_net
net.core.neigh_inherit_init_net = 1
# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh1=129
net.ipv4.neigh.default.gc_thresh1 = 129
# unshare -n sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 129
If it is turned off, all settings are reset in the new netns:
# sysctl net.core.neigh_inherit_init_net=0
net.core.neigh_inherit_init_net = 0
# unshare -n sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
Series overview:
Patch 1 deflakes test_neigh.sh.
Patch 2 ~ 3 are misc cleanup.
Patch 4 ~ 7 store arp_tbl/nd_tbl to net->neigh_tables[] and
remove the global neigh_tables[].
Patch 8 ~ 9 replace the direct access to arp_tbl/nd_tbl to
net->neigh_tables[] using new helpers.
Patch 10 ~ 12 finally replace the global table with per-netns
table.
Patch 13 ~ 14 clean up unnecessary net_eq().
Patch 15 updates test_neigh.sh.
Note that some buggy drivers access nd_tbl without checking
disable_ipv6_mod, so nd_tbl's extern definition is still left.
====================
Link: https://patch.msgid.link/20260902203722.926528-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
test_neigh.sh configures the following attributes in the root
netns, but now these can be set per netns.
* NDTA_THRESH1 / NDTA_THRESH2 / NDTA_THRESH3
* NDTPA_BASE_REACHABLE_TIME
Let's specify netns for "ip ntable".
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-16-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
neigh_table is now per-netns, and net_eq() is no longer needed.
Let's remove them.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-15-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
neigh_table is now per-netns, so struct pneigh_entry does not need
to store a net pointer.
Let's remove it and net comparison for pneigh_entry.
We no longer need to pass net to pneigh_create(), pneigh_delete(),
and pneigh_lookup().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-14-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now, neigh_table is ready to be namespacified.
Let's allocate per-netns neigh_table in neigh_table_register()
and call neigh_table_init() and neigh_sysctl_register() for it.
proc_create_seq_data() is changed to proc_create_net_data().
Since each netns has its own sysctl knobs, RTM_SETNEIGHTBL can
configure the default table param (ifindex==0) and GC parameters
per netns.
To avoid potential regression, all the default parameters under
/proc/sys/net/ipv{4,6}/neigh/default/, are inherited from init_net
by default.
This behaviour is controlled by a new sysctl knob,
net.core.neigh_inherit_init_net:
# sysctl net.core.neigh_inherit_init_net
net.core.neigh_inherit_init_net = 1
# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh1=129
net.ipv4.neigh.default.gc_thresh1 = 129
# unshare -n sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 129
If it is turned off, all settings are reset in the new netns:
# sysctl net.core.neigh_inherit_init_net=0
net.core.neigh_inherit_init_net = 0
# unshare -n sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
The next patch will remove other unnecessary net_eq().
Note that CONFIG_SYSCTL cannot be enabled without CONFIG_PROC_FS.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-13-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We will allocate neigh_table for each netns and free it
when netns is destroyed.
neigh_ifdown() cleans up all neighbour entries during netns
dismantle, but there is no synchronisation between timers because
neigh_del_timer() uses timer_delete() to stop a timer.
If neigh_table were freed while timer were running, neigh_destroy()
would touch the freed table.
If we called timer_delete_sync() in neigh_flush_one() under
tbl->lock, lockdep would complain although it is false-positive.
Let's convert neigh_table.entries to refcount_t and destruct
neigh_table only when the count reaches 0.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-12-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, neigh_table_init() and neigh_table_clear() are called
once at the boot time, but we will call them for each netns.
Let's clean up them.
For neigh_table_init(),
* Allocate all memory first and unwind on failure
* Remove !tbl->entry_size check since it is always true
for arp_tbl and nd_tbl
* Initialise everything before starting delayed works
For neigh_table_clear(),
* Reorder function to match neigh_table_init()
* Use timer_shutdown_sync() instead of timer_delete_sync()
* Remove pneigh_queue_purge() since it is called
via neigh_ifdown()
* Replace pr_crit() with DEBUG_NET_WARN_ON_ONCE()
* Call neigh_hash_free_rcu() directly without call_rcu()
In a later patch, neigh_table_clear() will be split so that
tbl->{stats,phash_buckets,nht} will be freed only when all
neighbour entries are freed.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-11-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We will allocate per-netns neigh_table in net->neigh_tables[].
Let's replace &nd_tbl with nd_table(net).
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-10-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We will allocate per-netns neigh_table in net->neigh_tables[].
Let's replace &arp_tbl with arp_table(net) and remove extern
definition for arp_tbl.
Three notes:
1. mlx5e_rep_netevent_event() and nfp_tun_neigh_event_handler()
have code assuming neigh_table other than &arp_tbl and
&nb_tbl, and the part is removed as it will be false once
per-netns table is allocated.
2. prestera and rocker uses init_net because they set
dev->netns_immutable to true.
3. mlx5e_tc_update_neigh_used_value() dereferences nhe->neigh_dev
in trace_mlx5e_tc_update_neigh_used_value().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-9-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now, &arp_tbl and &nd_tbl are stored in net->neigh_tables[].
Let's use net->neigh_tables[] in neighbour.c and remove the
global neigh_tables[].
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-8-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We will remove RTNL for neigh_add() and neigh_delete(), but they
are still serialised by per-protocol neigh_table.lock.
We can avoid contention by converting neigh_tables[] to per-netns,
but arp_tbl and nd_tbl are directly used in many places.
As a prep, let's store &arp_tbl and &nd_tbl in net->neigh_tables[].
We will replace such users with arp_table(net) and nd_table(net)
and then allocate per-netns neigh_table.
Note that nd_table() still returns &nd_tbl in case disable_ipv6_mod
is 1 because some buggy drivers use nd_tbl without checking it.
proc_create_net() is guarded with CONFIG_PROC_FS because it
returns NULL when =n and setup_net() fails and panic()s. Also
a later patch moves neigh_sysctl_register() under the guard.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-7-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 1bf20cc62a ("neighbour: remove obsolete EXPORT_SYMBOL()")
unexported some functions in neighbour.c because IPv6 is no longer
built as module.
Since it unexported neigh_table_init(), no module can register
neigh_table dynamically.
Let's unexport a few more functions.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902203722.926528-5-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
