Perform one time register initialization during mpnic_probe(). These CSR
settings are either static configs that only need to be set once, or
pulses for zeroizing on chip SRAMs, which also only need to be done
once.
This initialization is idempotent and does not require any matching
deinitialization in the remove path. We can unbind and re-bind the
driver and perform the same initialization without problems.
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-2-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
MPNIC is the next network interface controller designed by Meta. Create
a bare PCI driver for it. Subsequent changes will flesh it out.
Registers live in BAR0 and are addressed as an array of 32 bit words,
which is why the CSR indices are a quarter of the byte offset. Most of
the register file is only accessible as 64 bit, so that is the only
accessor added here.
If a read returns all ones, a second read to an unused register with
reset value 0 is performed to determine if the device is gone. If the
device is gone, the mapped BAR0 pointer is cleared, so no further
accesses reach the bus.
For now, if mpnic_mmio_err() clears mpd->uc_addr0, nothing will
reassign it. The user will have to unbind and rebind the driver. Future
series will reset uc_addr0 from pci error handlers.
In addition to being used as a 0 value reference CSR, MPNIC_BDQ_SPARE is
also used to perform write flushes, because it can be read without
producing side effects.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-1-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The FIB6_EXCEPTION_BUCKET_FLUSHED logic has been dead since added.
Commit 0346ec2f08 ("ipv6: Prevent rt6_insert_exception() for
dying fib6_info.") restored the original race protection in
rt6_insert_exception() by reusing fib6_info.fib6_destroying.
The flag now prevents two races for per-cpu and exception routes.
Let's remove FIB6_EXCEPTION_BUCKET_FLUSHED and set fib6_destroying
in fib6_purge_rt().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260926033355.3295550-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A provider index of 0xFFFFFFFF picks a provider on hardware that has
none. phc_index is an int where -1 means no PHC, and the u32 from user
space ends up as -1, so the two match.
TSINFO_GET uses -1 for "no provider requested" and answers with the
default provider instead of an error.
Reject the value in the netlink policy, which covers every comparison
site.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20260925135237.3432266-2-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEjF9xRqF1emXiQiqU1w0aZmrPKyEFAmq5lC0ACgkQ1w0aZmrP
KyH/+A//XlfAsuJFsBE0sGf4zSuPw96RvjG9hjlbCahoMHSwwON46bl3frT+W9Zr
YNEIJMdEqqGEQ+bGQcafLlX3ayknzhN7cTe+VoBOR12/6WeewSG/1l3JusWgb91b
snDGU/tWaXn0ZmumpziiDWlgNapRkLlxCr7ZzqBNJowNZU/RNd/dtqiMdBz8osX7
eOtL947O2EIjNZ0+Y5AI6uHwQimEIdzPYIi50WpyxcLYLC/AEEJFhDTafwq5NTP/
tCzYODr2ybWXeC90yxFsLNQai+1Tyo7tq0BP1dcMg80i/kgOnVtAQqRt0E6BYaEP
Rwbfhh+onCbdRV0DpsuyL6uy3pnJ21uj48hWuquHgGnuP6yrc2EMTreLmt0szorH
nngUoqBNKheTqC8L+VSfjV6/+tDhwLTaH4knlasbZizWC//GjlBfK7c7499ApHrS
Icm9pVwKYtFFRARe8wT2H3AKO3u3DaVNXBDypviCnEuvAXRuIi4nwu/aMVVeD9cs
04uTCFqMvUv+rX3oJN13hhC88fyH4R25sMt/XIZQxel/ZwjZrcZYz8FoFi5ePdfF
X/tBDloygOt2tB3YRnHdPxm/SYOZTQoUlD9SmtwvSYnGD0V3TFmCFILAeNPc4SrZ
rR/H5yDV47JxXGst9xd5AJlMNhr6ZrbCqbqC6GhWPnXFXC01lvg=
=RZ9z
-----END PGP SIGNATURE-----
Merge tag 'nf-next-26-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next
Pablo Neira Ayuso says:
====================
Netfilter updates for net-next
The following patchset contains Netfilter updates for net-next. The
fixes included in this batch are deemed to handle correctness issues
present in the Netfilter tree:
1) TCP sequence tracking is not reset inconditionally by synproxy when
recycling an entry, sashiko reports the zero offset case skips it.
Add a new function to inconditionally reset TCP sequence tracking.
From Fernando F. Mancera.
2) Update documentation to reflect that the default maximum number of
expectations (nf_conntrack_expect_max) is nf_conntrack_buckets / 64.
From Shaojie Sun.
3) Remove useless break; after return in nft_osf, from Linkui Xiao.
4) Fix typos in comments in the netfilter tree, from Hemanth Selam.
5) Remove a few conntrack error stats duplicated updates,
from Phil Sutter.
6) Do not bump invalid and drop conntrack error stats when packet is
dropped, this is another duplicate. also From Phil.
7) Set on netns pointer before registering the flowtable, this is
a requirement by the next patch, not fixing an existing issue.
From Qingfang Deng.
8) Remove unnecessary workqueue work flush for all of the existing
netns when device is gone. Also from Qingfang Deng.
9) Rework-fix nfnetlink_hook to correctly deal with large netlink
dumps. Use sequence numbers to detect interference with hook
updates while netlink dump is ongoing. From Phil Sutter.
10) Fix ctnetlink dump filtering by the IPv6 address, this has
only work correctly for IPv4 this far, from Piotr Kubik.
11) ctnetlink filtering by zone is supported, but the ctnetlink
dump filtering infrastructure was never updated to include a
flag from userspace, update it to fill this gap.
From Ilya Maximets.
* tag 'nf-next-26-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
netfilter: conntrack: make filtering by zone discoverable
netfilter: ctnetlink: fix inverted IPv6 address match in dump filter
netfilter: nfnetlink: Fix for interrupted hook dumps
netfilter: flowtable: check namespace before iterating flows
net/sched: act_ct: set net pointer before publishing flowtable
netfilter: conntrack: Untangle drop and invalid counters
netfilter: conntrack: Untangle insert_failed counter from others
netfilter: fix several typos in comments
netfilter: osf: remove unreachable break in nf_osf_ttl()
netfilter: conntrack: fix nf_conntrack_expect_max default value in documentation
netfilter: synproxy: fix reset of ct seqadj when reopening a connection
====================
Link: https://patch.msgid.link/20260927223436.269024-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Family._load_nested_set_nest() collects the type-value names of a
nest-type-value attribute into a set and Struct.set_inherited() renders
them sorted, while TypeNestTypeValue._attr_get() passes them to the
parse helper in the order the spec lists them. For nlctrl's
type-value: [policy-id, attr-id]
that makes the generated helper take (attr_id, policy_id) and the caller
pass (policy_id, attr_id). Both are __u32 so nothing complains, and
every C YNL user of the nlctrl policy dump gets the two swapped.
Two attributes nesting the same attribute set with the type values in
a different order now fail set_inherited() instead of comparing equal.
No spec does that today, but better safe than sorry.
Nesting an attribute set which is also used as a sub-message gets its own
check: it used to be caught by the list-versus-set type mismatch, which
the ordering fix removes, and without it the generator emits a call
to the sub-message parser with the selector argument missing.
Again, no spec does this today.
nlctrl is the only spec affected, discovered by an LLM scan of the spec.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260924223245.530132-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David Carlier says:
====================
vsock: receive queue hint for io_uring
AF_VSOCK stream receives never fill msghdr.msg_inq. io_uring initialises the
hint to -1 and treats that as "unknown", so it cannot set
IORING_CQE_F_SOCK_NONEMPTY, and it speculatively retries a multishot receive
after every completion, including when the queue is already empty.
Patch 1 fills the hint at the common exit of __vsock_connectible_recvmsg(),
reusing vsock_stream_has_data(), the transport callback that SIOCINQ already
uses. Following tcp_inq_hint(), it reports a terminal hint of 1 once the
connection is finished, so the caller still performs the receive that
observes EOF. Patch 2 adds selftest coverage.
Numbers come from a ping-pong over vsock loopback using io_uring multishot
receive, 4 KiB messages, the queue drained between messages, with kernel
receives counted by a kprobe. The baseline is the same tree with patch 1
reverted:
entries per delivered message 1.97 -> 1.00 (5000 messages)
receiver CPU time, median 1.640s -> 1.587s (-3.2%)
receiver wall time, median 3.260s -> 3.183s (-2.4%)
Timing is 25 runs of 50000 messages per kernel; CPU gives Mann-Whitney
p=0.006, wall time does not separate from noise (p=0.12), as expected for a
latency-bound workload.
The hint is gated to SOCK_STREAM; seqpacket is untouched. SO_INQ and SCM_INQ
are deliberately left out: they need their own per-socket state and
ancillary-message semantics, and a byte-count contract would have to account
for transports reporting less than the whole queue. That can follow.
Testing: built and run under virtme-ng on loopback, where the new cases pass
and vsock_test still passes 41 of 41 with a clean dmesg. Other transports
were reviewed but not tested. Hyper-V reports the current packet rather than
the whole queue and can return -EIO; an undercount only understates what is
readable, and a negative result reports -1, the same "unknown" value io_uring
presets.
====================
Link: https://patch.msgid.link/20260923184008.153541-1-devnexen@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add io_uring receive tests checking IORING_CQE_F_SOCK_NONEMPTY across a
partial receive, draining while the peer stays connected, EOF, a
nonblocking receive on an empty queue, a zero-length request, and a
multishot receive with provided buffers.
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260923184008.153541-3-devnexen@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
AF_VSOCK stream receives never fill msghdr.msg_inq, so io_uring cannot set
IORING_CQE_F_SOCK_NONEMPTY and retries a multishot receive even after the
queue has been drained.
Fill the hint at the common receive exit using the transport callback that
SIOCINQ already uses, and report 1 once the connection is finished so the
caller performs the receive which observes EOF, as TCP does after a FIN.
A vsock loopback ping-pong with io_uring multishot receive drops entries
into __vsock_connectible_recvmsg from 1.97 to 1.00 per delivered message,
and receiver CPU time by about 3% (25 runs of 50000 messages, p=0.006).
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260923184008.153541-2-devnexen@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tariq Toukan says:
====================
net/mlx5: Preparations for nested E-switch
This series by Shay has two intertwined goals. The first is to remove
the compile-time MLX5_MAX_PORTS sizing from the LAG and eswitch/TC
datapaths so that structures scale with the actual number of ports/peers
rather than a fixed maximum. The second is a set of small,
self-contained fixes that prepare the eswitch and LAG code for a VF/SF
acting as a nested e-switch manager - a mode new FW will allow, where a
VF/SF has its own eswitch and the VFs/SFs can be grouped by MPESW.
No functional change is intended for existing configurations.
====================
Link: https://patch.msgid.link/20260923103830.1183-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlx5_esw_host_functions_enabled() only treated host functions as
disabled for an ECPF manager.
To support a non PF acting as an e-switch manager, add a check for a non
PF e-switch manager that treats host functions as disabled. This will
avoid allocating a host-PF vport in mlx5_esw_vports_init().
With host functions disabled for non PF, its e-switch is the expected
manager + uplink only.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-14-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlx5_esw_hold() and mlx5_eswitch_unblock_ipsec() bail out on
!mlx5_esw_allowed(), and their comments explained that as "a VF has no
eswitch" / "core dev is not a PF". New FW will let a VF act as a nested
e-switch manager - such a VF has an eswitch and passes
mlx5_esw_allowed() - so that equivalence no longer holds. Reword the
comments to describe the actual condition, the device is not an e-switch
manager, with no functional change.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-13-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The shared-FDB support check still requires the esw_shared_ingress_acl
capability. That capability backed the merged uplink ingress ACL, where
the slave uplink's ingress-ACL root was pointed at the master's
(esw_set_uplink_slave_ingress_root()). That handling was removed in
commit 82e86a6c71 ("net/mlx5: E-switch, remove special uplink ingress
ACL handling") once both uplinks were tagged with the same reserved
metadata (MLX5_ESW_METADATA_RSVD_UPLINK) - a single FDB rule then
matches traffic from either uplink, with no shared ingress ACL involved.
The capability check was left behind and has been dead since: the driver
programs no shared ingress ACL, yet the check still keeps otherwise
shared-FDB-capable devices out of shared FDB. Drop it.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-12-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The mapping debugfs file dumps the LAG virtual-to-physical port mapping.
In MPESW mode the LAG does not own that mapping - port selection is
driven by user steering rules, not by the LAG - so the dumped values are
meaningless.
Treat MPESW as if LAG is inactive and don't print anything to the user.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-11-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlx5_eswitch_manager_vport() hardcoded the e-switch manager vport as
either the ECPF or the host PF. Read esw_manager_vport_number from the
e-switch capability when esw_manager_vport_number_valid is set, so the
manager vport can be a VF - a prerequisite for VFs acting as e-switch
managers. Keep the previous mapping as fallback when the capability does
not report a number.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-10-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The per-peer reverse index lived in a fixed esw->offloads.peer_flows[]
array of list heads indexed by the peer's LAG sequence number, capping a
shared FDB at MLX5_MAX_PORTS members.
Replace the array with an xarray keyed by the peer vhca_id. Each entry
is a heap-allocated list head that chains the flows duplicated to that
peer via their peer node. This lifts the MLX5_MAX_PORTS cap: the number
of peers is bounded only by the number of distinct vhca_ids.
The lifetime of the duplicated peer flows list_head follows the devcom
pairing of the two eswitches:
- pair (mlx5_esw_offloads_pair): kzalloc_obj + INIT_LIST_HEAD +
xa_store the dup_peer_flows under the peer's vhca_id.
- add (mlx5e_tc_add_fdb_peer_flow): xa_load the dup_peer_flows and
list_add the duplicated flow's peer node.
- del (mlx5e_tc_del_fdb_peer_flow): list_del that node.
- flush (mlx5e_tc_clean_fdb_peer_flows): xa_for_each dup_peer_flows,
drop every duplicated flow on it; called from unpair.
- unpair (mlx5_esw_offloads_unpair): xa_erase + kfree the
dup_peer_flows.
So a dup_peer_flows is created when the local eswitch pairs with a peer
over devcom and freed when they unpair.
No functional change.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-9-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A TC eswitch flow offloaded to a shared FDB is duplicated onto every
peer eswitch. Besides the forward list of duplicates on the origin flow
(mlx5e_tc_flow.peer_flows), the eswitch keeps a reverse index,
esw->offloads.peer_flows[], an array of per-peer list heads keyed by the
peer's LAG sequence number, used to tear down a peer's duplicates when
it is removed.
That reverse index was anchored on the origin: since one origin can have
a duplicate on every peer, the origin carried per-peer storage sized to
the max port count - a peer[MLX5_MAX_PORTS] array of list nodes plus a
peer_used bitmap - and each duplicate stored its peer_index.
Anchor it on the duplicate instead, which belongs to a single peer. Give
each flow one list node, mlx5e_tc_flow.peer, and place the duplicate -
not the origin - on its peer's list through it; add a peer_orig back-ref
so del can reach the origin from the duplicate. One node then replaces
the origin's per-peer array, and del unlinks the duplicate directly, so
peer[], peer_used and peer_index are dropped.
The per-peer list heads remain the fixed esw->offloads.peer_flows[]
array keyed by the LAG sequence number - that array is replaced in the
next patch. No functional change.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-8-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlx5_lag_drop_rule_setup() walks the per-port tracker state, but does so
through a per-port scratch array, mlx5_lag_drop_rule_setup() collects
the disabled ports to create a per-port drop rule.
Walk the tracker state inline removing its MLX5_MAX_PORTS dependency.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-6-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlx5_lag_print_mapping(), mlx5_infer_tx_affinity_mapping() and
lag_active_port_bits() each used a MLX5_MAX_PORTS-sized stack buffer to
hold per-port working state. Allocate these buffers with
kcalloc(ldev->ports, ...) instead so they track the actual port count
and no longer depend on MLX5_MAX_PORTS.
lag_active_port_bits() can now fail on allocation, so it returns int and
propagates -ENOMEM; a non-negative return is the active-port bitmask as
before. Its two callers, mlx5_cmd_create_lag() and _mlx5_modify_lag(),
check for a negative return and bail out, then narrow the value back
into the u8 they hand to the device.
This removes these buffers' dependency on MLX5_MAX_PORTS.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-5-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
v2p_map was a fixed array sized MLX5_MAX_PORTS *
MLX5_LAG_MAX_HASH_BUCKETS embedded in struct mlx5_lag. Turn it into a
pointer allocated in mlx5_lag_dev_alloc() once ldev->ports is known,
sized by the actual port count, and free it in mlx5_ldev_free(). The
ldev->ports / ldev->buckets initialization is moved up so the allocation
can use it.
The matching scratch buffer in mlx5_modify_lag() is converted from a
MLX5_MAX_PORTS-sized stack array to a kcalloc() of the same extent, with
the trailing teardown reworked through a goto so the buffer is freed on
every path. The memcpy() that previously relied on sizeof() of the stack
array now uses the explicit ldev->ports * MLX5_LAG_MAX_HASH_BUCKETS
span.
No functional change; this removes v2p_map's dependency on
MLX5_MAX_PORTS.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-4-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If the initial PAIR event fails, the eswitch offloads devcom component
stays registered until eswitch teardown even though no peer was ever
paired. devcom is optional, so this is not a functional bug - but a
registered component that reflects no actual pairing is incorrect state
to keep around.
Release it when the initial pairing fails.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlx5e_set_netdev_dev_addr() falls back to a random MAC only when the
queried address is all-zeros AND the device is not a vport group
manager. A vport group manager that comes up with a zero MAC is
therefore left with an invalid all-zero address.
The vport_group_manager exception is unnecessary: a zero MAC is always
invalid, regardless of device type. Drop the condition and assign a
random MAC whenever the queried address is zero, so every netdev comes
up with a valid address.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Akiva Goldberger <agoldberger@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260923103830.1183-2-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In bcm_sysport_stop(), the error messages printed when tdma_enable_set()
and rdma_enable_set() time out were inverted: the failure of
tdma_enable_set() logged 'timeout disabling RDMA' and the failure of
rdma_enable_set() logged 'timeout disabling TDMA'.
Swap the error messages so they correctly describe the failing engine.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260922232440.598918-9-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In bcm_sysport_suspend_to_wol(), the loop enabling programmed RXCHK
filters in RXCHK_CONTROL used an auxiliary counter 'i' instead of the
actual set filter index 'index'.
When non-contiguous filters were configured (for example, if filter 0
was deleted and filter 1 remained), the code would enable bit
(RXCHK_BRCM_TAG_MATCH_SHIFT + 0) corresponding to filter 0 rather than
filter 1, causing Wake-on-LAN filter matching to fail.
Fix this by using the filter 'index' to set the appropriate match bit
in RXCHK_CONTROL.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260922232440.598918-5-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If allocation of priv->rx_cbs fails during bcm_sysport_init_rx_ring(),
error unwinding in bcm_sysport_open() calls bcm_sysport_fini_rx_ring().
Without checking if priv->rx_cbs is non-NULL, bcm_sysport_fini_rx_ring()
dereferences priv->rx_cbs, resulting in a NULL pointer dereference.
Add a check for !priv->rx_cbs at the beginning of
bcm_sysport_fini_rx_ring(), matching bcm_sysport_fini_tx_ring().
Cc: stable+noautosel@kernel.org # unlikely driver error path
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260922232440.598918-4-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Florian Fainelli says:
====================
net: broadcom: Couple of minor changes
The first change makes sure there is proper reference counting handling
in case of error/removal for the bcmsysport driver.
The second change removes duplicates definitions in the ASP2 driver.
====================
Link: https://patch.msgid.link/20260922222525.3992167-1-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In bcm_sysport_probe(), priv->phy_dn is only initialized if the device
tree node has a fixed-link configuration (of_phy_is_fixed_link). When
connecting to a discrete MDIO-attached PHY referenced via 'phy-handle',
priv->phy_dn remains NULL. This causes of_phy_connect() during
bcm_sysport_open() to fail with -ENODEV since of_phy_find_device(NULL)
returns NULL.
Fix this by parsing 'phy-handle' via of_parse_phandle() and falling back
to of_phy_is_fixed_link(). Ensure proper of_node_get() and of_node_put()
refcounting lifecycle on both error unwinding and module remove paths.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260922222525.3992167-2-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
vxlan: convert configuration to RCU and enable lockless dumps
This patch series converts struct vxlan_config to RCU protection, eliminates
redundant destination fields, and enables lockless RTNL-free link dumping
in vxlan_fill_info().
====================
Link: https://patch.msgid.link/20260922181102.3989489-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that vxlan->cfg is RCU-protected, we can update vxlan_fill_info()
to run under RCU read lock instead of relying on RTNL.
This completes the transition to RTNL-less link info dumping for VXLAN.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-9-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that vxlan->cfg is an RCU-protected pointer, storing default
destination attributes (remote_ip, remote_vni, remote_ifindex) in
vxlan->default_dst is redundant and creates potential data races for
lockless readers.
Furthermore, several fields of struct vxlan_rdst (remote_port,
offloaded, list, rcu, dst_cache) in default_dst were completely unused.
The remaining one, remote_dev, only tracked the lower device, a role
now taken by vxlan->lowerdev, so drop it from struct vxlan_rdst.
Replace vxlan->default_dst with a 'struct net_device *lowerdev' pointer
in struct vxlan_dev to track adjacent upper/lower netdev topology under
RTNL, and switch all remaining users over to reading configuration
attributes from vxlan->cfg.
Also update mlx5e_tc_tun_get_remote_ifindex() to read remote_ifindex
from vxlan->cfg under rcu_read_lock().
In vxlan_changelink(), pass lowerdev to vxlan_config_apply() to preserve
needed_headroom and needed_tailroom. The mtu is still only reconsidered
when the lower device changes, so that an unrelated changelink can not
shrink it.
cfg->remote_ifindex is now committed unconditionally, where
default_dst.remote_ifindex was left untouched when IFLA_VXLAN_LINK was
cleared, so a changelink dropping the lower device no longer leaves a
stale ifindex behind. For the same reason vxlan_changelink() no longer
needs to compute the ifindex that will actually be committed.
Setting IFLA_VXLAN_LINK to 0 now also tears down the upper/lower
adjacency, which netdev_adjacent_change_commit() used to skip for a NULL
new device, resets needed_tailroom, and is rejected if per-VNI multicast
groups are configured.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-8-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move 'struct vxlan_config' from an embedded structure inside
'struct vxlan_dev' to a dynamically allocated RCU-protected pointer
'vxlan->cfg'.
Updating configuration via vxlan_changelink() or vxlan_dev_configure()
allocates a new struct vxlan_config and publishes it with
rcu_assign_pointer(), freeing the previous config with kfree_rcu().
Readers are converted to use rcu_dereference() or rtnl_dereference().
In vxlan_xmit(), acquire rcu_read_lock() to protect config access.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-7-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
VXLAN_F_MDB is an internal runtime state flag indicating whether any
MDB entries are configured on the device, rather than a netlink
configuration attribute.
In preparation for converting vxlan->cfg to an RCU-protected pointer,
move VXLAN_F_MDB from struct vxlan_config to a dedicated 'flags' field
in struct vxlan_dev as VXLAN_DEV_F_MDB, using atomic bitops (set_bit(),
clear_bit(), test_bit()) to avoid KCSAN data races between the TX path
and RTNL operations.
This avoids having to dynamically reallocate and publish a new
vxlan_config structure via RCU whenever the first MDB entry is added
or the last one is removed, and prevents potential memory allocation
failures during MDB teardown under memory pressure.
mlxsw validates cfg->flags against a deny-by-default mask, so
VXLAN_F_MDB used to make mlxsw_sp_nve_vxlan_can_offload() reject a
device with MDB entries as carrying an unsupported flag. Add an
explicit VXLAN_DEV_F_MDB test there to keep that rejection, with a
message naming the actual reason.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-6-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In preparation for converting vxlan->cfg to an RCU-protected pointer,
refactor internal helper functions in the RX, TX, MDB, and VNIFILTER
paths to accept a pointer to struct vxlan_config (or pass flags/
saddr_family where appropriate) rather than directly accessing
vxlan->cfg.
No functional changes.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-5-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
vxlan_vnifilter_dump() walks all vxlan devices of a netns, and for each
one walks vg->vni_list. Both cursors are plain ordinals stored in
cb->args[0] and cb->args[1], and RTNL is released between dump skbs.
A concurrent __vxlan_vni_add_list(), which inserts sorted by VNI,
__vxlan_vni_del_list(), or an in-place group update in
vxlan_vni_update() (which splits or merges coalesced VNI ranges) shifts
the second cursor, duplicating or skipping entries. Unregistering a
vxlan device shifts the first one, and the partially dumped device is
then skipped altogether by the "if (idx < s_idx)" test, silently losing
the rest of its VNIs.
Add a per-netns generation counter, bumped whenever the set of vxlan
devices in the netns or any vni_list changes, and feed it to
nl_dump_check_consistent() so that user space gets NLM_F_DUMP_INTR and
can retry, as vxlan_mdb_dump() already does.
The counter is keyed on dev_net(vxlan->dev) rather than vxlan->net,
because the dump enumerates devices with for_each_netdev_rcu() in the
netns the netdevice lives in, which differs from the packet i/o netns
when the device was created with a separate link netns.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RTM_GETTUNNEL dumps currently run under RTNL lock, but
vxlan_vnifilter_dump() also acquires rcu_read_lock().
1) Currently vxlan_vnifilter_dump_dev() traverses vg->vni_list using
list_for_each_entry_safe(). Even though RTNL is held today, writers
modify vg->vni_list with list_add_rcu() and list_del_rcu().
Switch to list_for_each_entry_rcu() for proper RCU traversal and
as preparation for future lockless dump support.
2) During a paginated dump, RTNL is released between dump skbs.
If vxlan_vnifilter_dump_dev() returns early because VXLAN_F_VNIFILTER
is not set or vg has no VNIs, cb->args[1] was not cleared. This leaked
a non-zero VNI offset to subsequent devices, silently skipping their
first N VNIs.
Furthermore, if devices are added or removed between dump calls,
ordinal device indexes can shift. Track the current device ifindex
in cb->args[2] and reset cb->args[1] if the device changes.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
vxlan_changelink() only refreshed the default fdb entries when the
remote IP changed, but vxlan_config_apply() also updates
default_dst.remote_ifindex when the lower device changes. A changelink
that only swaps the lower device therefore left the all zeros mac rdst
pointing at the old ifindex:
ip link add vxlan0 type vxlan id 10 group 239.1.1.1 dev eth0
ip link set dev vxlan0 type vxlan group 239.1.1.1 dev eth1
vxlan_xmit_one() uses rdst->remote_ifindex as the route oif, so traffic
kept leaving eth0.
VNI filter entries have the same problem, and are worse: their fdb
entries are keyed on the device remote_ifindex even when the vni
carries its own group, but vxlan_vnilist_update_group() only visited
the vnis without one. vxlan_vni_delete_group() later looks an entry up
with the current remote_ifindex, and vxlan_fdb_find_rdst() requires an
exact match, so the lookup failed and the entry survived the delete.
Re-adding the same vni then appended a second rdst, duplicating
transmitted BUM traffic.
Likewise, in vxlan_vni_update_group(), oldrip was only set when newrip
was NULL, so changing an existing VNI's group appended the new rdst
without deleting the old one. Set oldrip to the previous effective
remote IP whenever updating an existing VNI (!create).
Pass the old and new ifindex down to vxlan_update_default_fdb_entry()
so the append targets the new lower device and the delete still matches
the entry created for the old one, and refresh every vni rather than
only those inheriting the device group. If updating the vni list fails
partway through, unwind the already updated fdb entries (still deleting
the new rdst even if re-adding the old one fails) so default_dst and
the fdb entries do not diverge.
Also run vxlan_multicast_leave() and vxlan_multicast_join() when
VXLAN_F_VNIFILTER is set so per-VNI multicast memberships are migrated
even when the device default remote_ip is not multicast, and make
vxlan_multicast_leave_vnigrp() skip the default group and ignore
-EADDRNOTAVAIL when multiple VNIs share a multicast group.
The new ifindex is the one vxlan_config_apply() will commit, which is
the current one when lowerdev is NULL, so that default_dst and the fdb
entries can not diverge.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260922181102.3989489-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
hinic3_init_hwdev() stores the result of hinic3_adev_idx_alloc() in
hwdev->dev_id without checking for an error. If ID allocation fails but
the remaining initialization succeeds, hinic3_add_one_adev() uses the
negative error code as the auxiliary device ID instead of a reserved ID.
Return the allocation error before initializing the hardware. Add an
unwind label that clears pci_adapter->hwdev and frees the allocation
without attempting to release an ID that was never allocated.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Reported-by: Changyul Lee <lcy8047@gmail.com>
Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
Link: https://patch.msgid.link/179001656835.91284.3719235813225229273.idr-bug-81@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After conntrack NAT rewrites a packet, OVS refreshes the cached flow
key in ovs_nat_update_key(), which has a per-protocol branch for the
L4 ports (UDP/TCP/SCTP, conntrack.c). Address-only NAT cannot tell a
working SCTP branch from a missing one: the ports survive unchanged
either way, so a post-recirc match on the original port stays green
even with the branch deleted. The suite's NAT coverage drives TCP
over nc, and the merged SCTP test has no conntrack in the path, so
the SCTP branch goes unexercised.
Add test_sctp_nat_connect_v4: untracked client traffic to
192.168.0.20:4443 hits ct(commit,nat(dst=172.31.110.20:5555)),recirc,
and the post-recirc flows match the translated tuple,
ipv4(dst=172.31.110.20),sctp(dst=5555). Reply traffic is matched on
the restored original tuple, sctp(src=4443). With the SCTP branch
broken the translated port never reaches the key, no post-recirc
flow matches, and the association fails. The probe flow uses the
same ct+nat action as the real flows, so a kernel without
CONFIG_NF_NAT rejects it at flow-add time and the test skips instead
of failing. The config fragment sets CONFIG_NETFILTER_ADVANCED=y so
CONFIG_NF_CT_PROTO_SCTP is visible, CONFIG_NF_CT_PROTO_SCTP=y, and
CONFIG_NF_NAT=m so the reference build actually has those pieces.
After the association succeeds the test pushes a known payload
across and waits for the listener to log it.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Narcisa Vasile <narcisav.kernel@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260918144647.2024095-3-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The merged SCTP test covers only IPv4. The SCTP branch of the IPv6
extractor (the proto=132 walk after parse_ipv6hdr) and the v6 side of
the SCTP netlink validation (match_validate() requires the sctp() key
whenever ipv6(proto=132) is matched) have no selftest coverage.
Add test_sctp_connect_v6 mirroring the v4 test: bare icmpv6() flows
forward NS/NA, and ipv6(proto=132),sctp(dst=4443)/sctp(src=4443)
flows gate the association in the same three phases (flows installed,
removed, reinstalled). A keyless ipv6(proto=132) install must be
refused with EINVAL, pinning the reject side of the match_validate()
rule; without it a regression dropping the requirement would pass
unnoticed. The refusal is asserted to be EINVAL specifically, not a
parse error of the flow string. After the association succeeds the
test also pushes a known payload across and waits for the listener
to log it, proving the datapath carries the association's traffic
end to end, not only its handshake. Skips when the sctp module is
missing, socat lacks SCTP or IPv6 support, or IPv6 is unavailable;
an association or payload failure with the flows installed fails
the test.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Narcisa Vasile <narcisav.kernel@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260918144647.2024095-2-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Conntrack flush supports filtering by zone using CTA_ZONE, but this
attribute is really hard to use from user space applications. The
reason is that it is not possible to tell if it's supported or not.
Older kernels silently ignore CTA_ZONE. And in that case they just
happily flush all the entries from all zones breaking all the existing
connections. So, applications have to infer support from the kernel
version. While it works in most cases, it's not a particularly
reliable or desired way to check kernel capabilities from applications
that aim to be portable. There should be a better way to probe or
discover features in the kernel.
The CTA_FILTER interface on the other hand is simple enough to probe.
We can check for NLM_F_DUMP_FILTERED in the dump to see if filtering
is supported. And unknown sub-attributes in CTA_FILTER are rejected
explicitly since strict validation is in use there.
Let's add new CTA_FILTER_ZONE that signals that CTA_ZONE should be
filtered on. It is a flag, since everything in the CTA_FILTER is a
bit mask, i.e., a form of a flag. If set, it means that CTA_ZONE must
be present and be used for filtering. If the flag is not set however,
the filtering on CTA_ZONE will still take place to ensure backwards
compatibility. So, the flag doesn't really change the filtering
behavior, but it allows user space applications to properly discover
support for CTA_ZONE filtering without need to rely on kernel version
parsing or risk accidental flushes of the entire conntrack table,
and also without modifying the kernel state.
A new test variant is added to test with and without the new flag.
Since the setup code is moved into a shared function, expectations
replaced with assertions to bail early if the base setup fails to
avoid the cascade of secondary failures that can be misleading.
Error return is only for the SKIP cases.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
ctnetlink_filter_match_tuple() rejects an entry when
!ipv6_addr_cmp(filter, entry) is true. ipv6_addr_cmp() is a memcmp() and
returns 0 for equal addresses, so the condition is true exactly when the
addresses match: a CTA_FILTER dump with an IPv6 CTA_IP_SRC or CTA_IP_DST
skips every entry that matches the requested address and returns all the
others. The IPv4 branch compares with != and behaves correctly.
Observed with libnetfilter_conntrack NFCT_FILTER_DUMP_TUPLE: a dump
filtered on src 2001:db8::10 returned only the unrelated entries, and a
dump filtered on ::1 returned every entry except the ::1 ones.
conntrack-tools does not use the tuple filter for -L, which is why this
went unnoticed.
Use ipv6_addr_equal() so the IPv6 branch mirrors the IPv4 one.
Fixes: cb8aa9a3af ("netfilter: ctnetlink: add kernel side filtering for dump")
Cc: stable@vger.kernel.org
Signed-off-by: Piotr Kubik <piotr@kubik.pl>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Handling of concurrent hook changes with a dump in progress was
problematic in nfnl_hook_dump and entirely broken in nfnl_hook_dump_nat.
Address all issues in a single patch to please the review LLM.
Introduce sequence numbers in struct netns_nf to replace pointer
value-based modification detection which may fail due to memory buffer
reuse. This also eliminates the need for most manual cb->seq updates and
excessive array index value checks.
Since nat hook updates are protected by a different mutex than others,
they have to bump their own sequence number. nfnl_hook_dump_nat
therefore open-codes what nl_dump_check_consistent does but bumps
cb->seq instead of setting NLM_F_DUMP_INTR flag.
Dumps of many nat hooks was entirely broken since the array index was
not (re)stored. Use cb->args[1] for that and make sure it is reset upon
completion as the same dump may loop over multiple arrays of nat hooks.
In nfnl_hook_dump, don't signal NLM_F_DUMP_INTR if
nfnl_hook_entries_head returns error: This is a permanent condition
which does not change during a dump. It is already caught by
nfnl_hook_dump_start though, so should not happen anyway.
In general, access ops array pointer values using READ_ONCE since they
are assigned to using WRITE_ONCE.
Avoid setting NLM_F_DUMP_INTR flag in garbage memory by calling
nl_dump_check_consistent only for non-empty skbs. If not a single
netlink message was created, nfnetlink code will take care of setting
the flag.
Fixes: e2cf17d377 ("netfilter: add new hook nfnl subsystem")
Fixes: b010e2a4a9 ("netfilter: nfnetlink_hook: Dump nat type chains")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
nf_flow_table_cleanup() walks every registered flow table, checking the
network namespace for each flow in nf_flow_table_do_cleanup(). As a
result, tables in other namespaces are still iterated and their cleanup
work is flushed.
Compare the flow table's namespace with the device's namespace in
nf_flow_table_cleanup() and skip nonmatching tables. This avoids
unnecessary iteration and work flushing, and leaves the per-flow cleanup
callback to check only the interface index.
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
nf_flow_table_init() adds the flowtable to the global flowtables list.
However, tcf_ct_flow_table_get() sets the table's network namespace only
after that call, leaving a window where the published table has a NULL
namespace pointer.
Set the namespace before calling nf_flow_table_init() so that flowtable
list walkers can rely on it being initialized.
This is required by:
"netfilter: flowtable: check namespace before iterating flows"
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
In nf_conntrack_in, 'drop' counter increments if
nf_conntrack_handle_packet returns NF_DROP. This is a special case with
TCP packets (added by commit 6b69fe0c73 ("netfilter: nf_conntrack_tcp:
fix endless loop") and not related to invalid packets which are
responsible for all the other <=0 returns. So don't increment 'invalid'
ounter in this case.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
There is not much sense in incrementing multiple conntrack counters for
the same situation. Defining insert_failed as a situation where a valid
packet's conntrack can't be confirmed due to unresolvable clash sets it
apart from 'drop' (ENOMEM situation) and 'chaintoolong'.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
