Smatch combines the return values together and wants all the callers
to handle the positive values so it leads to static checker warnings.
Add a comment explaining the return values.
Generally functions which return non-standard values should have a
comment.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/09f24cefc214455305543a0528ceae6349c77419.1790357822.git.error27@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Lawrence Lee says:
====================
ipv6: update NUD_FAILED neighbors from NA messages
Neighbor Advertisements for existing NUD_FAILED entries are currently
ignored. This can leave a first-hop router with an unusable neighbor after
the host becomes reachable and announces itself, particularly when
forwarding is offloaded away from the kernel and traffic destined to the
FAILED neighbor is unable to trigger the kernel's normal neighbor
resolution process.
Allowing neighbor entries to be updated from NAs already received by the
kernel is preferable since it creates less work compared to periodically
probing FAILED neighbors (e.g. using NTF_EXT_MANAGED).
Extend accept_untracked_na to treat FAILED entries like absent entries.
Require a target link-layer address, IPv6 forwarding, and acceptance by the
sysctl, including its source-prefix check in mode 2. Recover the entry only
to STALE, including for solicited NAs, to maintain parity with handling of
non-existent neighbor cache entries.
Patch #1 implements the behavior and updates RFC 9131-related comments and
accept_untracked_na documentation.
Patch #2 extends ndisc_unsolicited_na_test.sh to cover FAILED-entry
recovery and each acceptance gate, including in-prefix and out-of-prefix
mode 2.
Thanks to Ido Schimmel for feedback on the original RFC.
====================
Link: https://patch.msgid.link/cover.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Seed a FAILED neighbor before triggering an unsolicited NA. Verify that
the entry transitions to STALE and learns the advertised link-layer
address only when drop_unsolicited_na is disabled, accept_untracked_na
mode 1 or in-prefix mode 2 is enabled, and IPv6 forwarding is enabled.
Verify that disabling each gate keeps the entry in FAILED without a
link-layer address.
Mark the seed externally learned and disable carrier-based eviction so
the entry cannot be garbage-collected before the NA arrives. Require the
marker after processing to prove that a recovered entry was updated in
place instead of deleted and recreated.
Keep the NA source, target, and neighbor key fixed for the mode 2 cases.
Vary the prefix configured on the router to exercise the source-prefix
check without changing the entry under test.
Arm packet capture before bringing up the host interface and starting
DAD. Wait for the capture to become ready and for tcpdump to exit so the
NA cannot be missed and receive processing is complete before checking
the neighbor entry.
Preserve the return code from test_unsolicited_na_common() before
constructing the test description. The array assignment previously reset
the return code to zero and caused existing cases to report false success.
Link: https://lore.kernel.org/r/20260813233344.445265-1-lfqlee314@gmail.com
Signed-off-by: Lawrence Lee <lfqlee314@gmail.com>
Link: https://patch.msgid.link/ce40008682ed26ab039168a5fcb515eff8d30c3a.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Transition a FAILED neighbor entry to STALE upon receipt of an NA
message on routers when accept_untracked_na is enabled. This extends the
RFC 9131 accept_untracked_na behavior so that FAILED entries are treated
the same as non-existent entries.
RFC 4861 section 7.3.3 says that an entry should be deleted when address
resolution fails. Linux instead retains the entry in NUD_FAILED, so
treating it as untracked is consistent with the protocol model.
Trying to resolve FAILED neighbors via periodic probing (e.g. using
NTF_EXT_MANAGED) is more work compared to this approach which uses
information in NAs that the kernel may already be receiving. Note that
because this behavior in IPv6 is dependent on the accept_untracked_na
sysctl setting, this approach is more conservative than IPv4 which
transitions FAILED neighbors to STALE by default upon receiving GARPs.
Link: https://lore.kernel.org/r/20260813233344.445265-1-lfqlee314@gmail.com
Signed-off-by: Lawrence Lee <lfqlee314@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/6be400e601f4ffa59e47ddb5daa33ecdd85dd88b.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Arthur Crepin Leblond says:
====================
w5100: restore GPIO-based link detection
In the previous version of the w5100 driver, the LINKLED pin could be
wired to a GPIO to detect the link status changes via an interrupt.
This only works on w5500 as it is the only one documenting its LINKLED
pin to hold the link status (on w5100 the LINKLED pin is changing with
RX/TX activity).
This series of patches is bringing back the link status detection on
w5500 using the Link Status bit of the PHY Configuration Register.
Additionally, the LINKLED pin can also be wired to detect link status
changes and read the register in the interrupt handler.
====================
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-0-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Detect the carrier state on the w5500 Ethernet controller using the
Link Status bit from the PHY Configuration register (PHYCFGR).
On w5100/w5200, which lack this register, get_link() is not implemented
and the carrier state is not reported (netif_carrier_(on|off) is not
called).
For the w5500, add an optional interrupt, wired to the LINKLED pin of
the device, to detect link status changes with a read of the PHYCFGR
register and update of the carrier state with netif_carrier_(on|off).
If this interrupt is not set in the DT binding, get_link() is not
implemented and the carrier state is not reported
(netif_carrier_(on|off) is not called).
The interrupt handler and the PHYCFGR register readings are
synchronized using a mutex.
A few changes are also brought for the bring-up/teardown
synchronization:
- The net device is registered last in the probe() function so no
operation can be performed before the probing is finished
- The net device is unregistered first in remove()
- dev_name is now used instead of netdev_name
- w5100_stop() calls cancel_work_sync() and flush_work() to make sure
there is no race condition or unfinished work
- w5100_suspend() calls w5100_stop()
- w5100_resume() calls w5100_open()
- The main irq is not automatically enabled in w5100_probe() but in
w5100_open() and disabled in w5100_stop()
Commit dacf281771 ("w5100: remove unused gpio link detection")
dropped the link_gpio/link_irq handling on the grounds that no
devicetree user passed a "link" gpio at the time and that it used the
old gpio interface.
This isn't a plain revert of that removal: link detection is now done
using a second interrupt rather than a gpio with a documented DT
binding.
Set the WIZNET entry as DRIVER and add drivers/net/ethernet/wiznet in
MAINTAINERS file.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Fixes: dacf281771 ("w5100: remove unused gpio link detection")
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-3-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add an optional link status interrupt which can be connected to the
LINKLED pin on the device to detect link status changes. This second
interrupt is only supported on wiznet,w5500.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-2-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the Wiznet w5x00 SPI Ethernet controller binding from
plain text to DT schema.
Change the trigger type from edge-falling to low to match the driver
implementation.
Add wiznet,w5100.yaml entry in MAINTAINERS.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-1-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After reclaiming, the Tx poll asks to be polled again. That extra poll
finds nothing to do and does not reduce the interrupt rate.
Complete the NAPI and unmask the ring interrupt right after the reclaim.
On a CM4 this raises 60 byte pktgen Tx from about 187k to 224k pps and
saves about 5% of one core at TCP line rate.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260928121454.901306-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace if/else blocks using regmap_set_bits()/regmap_clear_bits() with
the simpler regmap_assign_bits() calls in the lantiq gswip, mt7530 and
qca8k drivers.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260924083538.461887-1-peng.fan@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use IP_LOCAL_PORT_RANGE to limit a socket to 8 ports, bind 8 sockets
to port 0 and check they get 8 distinct ports and the 9th bind fails
with EADDRINUSE. Run it for the four combinations of reuse options on
the sockets:
none (existing test)
SO_REUSEPORT
SO_REUSEADDR
SO_REUSEADDR + SO_REUSEPORT
TCP passes all four. Before the udp fix UDP only passes the first
one: the scan hands out a port already taken by a socket with the
same reuse options, so fewer than 8 distinct ports come back and the
9th bind succeeds.
# ./ip_local_port_range.sh
Before:
ok 13 ip_local_port_range.ip4_udp.exhaust_8_port_range
not ok 14 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseport
not ok 15 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr
not ok 16 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr_reuseport
ok 49 ip_local_port_range.ip6_udp.exhaust_8_port_range
not ok 50 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseport
not ok 51 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr
not ok 52 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr_reuseport
After:
ok 13 ip_local_port_range.ip4_udp.exhaust_8_port_range
ok 14 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseport
ok 15 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr
ok 16 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr_reuseport
ok 49 ip_local_port_range.ip6_udp.exhaust_8_port_range
ok 50 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseport
ok 51 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr
ok 52 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr_reuseport
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260928023145.301855-2-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Observed with two independent servers in the same process:
fd1 = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt(fd1, SOL_SOCKET, SO_REUSEPORT, ...);
bind(fd1, port 0); /* got 40000 */
fd2 = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt(fd2, SOL_SOCKET, SO_REUSEPORT, ...);
bind(fd2, port 0); /* got 40000 as well */
Both sockets end up on the same port and join the same reuseport
group, so each of them takes part of the other's datagrams. The same
port sharing happens with SO_REUSEADDR, without the reuseport group.
udp_lib_lport_inuse() keeps the reuse rules when it scans for a free
port: a socket with SO_REUSEADDR set, or one with SO_REUSEPORT and
the same uid, is not a conflict, so its port is never marked in the
bitmap and the scan can hand it out again. Those rules only make
sense when the user asks for a specific port. bind(0) wants a free
port and has no way to know whose port it lands on.
TCP already does this: inet_csk_find_open_port() passes relax=false
and reuseport_ok=false, so the scan treats every port in use as a
conflict whatever options the sockets have. Commit aacd9289af
("tcp: bind() use stronger condition for bind_conflict") did it for
SO_REUSEADDR and commit 0643ee4fd1 ("inet: Fix get port to handle
zero port number with soreuseport set") for SO_REUSEPORT.
Do the same for UDP: ignore both options during a scan, keep them
for an explicit port.
This changes bind(0) for SO_REUSEADDR sockets once the port range is
full: it used to share a port and now fails with EADDRINUSE, like
TCP. Sharing a port on purpose when the range is full is a feature,
TCP has net.ipv4.ip_autobind_reuse for it, off by default. UDP can
get the same knob later, this patch only fixes the scan.
Fixes: ba418fa357 ("soreuseport: UDP/IPv4 implementation")
Cc: stable+noautosel@kernel.org # bind() behaviour change
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260928023145.301855-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When disconnecting a device while firmware is not present on the system,
usbatm_usb_disconnect() waits for the heavy_init thread to finish:
wait_for_completion(&instance->thread_exited);
If CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled, missing firmware
causes request_firmware() to fall back to sysfs/udevd. This creates a
circular dependency during disconnect:
1. usb_disconnect() holds device_lock(&udev->dev).
2. usbatm_usb_disconnect() waits for instance->thread to exit.
3. instance->thread waits for request_firmware() sysfs fallback.
4. udevd receives the firmware uevent and attempts to read sysfs
attributes (e.g. serial), blocking on device_lock(&udev->dev).
Furthermore, the fallback wait uses wait_for_completion_killable_timeout(),
which ignores the non-fatal SIGTERM signal sent by usbatm_usb_disconnect().
Because speedtch and cxacru probe multiple candidate firmware files
sequentially, each file stalls for the 60-second fallback timeout,
triggering hung task timeouts (>120s) reported by syzbot.
Switch to request_firmware_direct() to probe firmware files directly from
the filesystem without falling back to user-mode helper.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Reported-by: syzbot+9ca2c9f85bd8b5e46516@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ca2c9f85bd8b5e46516
Signed-off-by: Matvey Valigura <valigurasm@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260924050654.15347-1-valigurasm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stanislav Fomichev says:
====================
net: consolidate devmem net_iov freelist and DMA handling
Follow up on the recently merged devmem gen_pool removal by consolidating
devmem's net_iov freelist and DMA-address handling.
- move devmem freelist to index-based approach with push/pop helpers
- switch devmem to public memory-provider helpers and reject DMA
addresses that cannot be represented
- decode stored DMA addresses for TX on 32-bit systems with 64-bit
dma_addr_t
====================
Link: https://patch.msgid.link/20260925201522.254717-1-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On 32-bit architectures where dma_addr_t is wider than unsigned long,
page_pool_set_dma_addr_netmem() stores page-aligned DMA addresses shifted
by PAGE_SHIFT. The net_iov branch of __skb_frag_dma_map() adds byte offsets
to the encoded value, so the NIC is programmed with an invalid DMA address.
This can trigger an IOMMU fault or DMA from unintended memory.
Consolidate DMA address encoding, decoding, and representability checks in
netmem helpers. Use the common decoder from the page pool and net_iov TX
paths so both interpret stored addresses consistently.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-4-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Use public memory-provider helpers for DMA address storage and page-pool
association instead of open-coding page_pool state and accounting.
Zero the net_iov array because net_mp_niov_set_page_pool() ORs
PP_SIGNATURE into pp_magic. Reject DMA addresses that cannot be
represented in net_iov metadata.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-3-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move devmem's freelist to an index-based approach similar to io_uring.
This halves the memory requirements for the freelist.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-2-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Marvell PHY driver consumes marvell,reg-init as one or more
<page register mask value> tuples. Define the property so dtbs_check
validates the existing board descriptions.
Existing users have no compatible or just "ethernet-phy-ieee802.3-c22"
so this has to go into the generic ethernet-phy.yaml schema. Marking it
deprecated both for that reason and because opaque register
initialization values are discouraged in DT.
Assisted-by: LLM
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260925140410.1157036-2-robh@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
sock_sendmsg_nosec() runs in syscall context but calls BUG_ON() if
proto_ops->sendmsg() returns -EIOCBQUEUED. Crashing the kernel on an
unexpected return value is dangerous for production workloads.
This risk is real: any signed integer overflow in a sendmsg handler
that returns 0xfffffdef (-529, -EIOCBQUEUED) triggers this BUG_ON. In
one month, two such bugs were reported in PF_PACKET, reachable by
a local user with CAP_NET_RAW in a user namespace:
- Commit 73e594c19b ("af_packet: Don't cast tpacket_hdr.tp_len to int
in tpacket_parse_header().")
- In review ("net/packet: prevent TX_RING byte count overflow")
https://lore.kernel.org/netdev/20260925124829.6595-1-ilkka.lappetelainen@gmail.com/
Replace the BUG_ON with DEBUG_NET_WARN_ON_ONCE() to retain debug and
syzbot coverage, and return -EIO so that -EIOCBQUEUED does not leak to
userspace or trigger the BUG_ON(ret == -EIOCBQUEUED) in VFS callers of
sock_write_iter() such as new_sync_write().
Failing gracefully is safe because the original reason for the BUG_ON
is gone. It was added in commit 599bd19bdc ("fs: don't allow to complete
sync iocbs through aio_complete") and commit d8725c86ae ("get rid of the
size argument of sock_sendmsg()") to prevent an async completion from
corrupting a caller's on-stack kiocb. Commit 1b78414047 ("net: Remove
iocb argument from sendmsg and recvmsg") removed that on-stack kiocb.
More recently commit fcc77d33a3 ("net: Remove support for AIO on
sockets") removed socket AIO support entirely.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260928020420.3097018-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Callers of __pktgen_NN_threads() only check whether a pktgen_dev was
found. Returning the pointer exposes it outside the helper even though
neither caller uses the object itself.
Return bool instead and keep the pktgen_dev pointer internal to the
helper.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Reviewed-by: Ivy Lopez <skunkolee@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260927135406.3969970-1-nicoyip.dev@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix two invalid name-prefixes in the specs:
- It's PHY_UPSTREAM_MAC, not PHY_UPSTREAMMAC.
- It's PHY_UPSTREAM_PHY, not PHY_UPSTREAMPHY.
- It's OVPN_MODE_P2P, not OVPN_MODEP2P.
- It's OVPN_MODE_MP, not OVPN_MODEMP.
CC: Andrew Lunn <andrew@lunn.ch>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-10-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix a typo in the naming of a cls-flags constant.
The correct name for TCA_CLS_FLAGS_NOT_IN_HW is "not-in-hw",
not "not-in-nw".
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: "Jonas Köppeler" <j.koeppeler@tu-berlin.de>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-9-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Use the correct naming for enum members:
- In feature-flags, it's NL80211_FEATURE_ND_RANDOM_MAC_ADDR,
so "nd-random-mac-addr", not "no-random-mac-addr".
- In commands, it's NL80211_CMD_UNEXPECTED_4ADDR_FRAME,
so "unexpected-4addr-frame", not "unexpected-4-addr-frame".
CC: Joe Damato <joe@dama.to>
CC: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-8-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Correct the values for enum ethtool_module_fw_flash_status:
- ETHTOOL_MODULE_FW_FLASH_STATUS_STARTED is 1, not 0.
- ETHTOOL_MODULE_FW_FLASH_STATUS_IN_PROGRESS is 2, not 1.
- ETHTOOL_MODULE_FW_FLASH_STATUS_COMPLETED is 3, not 2.
- ETHTOOL_MODULE_FW_FLASH_STATUS_ERROR is 4, not 3.
Re-align the YNL spec by explicitly setting the first value to 1.
CC: Andrew Lunn <andrew@lunn.ch>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-7-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
enum ethtool_c33_pse_ext_state is misaligned with YNL:
- ETHTOOL_C33_PSE_EXT_STATE_OVLD_DETECTED is 6.
- ETHTOOL_C33_PSE_EXT_STATE_PD_DLL_POWER_TYPE is 7 (not in YNL).
- ETHTOOL_C33_PSE_EXT_STATE_POWER_NOT_AVAILABLE is 8, not 7.
- ETHTOOL_C33_PSE_EXT_STATE_SHORT_DETECTED is 9, not 8.
In commit c8149739af ("netlink: specs: Expand the PSE netlink command
with C33 new features") the PD_DLL_POWER_TYPE enum member was skipped,
leading incorrect values for power-not-available and short-detected.
As PD_DLL_POWER_TYPE is not used, then skip it, but set the value for
power-not-available to 8.
CC: Andrew Lunn <andrew@lunn.ch>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-6-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The correct type for resource-scope is flags, not enum:
- DEVLINK_RESOURCE_SCOPE_DEV is _BITUL(0) aka. 1, not 0.
- DEVLINK_RESOURCE_SCOPE_PORT is _BITUL(1) aka. 2, not 1.
This patch also removes "enum-as-flags", as it is now redundant,
these changes does not change the generated policy.
Before this patch, this generated devlink-user.c function call:
devlink_resource_scope_str(DEVLINK_RESOURCE_SCOPE_DEV) returned "port",
not "dev", as it didn't use ffs() to convert the value.
CC: Jiri Pirko <jiri@resnulli.us>
CC: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-5-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Correct the names of `enum net_device_flags` constants:
- IFF_POINTOPOINT should be "pointopoint", not "point-to-point".
- IFF_NOTRAILERS should be "notrailers", not "no-trailers".
- IFF_NOARP should be "noarp", not "no-arp".
- IFF_ALLMULTI should be "allmulti", not "all-multi".
- IFF_AUTOMEDIA should be "automedia", not "auto-media".
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-4-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
YNL enum ifla-inet6-stats got misaligned with C, as two commits
reordered the enum.
In commit b4a11b2033 ("net: fix IPSTATS_MIB_OUTPKGS increment in
OutForwDatagrams."), IPSTATS_MIB_OUTPKTS was renamed to _OUTREQUESTS
and a new _OUTPKTS was as the last entry.
In commit 652e2c7778 ("net: reorganize IP MIB values (II)"), the
IPSTATS_MIB_* enum was reorganized for data locality.
Neither of these commits updated the YNL spec.
This changed uAPI, as IPSTATS_MIB_* is used as indicies in an u64 array,
exported as IFLA_INET6_STATS by inet6_fill_ifla6_stats_attrs().
This patch updates ifla-inet6-stats to reflect both of these commits.
Next time we want to reorganize these counters we should properly apply
mapping as to maintain the current order on the netlink side.
While touching these entries, also remove the dash from ect{0,1}-pkts,
so that they align with the C naming.
This pre-existing issue was identified by Sashiko during review of
commit 2b0aecb7b2 ("netlink: specs: rt-link: add accept-ra-min-lft").
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260831093458.472180-1-ast%40fiberby.net
CC: Heng Guo <heng.guo@windriver.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-3-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The YNL "ipv4-devconf" enum is misaligned with the IPV4_DEVCONF_* enum.
IPV4_DEVCONF_* starts at 1, ipv4-devconf starts at 0.
$ git grep -B3 -A1 IPV4_DEVCONF_FORWARDING include/
inc../uapi/linux/ip.h-/* index values for the variables in ipv4_devconf */
inc../uapi/linux/ip.h-enum
inc../uapi/linux/ip.h-{
inc../uapi/linux/ip.h: IPV4_DEVCONF_FORWARDING=1,
inc../uapi/linux/ip.h- IPV4_DEVCONF_MC_FORWARDING,
Re-align the YNL spec by explicitly setting the first value to 1.
This misalignment has been present since the spec was added in
commit b2f63d904e ("doc/netlink: Add spec for rt link messages").
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-2-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Dismantle two netns holding a dummy and a netkit pair registered in
opposite order. unregister_netdevice_many_notify() takes the instance
locks of all the devices at once, nesting the two kinds of devices one
way for the first netns and the other way for the second. With lockdep
enabled this used to trigger a circular locking report.
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260926041832.1649675-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netdev_lockdep_set_classes() puts dev->lock in a separate lockdep class,
by type (netkit vs dummy etc), with the intent of keeping the instance
locks of individual devices as independent from each other as possible.
In practice it does the opposite. lockdep only calls the cmp_fn for locks
of the same class, so netdev_lock_cmp_fn() never gets a say when devices
from different classes are nested. Instead lockdep records a dependency
between the classes, and reports a circular locking problem as soon as
the nesting happens the other way round, e.g. when devices are unregistered
in a batch.
======================================================
WARNING: possible circular locking dependency detected
7.3.0-rc3+ #26 Not tainted
------------------------------------------------------
kworker/u256:1/326 is trying to acquire lock:
ff110000104fce28 (&dev_instance_lock_key#6){+.+.}-{4:4}, at:
unregister_netdevice_many_notify+0x1141/0x1c30
but task is already holding lock:
ff110000127f2e28 (&dev_instance_lock_key#7){+.+.}-{4:4}, at:
unregister_netdevice_many_notify+0x1141/0x1c30
-> #1 (&dev_instance_lock_key#7){+.+.}-{4:4}:
__lock_acquire+0x767/0xd60
lock_acquire.part.0+0xd0/0x260
__mutex_lock+0x17d/0x1f20
unregister_netdevice_many_notify+0x1141/0x1c30
default_device_exit_batch+0x3ee/0x520
ops_undo_list+0x2cc/0x8a0
cleanup_net+0x442/0x9c0
process_one_work+0x951/0x1ab0
worker_thread+0x5a6/0xd10
kthread+0x339/0x430
ret_from_fork+0x4a4/0x6f0
ret_from_fork_asm+0x1a/0x30
-> #0 (&dev_instance_lock_key#6){+.+.}-{4:4}:
check_prev_add+0xeb/0xe60
validate_chain+0x598/0x900
__lock_acquire+0x767/0xd60
lock_acquire.part.0+0xd0/0x260
__mutex_lock+0x17d/0x1f20
unregister_netdevice_many_notify+0x1141/0x1c30
default_device_exit_batch+0x3ee/0x520
ops_undo_list+0x2cc/0x8a0
cleanup_net+0x442/0x9c0
process_one_work+0x951/0x1ab0
worker_thread+0x5a6/0xd10
kthread+0x339/0x430
ret_from_fork+0x4a4/0x6f0
ret_from_fork_asm+0x1a/0x30
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&dev_instance_lock_key#7);
lock(&dev_instance_lock_key#6);
lock(&dev_instance_lock_key#7);
lock(&dev_instance_lock_key#6);
*** DEADLOCK ***
locks held by kworker/u256:1/326: 6, last CPU#6:
#0: ff11000001c2b540 ((wq_completion)netns){+.+.}-{0:0}, at:
process_one_work+0x117c/0x1ab0
#1: ffa0000001a3fd18 (net_cleanup_work){+.+.}-{0:0}, at:
process_one_work+0x8ce/0x1ab0
#2: ffffffff98f53288 (pernet_ops_rwsem){++++}-{4:4}, at:
cleanup_net+0xc1/0x9c0
#3: ffffffff98f6ede0 (rtnl_mutex){+.+.}-{4:4}, at:
default_device_exit_batch+0x92/0x520
#4: ff1100001321ae28 (&dev_instance_lock_key#7){+.+.}-{4:4}, at:
unregister_netdevice_many_notify+0x1141/0x1c30
We can't put all devices in the same class, that'd be too permissive.
netdev_nl_queue_create_doit() and netdev_nl_bind_tx_doit() lock
a virtual device (netkit) before a physical device, without rtnl_lock.
We can never allow locking in the opposite order even under rtnl_lock.
cmp_fn cannot enforce this sort of rule: lockdep keys its chain cache on
the sequence of lock classes, so with a single class both orders hash
to the same chain and only whichever happens first is validated.
netdev_lock_cmp_fn() itself has another source of false-negatives.
lockdep calls it from within __lock_acquire(), with the recursion counter
already raised, so lock_is_held_type() always returns LOCK_STATE_UNKNOWN,
which means lockdep_rtnl_is_held() always returns true / held.
Use rtnl_is_locked(), which looks at the mutex directly and does
work from that context. We may still miss a bad case if some other
process is holding the lock, not us, but that's better than the
100% false negative rate of lockdep_rtnl_is_held().
One last thing, lockdep compares the address of the cmp function,
so it can't be a static inline - that would work similarly to having
separate classes, again. Move it to a source file.
Tested by nesting two instance locks from a module, one scenario per boot
since the first splat turns debug_locks off:
first second rtnl reported
-----------------------------------------------------------
virt->virt no recursive locking
virt->virt yes -
virt->phys no -
virt->phys yes -
phys->virt no - (records the edge)
phys->virt yes - (records the edge)
phys->phys no recursive locking
phys->phys yes -
virt->phys phys->virt no, no circular dependency
virt->phys phys->virt no, yes circular dependency
virt->phys phys->virt yes, no circular dependency
virt->phys phys->virt yes, yes circular dependency
phys->virt virt->phys no, no circular dependency
phys->virt virt->phys yes, yes circular dependency
virt->virt virt->virt yes, no recursive locking
phys->phys phys->phys yes, no recursive locking
(netkit and dummy stood in for the virtual devices, virtio_net and
netdevsim for the physical ones.)
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260926041832.1649675-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Daniel Zahka says:
====================
eth: mpnic: initial support for Meta Platforms NIC
Meta Platforms NIC is the second-generation NIC from Meta. There are
quite a few high-level similarities to fbnic, but all of the CSRs and
descriptors have been reshuffled, and new features have been added.
Since the device is sufficiently different from fbnic, and the design of
our FW is minimal, we have decided a separate driver is appropriate.
Major new features compared to fbnic will take a while to land. This
series includes only the bare-bones Tx/Rx datapath.
Our high-level patch sequence and plan for the upcoming series is:
1. Core datapath (this series)
2. Basic offloads, RSS, and counters
3. Firmware mailbox support
4. Base ethtool operations
This patch series was prepared in part with these LLM prompts:
https://github.com/kuba-moo/ai-prompts/blob/main/driver-upstreaming-prompts.md
The prompts were used to distill our fully-featured OOT driver into this
minimal Tx/Rx capable upstream driver. We then performed human review on
the output to create this posting. Jakub has made the prompts public in
case people would like to take a look.
v1: https://lore.kernel.org/r/20260922-linux-mpnic-v1-0-236844f53072@gmail.com
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
====================
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-0-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
A frame arrives as a run of completion descriptors: one header
address/length descriptor, one address/length descriptor per payload
page, and a metadata descriptor that closes the frame. The frame is
assembled in an xdp_buff as the descriptors come in and handed to the
stack when the metadata descriptor arrives.
A page holds several frames, so rather than taking a reference per
frame the driver takes a batch of references when it starts handing the
page out and returns whatever is left over once the device moves on to
the next one. Payload fragments that turn out to be contiguous within
one page are merged so that a frame spread over a page does not eat one
skb fragment slot per descriptor.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-8-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Rx side of a queue triad is a header queue, a payload queue and a
completion queue. With HDS not active yet, frames are split between the
two buffer queues at a fixed header boundary: everything up to 1536
bytes lands in the header page, the rest goes to the payload page. Small
frames therefore never touch the payload queue, and several of them
share one header page.
The device is set to leave headroom and tailroom for XDP and
skb_shared_info respectively.
Both queues draw from one page pool per triad and post buffer
descriptors to the device in batches.
Even though we do not support XDP yet, use the XDP APIs for tracking
pre-skb buffers. The XDP buffer handling helpers save us from
reimplementing the same logic in the driver.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-7-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Register the network interface and let it transmit skbs.
The typical TWQ descriptor sequence for an skb is: 1 primary metadata,
followed by 0 or more non-last address + length (A/L) descriptors,
terminated by an always present last A/L descriptor.
The device does not write a Tx completion unless it is requested in the
primary metadata desc. The xmit path sets this bit when the stack does
not report netdev_xmit_more(). This can create a problem if the last
packet in a burst is dropped by the driver. To deal with that case, the
driver latches the last metadata for which a completion was not
requested, and uses this to request a completion and flush queued
packets when one is dropped.
There is no link state yet, so carrier follows the administrative
state.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-6-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Point the hardware at the descriptor rings and provide functions for
turning the Tx queues on and off.
Teardown has to wait for the DMA engines to go idle before the ring
memory can be freed: disabling a queue only stops the device picking up
new work, it does not tell us that the work already fetched has been
retired. Each block exposes an idle bitmap per queue, and every one of
the four blocks a packet passes through on its way out has to report
idle before the descriptors are safe to free.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-5-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Queues come in triads of two work queues and one completion queue. The
Tx triad only uses the first work queue for now, the second one will be
used for the XDP ring later.
Add the ring structures, the per NAPI vector allocation of triads,
descriptor memory and interrupts, and the completion processing. The
completion queue does not report one entry per packet, it reports a
work queue head, so a single completion can release many packets.
Nothing enables the queues in hardware or submits anything to them yet,
that comes with the next two changes.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-4-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Request one vector for FW generated interrupts and then one vector per
CPU to use for the completion queues. Nothing requests a handler yet,
that comes with the NAPI vectors.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-3-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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>
