hci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev->tx_work
unconditionally. They can run from the L2CAP/SCO/ISO socket send path
while hci_dev_close_sync() is draining hdev->workqueue (HCIDEVDOWN
racing with a socket write). Since that queue_work() is not chained
work from the tx_work worker itself, __queue_work() sees the queue
marked __WQ_DRAINING, warns "cannot queue %ps on wq %s", and drops
the work:
WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work
Call Trace:
queue_work_on
l2cap_chan_send
l2cap_sock_sendmsg
...
hci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before
draining, but only hci_cmd_work() and handle_cmd_cnt_and_timer()
check it before queuing. Route the tx_work producers through the
same guard via a shared hci_sched_tx() helper.
Fixes: 525daaea45 ("Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close")
Reported-by: syzbot+b6919040d9958e2fc1ae@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b6919040d9958e2fc1ae
Signed-off-by: ThangNN99 <ngocthang2710.1999@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
- The task iterator could pick up a dying task whose refcount had already
dropped to zero and resurrect it, leading to a use-after-free when
reading cgroup.procs. Skip such tasks.
-----BEGIN PGP SIGNATURE-----
iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCaql+xg4cdGpAa2VybmVs
Lm9yZwAKCRCxYfJx3gVYGVcaAP424sQDRkkInl7APgUeQfgUheNG8WgCUt+qMgT2
6VbVEwD9HodEyKW4r/JBWcqN3m4bbNSx57gpXgQwH+ESoorqLgs=
=nZ8D
-----END PGP SIGNATURE-----
Merge tag 'cgroup-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fix from Tejun Heo:
- The task iterator could pick up a dying task whose refcount had
already dropped to zero and resurrect it, leading to a use-after-free
when reading cgroup.procs. Skip such tasks.
* tag 'cgroup-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup: Avoid iteration of dying tasks with zero refcount
eir_get_service_data() reads a 16-bit UUID from the service data using
get_unaligned_le16() without first checking that the data is long enough
to hold a UUID16 (2 bytes). If a malformed EIR entry has a service data
field with only 1 byte of payload (field_len=2), eir_get_data() returns
dlen=1. The subsequent get_unaligned_le16() then reads 1 byte past the
field boundary.
Additionally, if the corrupted UUID happens to match, the length
calculation "dlen - 2" underflows to SIZE_MAX since dlen is size_t.
Current callers either pass NULL for the length parameter or bounds-check
the returned length, but future callers may not.
Add a check that dlen >= sizeof(u16) and skip fields that are too short
to contain a valid UUID16.
Fixes: 8f9ae5b3ae ("Bluetooth: eir: Add helpers for managing service data")
Cc: stable@vger.kernel.org
Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The NXP IW610 module exposes itself as a composite USB device
(0471:0215) with three interfaces: two real Bluetooth HCI interfaces
(class 0xe0) and one vendor-specific WiFi interface (class 0xff) used
by mwifiex-nxp.
The composite device's whole USB descriptor reports class 0xe0/01/01
(Bluetooth), so btusb_table's generic USB_DEVICE_INFO(0xe0, 0x01, 0x01)
entry matches every interface, not just the two real HCI ones -- btusb
ends up binding the WiFi interface too, and mwifiex-nxp never gets it.
Fix:
1. In btusb_table (the table the USB core actually matches against),
explicitly ignore the WiFi interface via BTUSB_IGNORE, ahead of the
generic entry.
2. In quirks_table, scope the existing BTUSB_MARVELL entry to the BT
interface class instead of matching the whole device by VID/PID
(harmless either way since quirks_table isn't consulted for initial
binding, but keep it correct).
Not upstream anywhere: checked NXP's own i.MX kernel fork
(nxp-imx/linux-imx), no IW610 references in btusb.c on any branch --
their reference designs wire this chip differently (WiFi over SDIO
per their release notes), so they never hit this.
Signed-off-by: Nicolas Thibert <nithibert@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: LLM (Claude Sonnet 5, Anthropic)
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
wireless.wiki.kernel.org has not existed for a while. Update all links to
point to the current rendered pages at wireless.docs.kernel.org.
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915-wireless-wiki-v1-1-21dc76684b44@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Schedulers on the default cid mapping treat [0, nr_online_cids) as the
online set and restart on hotplug. Schedulers that install their own mapping
with scx_bpf_cid_override() have no way to learn which cids are online: the
count no longer identifies members and the CPU-form cpumask is unusable from
cid programs. This is an obvious hole in the cid API.
Add scx_bpf_online_cmask(), a kernel-maintained cmask in the scheduler's
arena, allocated alongside the per-CPU scratch masks and populated after the
cid mapping is finalized and before ops.init(), for child schedulers too.
The pointer stays valid through ops.exit() with no reference to take. It is
the arena offset as a void pointer, the same form struct_ops arena arguments
arrive in. The verifier types the void return as a scalar for the program's
arena cast.
The mask follows the SCX hotplug notifications: seeded from cpu_active_mask
and updated before ops.cid_online/offline() runs, so it lags cpu_online_mask
only inside a hotplug transition. Updates walk the scheduler list under the
lock that also serializes unlinking. Reads are live, not atomic snapshots.
Root initialization excludes hotplug.
v2: Reworded the getter kerneldoc (Andrea Righi).
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
scx_qmap tracks idle cids itself. pick_direct_dispatch_cid() claims a cid by
clearing its bit and the task is inserted into that cid's local DSQ, which
kicks the CPU. When the task does not arrive, for example because the insert
fell back to the global DSQ after an affinity change, the CPU wakes, finds
nothing and picks idle again. That is not an idle transition, so
ops.update_idle() is not called and the cid stays marked busy until an
unrelated task runs on it.
Restore the claim from ops.dispatch(). The kick guarantees a dispatch on the
kicked CPU, and when it finds nothing to run with a NULL @prev, the CPU is
going back to idle. Document the pattern in ops.update_idle(), which reports
only actual transitions.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Cc: Andrea Righi <arighi@nvidia.com>
* Re-add the range check for millisecond to jiffy conversion in sysctl
They where removed in d174174c67 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM
macro with functions") and b96b5c6708 ("sysctl: Replace
do_proc_do{int,ulong,uint}vec with do_proc_vec")
* Fix type truncation in sysctl_msec_to_jiffies
Previously truncated millisecond values now get converted into
MAX_JIFFY_OFFSET
* Testing
Ran through x86_64 selftest. One week in linux-next
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEErkcJVyXmMSXOyyeQupfNUreWQU8FAmqo8u8ACgkQupfNUreW
QU8upgv+Khwwu6gXQNXyA91daXY+sxvpEdERi5qTyqYjQJ3zg+YFNWziZ7Yp+JVB
wiYpmWKjqI1E1N/lC06vjQoKGkOnzHA0IMeCWFtO0wvIZFuWt200tGjS4fm1i48b
/hF7aZK+oi8yrs1auzIOS+4d0VCDIfScWlAwIH1nqmt7xiUTlChLt9UNdbqusJVw
NuMrX1CjxtPQqcZMdHwn83uiKkOvYN7DhPFI1VIgwWbp8TjTvskB0lsxqXMuxmUI
xEt74FcWGhjhCjxy4i85P85LBcVT5W2l21GBvUqvzSP+aWK9/n/gCL2KWtJEASbb
VaBEqN4azx/UEn4eUemGcBPsWG44a3i3hkx/V2UIJrbd/nh2EfQhugsrMtB0lAjL
xSn48PlKMXeF7GgsUWC0NmHU0HwKrROEafWqayuFLHnobwfAb9KYFBkCV8phUS6E
TfJPoDPwBzZebIP+HxY5SNY9CYTBnaUh/U8qq00eBgz/AUB6FwIXAuUMehnc9hcq
mqFSZRt4
=3g1Y
-----END PGP SIGNATURE-----
Merge tag 'sysctl-7.03-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl
Pull sysctl fixes from Joel Granados:
- Re-add the range check for millisecond to jiffy conversion in sysctl
They where removed in d174174c67 ("sysctl: replace
SYSCTL_INT_CONV_CUSTOM macro with functions") and b96b5c6708
("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec")
- Fix type truncation in sysctl_msec_to_jiffies
Previously truncated millisecond values now get converted into
MAX_JIFFY_OFFSET
* tag 'sysctl-7.03-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl:
sysctl: Fix type truncation in sysctl_msec_to_jiffies
sysctl: Check range in do_proc_ulong_conv_ms_jiffies
sysctl: Check range in proc_dointvec_ms_jiffies_minmax
virtio_spi_transfer_one() puts spi->bits_per_word into the request
header, so a transfer that sets its own word size reaches the backend
with the device default instead. The SPI core has already copied that
default into xfer->bits_per_word when the transfer leaves it at zero,
the same way it does for xfer->speed_hz, which this function already
uses.
Per-transfer word sizes are ordinary SPI usage. mipi_dbi, for one, sends
a 9-bit command and reads the reply as 8-bit data in the same message.
With a 16-bit device default, a one-byte transfer asking for 8 bits goes
out as a partial 16-bit word, which the backend may reject.
Fixes: f98cabe3f6 ("SPI: Add virtio SPI driver")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Hao-Qun Huang <alvinhuang0603@gmail.com>
Link: https://patch.msgid.link/20260913032049.11209.alvinhuang0603@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist
putting each entry into 'sg', but the entry length is read from 'sgl'
(the list head) instead of 'sg' (the current entry):
for_each_sg(sgl, sg, sg_len, i) {
addr = sg_dma_address(sg);
avail = sg_dma_len(sgl); /* should be 'sg' */
Consequently 'avail' is always the length of the first entry. For
multi-sg lists this causes out-of-bounds reads when a later entry is
shorter than the first, and silent data loss when it is longer.
Single-sg or uniformly-sized lists happen to mask the issue.
Fixes: c8acd6aa6b ("dmaengine: mmp-pdma support")
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260910021652.1296640-1-shoubaineng@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Do not reset the RFC1002 length of the complete response when a query
info buffer is too small. The current command will add its error response
through ksmbd_iov_pin_rsp(), while resetting the base length can truncate
earlier responses in a compound request.
This lets ksmbd return the earlier responses and the query-info error
response together. Remove the now-unused rsp_org parameter from the pipe
query-info helpers.
Fixes: e2b76ab8b5 ("ksmbd: add support for read compound")
Reported-by: Mobin Aydinfar <mobin@mobintestserver.ir>
Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Windows may request FILE_NORMALIZED_NAME_INFORMATION with an output
buffer that only fits the fixed portion of the variable-length response.
Treat the fixed portion as FILE_NORMALIZED_NAME_INFORMATION_SIZE so ksmbd
returns STATUS_BUFFER_OVERFLOW instead of STATUS_INFO_LENGTH_MISMATCH.
This avoids rejecting valid partial normalized-name responses.
Fixes: 6b8b79226b ("ksmbd: fix partial file information responses")
Reported-by: Mobin Aydinfar <mobin@mobintestserver.ir>
Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
We can hit a division by zero crash in tcp_rcvbuf_grow()
and tcp_rcv_space_adjust():
divide error: 0000 [#1] PREEMPT SMP
RIP: 0010:tcp_rcvbuf_grow+0x187/0x450 net/ipv4/tcp_input.c:939
...
grow = div_u64(((u64)rcvwin << 1) * (newval - oldval), oldval);
The division uses oldval = tp->rcvq_space.space as divisor.
When tp->rcvq_space.space is zero, this leads to a divide-by-zero
exception.
tp->rcvq_space.space is initialized in tcp_init_buffer_space():
tp->rcvq_space.space = min3(tp->rcv_ssthresh, tp->rcv_wnd,
(u32)TCP_INIT_CWND * tp->advmss);
If tcp_rmem[1] is configured to very small values (such as 1),
sk->sk_rcvbuf is initialized to 1. Then tcp_full_space(sk), which
computes (sk->sk_rcvbuf * scaling_ratio) >> 8, truncates to 0.
This sets tp->window_clamp = 0, tp->rcv_ssthresh = 0, and
tp->rcvq_space.space = 0. Later, when data arrives and DRS is invoked,
tcp_rcvbuf_grow() divides by oldval == 0.
Back in 2015, commit b1cb59cf2e ("net: sysctl_net_core: check SNDBUF
and RCVBUF for min length") ensured that net.core.rmem_default and
net.core.rmem_max cannot be set below SOCK_MIN_RCVBUF. Similarly,
SO_RCVBUF setsockopt enforces max_t(int, val * 2, SOCK_MIN_RCVBUF).
However, net.ipv4.tcp_rmem still had .extra1 = SYSCTL_ONE, allowing
arbitrarily small values.
Because SOCK_MIN_RCVBUF depends on sizeof(struct sk_buff) and cacheline
alignment, its value varies across architectures and configuration options.
Using a fixed constant of 4096 ensures a predictable, architecture-
independent lower bound that is safely above SOCK_MIN_RCVBUF everywhere
and matches the documented 4K default.
Fix this by setting tcp_rmem.extra1 to 4096 and updating the documentation.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260912144848.3448026-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
devmem.py fails on the HW runners with:
CMD[remote]: dd if=/dev/zero bs=512 count=1 2>/dev/null | socat -b 512 \
-u - TCP6:[fd00:2::1]:50051,bind=[fd00:2::2]:50051,nodelay
STDERR: socat[41018] W bind(5, {AF=10 [fd00:2::2]:50051}, 28): \
Address already in use
ncdevmem installs a 5-tuple flow rule which matches the source port, so
socat has to bind it explicitly. The port comes from rand_port(), which
checks availability on the DUT - but we bind on the remote...
That said the failure rate seems to high to be random collisions
(~2% per sub-test). It's probably TIME_WAIT sockets on the remote,
run_rx_hds() alone creates 12 of them.
Set reuseaddr so a TIME_WAIT socket does not fail the bind. Collisions
with a live socket are still possible, we'll see if they are frequent
enough to care.
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260912203101.153688-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
brcmf_bss_connect_done() receives the firmware event in @e but discards it
on the failure path. Every failed connect is reported to cfg80211 as
WLAN_STATUS_AUTH_TIMEOUT (16), whatever the firmware actually said, so
userspace only ever sees:
wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
The all-zero BSSID comes from the same place: conn_params is memset to
zero and profile->bssid has not been filled in when the station never
associated.
status_code=16 therefore carries no information about the cause. It is not
an AP response and it does not mean "authentication timed out" - it is the
only failure value this driver can produce. This is a recurring source of
confusion: [1] has been open since 2023 with more than twenty follow-ups
and no explanation of the code, and covers BCM4345/6, BCM43430 and
CYW43455 across several kernel versions. It supersedes [2], filed against
the firmware repository a day earlier and closed in favour of it.
The firmware's own status (BRCMF_E_STATUS_*) is more specific - FAIL,
TIMEOUT, NO_NETWORKS, ABORT and so on - and it is already in hand. Log it
so the cause can be narrowed down without rebuilding the kernel.
bphy_err() is used rather than brcmf_dbg() or brcmf_info(): it is the form
the rest of this file uses, and of the three it is the only one that is
both visible in a distribution kernel and bounded. brcmf_dbg(CONN)
expands to no_printk() unless CONFIG_BRCMDBG is set, which is what makes
the reports in [1] and [2] impossible to act on - the people hitting this
run stock kernels. brcmf_info() expands to a plain pr_info() in a
non-debug build and is not rate limited, and wpa_supplicant retries the
association every few seconds, so it would flood the log. bphy_err() is
guarded by net_ratelimit() there, so a station retrying against an
unreachable AP prints at most a few lines per second.
All three fields are printed because only some of them are meaningful on
each path into the failure branch. brcmf_is_nonetwork() keys off @status,
so that is the useful field for a join that never associated - the case in
[1]. brcmf_is_linkdown() keys off @event_code and @flags and does not look
at @status at all, so @status can read 0 there; on those events it is
@reason which carries the 802.11 reason code, as the mapping in
brcmf_map_fw_linkdown_reason() shows. Printing the three together lets
the reader tell which path was taken instead of guessing from one number.
The status reported to cfg80211 is left alone; changing it would alter what
userspace sees.
[1] https://github.com/RPi-Distro/firmware-nonfree/issues/38
[2] https://github.com/raspberrypi/firmware/issues/1829
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ryohei Hashimoto <laurel.medalist12@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260913165526.4426-1-laurel.medalist12@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Advertise NL80211_EXT_FEATURE_FAST_ROAM_OFFLOAD only when firmware
reports FBT or OKC support. That lets userspace provide PMK material for
firmware fast roaming without enabling the path on devices that cannot
complete the offloaded roam.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-6-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Firmware can complete FT or OKC roaming before the driver reports the
connect or roam event to cfg80211. Detect those successful offloaded
cases when the profile uses firmware 1X or roaming offload and the
association request carries PMK cache state, FT is in use, or OKC is
enabled.
After reporting the connect or roam event, call cfg80211_port_authorized()
so nl80211 emits the dedicated NL80211_CMD_PORT_AUTHORIZED event instead
of reusing the reserved NL80211_ATTR_PORT_AUTHORIZED flag in CONNECT/ROAM
notifications.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Darren Li <hsin-hung.li@cypress.com>
Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-5-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
FT and OKC roaming offload need PMK material in firmware even when
the initial 802.1X exchange is handled by userspace. Add a roaming
firmware-supplicant profile state for those connections and allow PMK
configuration while firmware FT or OKC state is active.
Program the OKC PMK through the okc_info_pmk iovar before setting the
regular PMK when firmware reports OKC state. Only select the roaming
firmware-supplicant state when firmware advertises FBT or OKC support;
devices without those capabilities keep the profile in the userspace
supplicant state and do not issue roaming-offload specific iovars on
every connect.
For FT-PSK with firmware supplicant support, keep the profile in the
PSK firmware-supplicant state.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Darren Li <hsin-hung.li@cypress.com>
Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Co-developed-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Co-developed-by: Shelley Yang <shelley.yang@infineon.com>
Signed-off-by: Shelley Yang <shelley.yang@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-4-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some firmware advertises Fast BSS Transition and Opportunistic Key
Caching support through the firmware capability string. Track those
capabilities so later roaming offload handling can be enabled only
when firmware reports support.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-3-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers can offload FT or OKC roaming without necessarily advertising
full 802.1X 4-way handshake offload. Add an extended feature bit for
that capability and allow PMK configuration when it is present.
This gives userspace a way to provide PMK or PMK-R0 material needed by
fast roaming firmware implementations while keeping the existing 4-way
handshake offload capability unchanged.
Assisted-by: GitHub-Copilot-CLI:gpt-5.5
Signed-off-by: Carella Chen <carella.chen@infineon.com>
Signed-off-by: Jason Huang <jason.huang2@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260911065656.1269623-2-Jason.Huang2@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All four RTT attributes tell the reader to left-shift, which inflates the
value by 16 to 64 times, and the two usec ones say the result is in msecs.
The attributes carry srtt_us and mdev_us, which hold 3 and 2 fractional
bits. The shift to get the integer part would be a right shift.
Drop the instructions instead of turning them around. The number of
fractional bits is the part worth documenting, whether to shift, divide or
convert to a double is up to the caller.
While at it fix the acronym on the two variance attributes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260912234337.308298-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
TCP_FASTOPEN_COOKIE_MAX is the longest cookie we accept, not the shortest
one. Cookies are even sized, from 4 bytes up, and the ones Linux itself
generates are 8 bytes, so a 16 byte minimum declares all but the longest
cookie invalid. The reference policy kept under #if 0 in tcp_metrics.c
spells it as a maximum, which is what .len means for NLA_BINARY.
The IPv6 addresses err the other way. The policy uses
NLA_POLICY_EXACT_LEN() for both, so a request carrying a longer address is
rejected with -ERANGE, even though the spec advertises 16 bytes as a mere
minimum. Were the policy generated from this spec, as kernel-policy: global
promises, the check would turn into NLA_POLICY_MIN_LEN() and start
accepting over-long addresses, of which nla_get_in6_addr() would take the
first 16 bytes.
Nothing generated changes. fopen-cookie is reply-only so it never gets a
policy entry, and exact-len only feeds the policy (and the fixed size array
form, which needs a sub-type).
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260912234337.308298-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit a4d258036e ("tcp: Fix race in tcp_poll") added smp_rmb() in
tcp_poll() and smp_wmb() in tcp_reset() (now tcp_done_with_error())
to ensure that if tcp_poll() observed socket closure, it would also
observe sk->sk_err.
Currently, tcp_poll() unconditionally executes smp_rmb() at the end
of every invocation, which on weakly-ordered architectures such as ARM64
emits a memory barrier instruction (dmb ishld) on the poll fast path,
even for healthy, active sockets.
However, tcp_poll() only needs this barrier if socket closure has been
observed, to ensure that the error code set by tcp_done_with_error()
before socket closure is visible before returning EPOLLERR.
Move smp_rmb() inside the conditional block handling socket closure
(shutdown == SHUTDOWN_MASK || state == TCP_CLOSE). For healthy
connected sockets in epoll, tcp_poll() avoids the barrier entirely.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260913123224.762935-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Cover the new TCA_HHF_HH_FLOWS_LIMIT bound: values above 2*HH_FLOWS_CNT
(4294967295, 65536, 2049) are rejected with the configured limit left
untouched on both the change and the add path, the boundary value 2048 is
accepted (installed at 100 first so the boundary change is load-bearing),
and an add-time hh_limit 500 is preserved instead of being clobbered by
the default.
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Tested-by: hybris <hybris@mojatatu.ai>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/QDISC-B855.v1.20260911153152@mojatatu.com.2
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge
hh_flows_limit lets each new heavy-hitter flow pass the
hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size
kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory
growth.
Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the
hhf_init() default) and report the rejected value via extack. The
deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on
TCA_OPTIONS. Configs relying on hh_limit above the default were relying
on unbounded, unsafe behaviour and are not supported going forward.
hhf_init() also ran hhf_change() before setting the default
hh_flows_limit, so a user-supplied hh_limit at add time was clobbered
back to 2048. Set the default before hhf_change() so the configured
value sticks.
This is a follow-up to commit eb56a495f5 ("net/sched: hhf: clamp
quantum in change and init paths"), which bounded the quantum of the
same qdisc; the hh_flows_limit bound is the remaining unbounded knob of
that series' scope.
Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace;
tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the
value is echoed by tc qdisc show, unbounding heavy-hitter flow
allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048
instead of 500.
Fixes: 10239edf86 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc")
Cc: stable@vger.kernel.org
Reported-by: Sashiko (gemini) <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260822195509.112717-1-jhs@mojatatu.com
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Tested-by: hybris <hybris@mojatatu.ai>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/QDISC-B855.v1.20260911153152@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ip_tunnel_delete_net() iterates ip_tunnel devices whose link_net
is dying and queues them for destruction.
The devices may reside in different netns.
Let's use unregister_netdevice_queue_net() to support per-netns
device unregistration.
Even after ip_tunnel_delete_net() queues a cross-netns ip_tunnel
device, ip_tunnel_changelink(), ip_tunnel_dellink(), and
ip_tunnel_ctl() could be called concurrently for it (once RTNL is
removed). In such a case, __rtnl_net_unlock() will perform the
unregistration.
Also, ip_tunnel_ctl() needs to check check_net(t->net), otherwise
it could create a new dev in dying netns after ip_tunnel_delete_net().
In the example below, we can see the fallback tunnel device (gre0)
and the cross-netns device (gre1) are unregistered by different
processes:
# bpftrace -e '#include <linux/netdevice.h>
kprobe:ip_tunnel_uninit {
$dev = (struct net_device *)arg0;
printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
}
kprobe:ipgre_exit_rtnl {
printf("PID: %d%s\n", pid, kstack());
}' &
# ip netns add ns1
# ip netns add ns2
# ip -n ns1 link add name gre1 link-netns ns2 \
type gre local 192.168.0.1 remote 192.168.1.1
# ip netns del ns2
PID: 12
ipgre_exit_rtnl+5
ops_undo_list+702
cleanup_net+1122
process_scheduled_works+2538
...
PID: 12 | DEV: gre0 <------ fallback device (itn->fb_tunnel_dev).
ip_tunnel_uninit+5
unregister_netdevice_many_notify+7129
unregister_netdevice_many_net+1050
__rtnl_net_unlock+37
ops_undo_list+754
cleanup_net+1122
process_scheduled_works+2538
...
PID: 10 | DEV: gre1
ip_tunnel_uninit+5
unregister_netdevice_many_notify+7129
unregister_netdevice_many_net+1050
rtnl_net_work_func+136
process_scheduled_works+2538
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-8-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
struct ip_tunnel.net is the netns where encapsulated packets
flow into.
struct ip_tunnel is linked to ip_tunnel_net.tunnels[] of netns.
During netns dismantle or module unload, ip_tunnel_delete_net()
iterates the list and queues devices for destruction regardless
of the devices' netns.
Thus, once RTNL is removed, the list can be modified concurrently
from different netns due to device removal.
Let's protect it with per-netns mutex.
Note that dev_siocdevprivate() calls netdev_lock_ops() but
it must be NOP for tunnel devices to avoid AB-BA deadlock.
DEBUG_NET_WARN_ON_ONCE() is added to annotate the locking
explicitly.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-7-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The next patch will introduce per-netns mutex and acquire it
in ip_tunnel_newlink() and ip_tunnel_changelink().
To make the diff cleaner, let's unify the error paths.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-6-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
With the previous patch, itn->fb_tunnel_dev can be removed
via ->dellink().
However, ioctl(SIOCDELTUNNEL) still uses unregister_netdevice(),
which requires ip_tunnel_del() in ip_tunnel_uninit().
Let's use ip_tunnel_dellink() everywhere to remove ip_tunnel device
and remove ip_tunnel_del() in ip_tunnel_uninit().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-5-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ip_tunnel_dellink() ignores itn->fb_tunnel_dev, so the per-netns
fallback tunnel device cannot be removed by userspace.
This also makes default_device_exit_batch() impossible to remove
the device since it calls ->dellink().
So, ip_tunnel_delete_net() has to iterate devices in the dying netns
and call unregister_netdevice_queue() directly.
But then, this duplicates ip_tunnel_del() in ip_tunnel_dellink()
and ip_tunnel_uninit().
Let's set itn->fb_tunnel_dev to NULL in ip_tunnel_delete_net() and
remove for_each_netdev_safe() in ip_tunnel_delete_net().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-3-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ipmr.c uses unregister_netdevice() to remove DVMRP tunnel devices
created in ipmr_new_tunnel().
This is fine because currently ip_tunnel_uninit() also calls
ip_tunnel_del() to unlink the device from the hash table.
However, we will move ip_tunnel_del() from ip_tunnel_uninit() to
ip_tunnel_dellink().
Removing DVMRP tunnel devices by unregister_netdevice() would leave
them in the hash table.
Let's call ->dellink for DVMRP tunnel devices.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-2-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This is a follow-up of one of sashiko's pre-existing bug reports.
br_mst_set_state() calls switchdev_port_attr_set() for nonzero MSTIs
while holding rcu_read_lock() which invokes the blocking switchdev
notifier chain and may sleep. Nonzero MSTI changes come from netlink
with rtnl held. Move the switchdev call before entering the rcu section and
assert that rtnl is held.
The call cannot be deferred because netlink needs its error and extack.
Also DSA reads the old bridge MST state during the callback and checks it.
A deferred callback will be late and will see the updated state.
Fixes: 3a7c1661ae ("net: bridge: mst: fix vlan use-after-free")
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260911105021.1385934-1-razor@blackwall.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Wei Fang says:
====================
net: enetc: SR-IOV improvements and ENETC v4 VF support
This series enhances SR-IOV support for ENETC v1 and adds VF support
for ENETC v4. For ENETC v1, the trusted VF management and per-VF
configuration query via ndo_get_vf_config() are added. For ENETC v4,
preliminary VF support is introduced for i.MX94 and i.MX95 platforms.
On the PF side, the series introduces trust level management and MAC
address assignment for VFs, and implements ndo_get_vf_config() so that
userspace tools such as 'ip link show' can query the current per-VF
configuration. The PSI-to-VSI messaging infrastructure is extended to
handle link status and link speed queries from VFs, enabling DPDK-owned
VFs to obtain accurate link information from the PF.
On the VF side, MAC address filtering is implemented via the VSI-to-PSI
mailbox, supporting both unicast/multicast hash filters and promiscuous
mode control. Since the ndo_set_rx_mode callback is invoked with BH
disabled and is incompatible with the mailbox polling path,
ndo_set_rx_mode_async is used instead. Link status notifications are also
supported: the VF registers with the PF and receives PSI-to-VSI messages
on every PF link transition, keeping the VF carrier state in sync without
polling.
VF Function Level Reset is handled explicitly to restore the PF-managed
MAC promiscuous policy after each reset, since the hardware default after
FLR enables promiscuous mode regardless of the policy set by the PF
driver.
Several preparatory refactors are included to share infrastructure
between the PF and VF drivers, such as moving msg_task and mac_filter
from struct enetc_pf into the common struct enetc_si.
====================
Link: https://patch.msgid.link/20260909100733.1139689-1-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Without ndo_get_vf_config(), userspace tools such as 'ip link show'
cannot query the current VF configuration from the PF.
To support this, extend struct enetc_vf_state to track the per-VF VLAN
and spoofchk settings, and update the corresponding setter callbacks to
persist their state when the hardware is programmed.
enetc_pf_get_vf_config() reads back the persisted state and reports MAC
address, VLAN parameters, spoofchk, and trust state through struct
ifla_vf_info.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-16-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Let ENETC v4 VFs track PF link status through the PSI-to-VSI messaging
channel. Add two enetc_si_ops hooks, vf_reg_link_status_notifier and
vf_unreg_link_status_notifier, populated only in enetc4_vsi_ops; rev1
hardware is unaffected.
A dedicated MSI-X vector on the VF handles incoming PSI-to-VSI messages.
Its handler schedules a work item on an ordered workqueue that reads the
notification via VSIMSGRR, updates the carrier state and sets congestion
mode from the PF TX PAUSE state in the message. Reading VSIMSGRR also
acknowledges the PF so it can send the next message. The workqueue is
set up in enetc_vf_probe() and torn down in enetc_vf_remove().
On a VF, enetc_phylink_connect() registers the notifier with the PF and
enetc_close() unregisters it. On registration the PF immediately sends
the current link status and then broadcasts every later transition; if
registration fails, fall back to the LS1028A behaviour and assert
carrier unconditionally. Register the notifier only after the Tx/Rx
resources are allocated in enetc_open(), because once registered the PF
may queue si->msg_task via a link-up message. An error unwind cannot
drain that work item, since enetc_open() and the work item both take the
RTNL lock and waiting would deadlock; and as __LINK_STATE_START is set
before ndo_open() runs, netif_running() stays true during the unwind, so
the queued work could still call netif_carrier_on() and leave carrier
'on' after a failed open.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-15-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
An ENETC VF sends MAC filter changes to the PF over the VSI mailbox,
whose send path may sleep for up to 200ms waiting for completion. Since
the legacy ndo_set_rx_mode runs in atomic context, use
ndo_set_rx_mode_async instead, which runs from a workqueue under
rtnl_lock and receives pre-snapshotted unicast and multicast address
lists from the core.
Add two helpers built on the VSI mailbox:
- enetc_vf_set_mac_promisc() sends a promiscuous mode message for a
given filter type (unicast, multicast or both).
- enetc_vf_set_mac_hash_filter() sends the 64-bit MAC hash filter table,
built from the snapshotted address lists.
The callback picks the configuration from the current netdev flags:
- IFF_PROMISC: enable promiscuous mode for both unicast and multicast.
- IFF_ALLMULTI: enable multicast promiscuous mode, disable unicast
promiscuous mode and apply a unicast hash filter.
- otherwise: disable promiscuous mode and apply both unicast and
multicast hash filters.
These requests are subject to the PF-side ENETC_VF_FLAG_TRUSTED check.
For an untrusted VF (the default) the PF denies promiscuous mode and
unicast hash filtering, so only the multicast hash filter is applied,
limited to ENETC_VF_MC_HASH_BITS_MAX buckets. Mark a VF trusted via
'ip link set <pf> vf N trust on' for the full behaviour.
Set IFF_UNICAST_FLT for ENETC v4 VFs so the stack does not needlessly
fall back to full promiscuous mode; whether a unicast hash filter is
actually programmed still depends on the PF trust policy.
Since a denied request always fails, map -EOPNOTSUPP, -EACCES and -EPERM
to 0 so the core does not retry an operation that can never succeed.
ENETC v1 (LS1028A) does not support VF-to-PF MAC filter messaging and
keeps using the legacy ndev ops.
On VF removal, disable promiscuous mode and clear the MAC filters, so
that stale configuration does not persist if the VF is later bound to
another driver.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-14-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add VF support for the i.MX94 and i.MX95 platforms. Compared to the
LS1028A ENETC, the VF device ID is updated to 0xef00, so add it to the
VF driver's PCI device ID table. Also add the enetc4 SI ops and VF
driver data, and wire up .sriov_configure for the enetc4 PF driver so
that VFs can be created and torn down on these SoCs.
The number of VFs is not decided by the driver. It is determined by
each ENETC instance's SR-IOV hardware capability, reported through the
PCI SR-IOV TotalVFs field and configured by the SoC integration and
device tree. The driver derives it from pci_sriov_get_totalvfs() in
enetc_init_sriov_resources(); an instance that advertises zero VFs
simply cannot enable SR-IOV. So there is no driver-side revision or
device-ID check bounding the VF count.
For reference, the per-instance VF capability on these SoCs is:
- i.MX95 (v4.1): each ENETC instance supports 2 VFs.
- i.MX94 (v4.3) has two kinds of ENETC:
- standalone ENETC, the same instance type as on i.MX95, but on
i.MX94 it advertises no VFs;
- internal ENETC connected to the CPU port of the NETC switch,
which supports 3 VFs.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-13-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On ENETC v4, when VF performs a PCI FLR, it resets PSIPMMR[SIn_MAC_UP]
and PSIPMMR[SIn_MAC_MP] bits, which control the unicast and multicast
promiscuous mode for the corresponding SI. The reset (default) value of
these bits enables promiscuous mode, meaning that after a VF FLR, the
SI is left in promiscuous mode regardless of the configuration set by
the PF driver prior to the reset.
This is a potential security vulnerability: a malicious VM could
deliberately trigger a VF FLR to force promiscuous mode on its SI,
allowing it to capture network traffic not destined for that VF.
To mitigate this, make the following changes:
- Add ENETC_VF_FLAG_UC_PROMISC and ENETC_VF_FLAG_MC_PROMISC to
enetc_vf_flags to track the PF-managed promiscuous mode state for each
VF.
- Update enetc_msg_set_vf_mac_promisc_mode() to keep these flags in sync
whenever a VF requests a promiscuous mode change via messaging.
- Update enetc_pf_set_vf_trust() to clear both promisc flags when a VF
is untrusted, so that a subsequent FLR cannot restore promiscuous mode
that the PF has already revoked.
- Add a vf_flr_handler callback to enetc_pf_ops. The ENETC v4
implementation re-applies the tracked UC/MC promiscuous mode settings
to the hardware after each FLR, ensuring the hardware state matches
the PF-managed policy rather than the insecure reset default.
- Add enetc_vf_flr_handler() in enetc_msg.c to detect FLR events via the
PSIIDR register and dispatch to the vf_flr_handler callback. Invoke it
at the start of enetc_msg_task() before processing VF messages.
- Enable FLR interrupts in PSIIER only when a vf_flr_handler callback is
registered, keeping ENETC v1 behavior unchanged.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-12-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The PSIIER register controls two categories of interrupt sources:
message-receive (MR) interrupts, which fire when a VF sends a mailbox
message to the PSI, and VF FLR interrupts, which fire when a VF
performs a Function Level Reset.
The current helpers enetc_msg_enable_mr_int() and
enetc_msg_disable_mr_int() use a read-modify-write sequence to update
only the MR bits in PSIIER, intending to preserve any other bits that
may be set. However, VF FLR interrupt support is not yet implemented,
so PSIIER only ever holds MR interrupt bits at this point. The
read-modify-write is therefore unnecessary overhead.
Simplify enetc_disable_psiier_interrupts() to write 0 directly to
PSIIER, disabling all interrupt sources at once, and simplify
enetc_enable_psiier_interrupts() to write the MR mask directly without
reading the current register value first.
Rename both helpers from the MR-specific names to names that reflect
their true scope, i.e. managing all PSIIER interrupt sources rather
than just the MR bits. This prepares the code for a future patch that
adds VF FLR interrupt support, at which point
enetc_enable_psiier_interrupts() will be extended to also set the
corresponding FLR bits.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-11-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ENETC v4 VF hardware supports MAC address filtering, but the underlying
resources (the PSIPMMR register and per-SI hash filter tables) are owned
by the PF. Add VSI-to-PSI mailbox messages so a VF can request MAC
filter configuration from the PF, using two new command IDs under the
existing MAC filter class (0x20):
1. ENETC_MSG_SET_MAC_HASH_TABLE (cmd_id 3): program the unicast and/or
multicast MAC hash filter table. Unicast filtering is only allowed for
a trusted VF, since it could be used to receive traffic destined for
other SIs. Multicast filtering is allowed even for an untrusted VF,
but limited to ENETC_VF_MC_HASH_BITS_MAX (8) buckets, enough for basic
operation such as IPv6 neighbor discovery and mDNS; a trusted VF may
use all 64 buckets.
2. ENETC_MSG_SET_MAC_PROMISC_MODE (cmd_id 5): enable or disable unicast/
multicast promiscuous mode, and optionally flush the hash filter
table. Enabling promiscuous mode requires a trusted VF; flushing the
table alone does not.
The PSIPMMR register is a shared resource accessed by both
enetc4_pf_set_rx_mode() and the VF message handler via a non-atomic
read-modify-write, so protect these accesses with si->gen_lock to avoid
lost updates on SMP.
When a VF loses trusted status via ndo_set_vf_trust(), clear its unicast
hash filter and disable promiscuous mode so it cannot receive traffic
beyond its allowed scope.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-10-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The mac_filter array currently resides in struct enetc_pf and is used to
track unicast and multicast MAC address filters for the PF. Since struct
enetc_si is the common structure shared between the PF and VF drivers,
move mac_filter into struct enetc_si to prepare for MAC filter support
in the VF driver.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-9-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move enetc_pf_set_vf_mac() into enetc-pf-common driver as a generic
interface for both ENETC v1 and v4 PF driver to use.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-7-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Prepare for moving enetc_pf_set_vf_mac() into the enetc-pf-common driver
by replacing enetc_pf_set_primary_mac_addr() with enetc_set_si_hw_addr().
This makes the VF primary MAC configuration path generic and allows
future enetc v4 PF driver to reuse the same interface.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-6-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When a VF is driven by DPDK, its user space application needs accurate
link speed information to make correct forwarding and configuration
decisions. Add link speed message support so the PF replies with the
current link speed when it receives a get-link-speed message from a VF.
Use a new message class 0x81 (ENETC_MSG_CLASS_ID_LINK_SPEED). The
PSI-to-VSI message is 16 bits: the high 8 bits are the class ID and the
low 8 bits are the speed code, so up to 255 speed values are supported
(ENETC_MSG_SPEED_MAX = 0xff). Instead of enumerating every speed above
5Gbps, use a formula so future high speeds need no enum or switch
changes:
speed_code = (link_speed - 5000) / 1000 + ENETC_MSG_SPEED_5G
The speed is read via phylink_ethtool_ksettings_get() rather than the
speed passed to the mac_link_up() callback. When the MAC has a PCS
layer, mac_link_up() reports the PCS link speed, which may differ from
the external PHY link speed; phylink_ethtool_ksettings_get() returns the
actual external link speed.
Unlike the link status message (class 0x80), the get-link-speed message
is only permitted for trusted VFs. Reading the speed requires the PF to
take rtnl_lock(), so an untrusted VF spamming this query could cause
rtnl_lock contention and starve routine network configuration on the
host. An untrusted VF therefore receives a permission-deny response; a
VF can be marked trusted via 'ip link set <pf> vf N trust on'.
Note that link speed change notification is not supported yet.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-5-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a mechanism for VFs to learn the PF link state, using message class
0x80 (ENETC_MSG_CLASS_ID_LINK_STATUS) with three VSI-to-PSI commands:
1. ENETC_MSG_GET_CURRENT_LINK_STATUS: the VF queries the current PF link
status synchronously. This is intended for DPDK-owned VFs and is not
used by the Linux VF driver.
2. ENETC_MSG_REGISTER_LINK_CHANGE_NOTIFIER: the VF registers for link
change notification. The PF then reports the current link status and
notifies the VF on every later link change.
3. ENETC_MSG_UNREGISTER_LINK_CHANGE_NOTIFIER: the VF unregisters.
The PSI-to-VSI notification is 16 bits wide: the upper 8 bits carry the
class ID and the lower 8 bits the class code. Bit 0 of the class code
indicates the link state (1 = down, 0 = up) and bit 1 indicates whether
TX PAUSE is enabled on the PF. The TX PAUSE state is included so a VF
can decide whether to enable congestion mode on its RX BD rings, which
only works when the PF can actually send PAUSE frames.
Notifications are sent through the ENETC_PSIMSGSR register. Since sending
a notification may take a long time, as it polls the per-VF message
status bits, the actual transmission is deferred to an ordered workqueue
rather than running in the phylink link_up/link_down callbacks. The
link_status_ms_mask tracks the VFs registered for notification and is
cleared when SR-IOV is disabled.
Export enetc_pf_notify_vf_link_up() and enetc_pf_notify_vf_link_down()
for the PF phylink callbacks. Through this, VFs can perceive the link
status and report it to upper layers such as the kernel network stack,
containers and virtual machines.
Currently only the ENETC v4 driver supports this feature; v1 does not.
And the SR-IOV feature of ENETC v4 will be added by subsequent patches.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-4-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
