One of the assumptions of libie_cp and pre-refactor idpf control queue
handling is such that all Rx processing is handled by a single task, which
is to be cancelled before the mailbox destruction. Aside from cancelling,
it is also important to make sure that idpf_intr_rel() never reschedules
it afterwards.
In order to comply, in the init path, do the first queueing of mbx_task in
idpf_init_dflt_mbx(), and in deinit and reset, always cancel the task in
idpf_deinit_dflt_mbx(), in every single flow call idpf_mb_intr_rel_irq()
beforehand.
Reviewed-by: Emil Tantilov <emil.s.tantilov@intel.com>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Support to initialize and configure controlqs, and manage their
transactions was introduced in libie. As part of it, most of the existing
controlq structures are renamed and modified. Use those APIs in idpf and
make all the necessary changes.
Previously for the send and receive virtchnl messages, there used to be a
memcpy involved in controlq code to copy the buffer info passed by the send
function into the controlq specific buffers. There was no restriction to
use automatic memory in that case. The new implementation in libie removed
copying of the send buffer info and introduced DMA mapping of the send
buffer itself. To accommodate it, use dynamic memory for the larger send
buffers. For smaller ones (<= 128 bytes) libie still can copy them into the
pre-allocated message memory. Those changes result in a pretty big diff,
but the changes are fairly trivial and localized.
In case of receive, idpf receives a page pool buffer allocated by the libie
and care should be taken to release it after use in the idpf.
idpf_idc_rdma_vc_send_sync() no longer truncates oversized responses or
zeroes *recv_len on error, but this was confirmed to have no practical
impact for any existing callers.
This refactoring introduces roughly additional 40KB of module storage used
for systems that only run idpf, so idpf + libie_cp + libie_pci takes about
7% more storage than just idpf before refactoring.
We now pre-allocate small TX buffers, so that does increase the memory
usage, but reduces the need to allocate. This results in additional 256 *
128B of memory permanently used, increasing the worst-case memory usage by
32KB but our ctlq RX buffers need to be of size 4096B anyway (not changed
by the patchset), so this is hardly noticeable.
As for the timings, the fact that we are mostly limited by the HW response
time which is far from instant, is not changed by this refactor.
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Use libie_pci init and MMIO APIs where possible, struct idpf_hw cannot be
deleted for now as it also houses control queues that will be refactored
later.
Memory regions are added and removed in layers, so e.g. mailbox and
rstat are added first and not removed until teardown. libie_pci stores the
regions in the order of addition, so no new locks/checks are required,
despite the data structure change.
Use libie_cp header for libie_ctlq_ctx that contains mmio info from the
start in order to not increase the diff later.
Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
idpf_send_get_set_rss_lut_msg() and idpf_send_get_set_rss_key_msg() do not
handle the get=true path properly. Response validation is insufficient,
memcpy size is wrong, LE-to-CPU conversion is missing. Fortunately, those
functions are never used with get=true. Given how broken this dead code is,
it is unlikely to be useful in the future.
Rename idpf_send_get_set_rss_lut_msg() to idpf_send_set_rss_lut_msg(),
idpf_send_get_set_rss_key_msg() to idpf_send_set_rss_key_msg(), remove the
get parameter and remove all get=true cases from the function.
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
While sending a create vport message to the device control plane, a create
vport virtchnl message is prepared with all the required info to initialize
the vport. This info is stored in the adapter struct but never used
thereafter. So, remove the said field.
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Small send control queue message buffers are managed and reused by
libie itself, bigger send buffers are consumed. All are tracked with
the unique transaction (Xn) ids until they receive response or time out.
Responses can be received out of order, therefore transactions are stored
in an array and tracked though a bitmap. Rx buffers utilize page_pool.
Pre-allocated DMA memory is used where possible. It reduces the driver
overhead in handling memory allocation/free and message timeouts.
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Phani R Burra <phani.r.burra@intel.com>
Co-developed-by: Victor Raj <victor.raj@intel.com>
Signed-off-by: Victor Raj <victor.raj@intel.com>
Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Tested-by: Bharath R <bharath.r@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Libie will now support control queue setup and configuration APIs. These
are mainly used for mailbox communication between drivers and control
plane.
Make use of the libeth_rx page pool support for managing controlq buffers.
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Phani R Burra <phani.r.burra@intel.com>
Co-developed-by: Victor Raj <victor.raj@intel.com>
Signed-off-by: Victor Raj <victor.raj@intel.com>
Co-developed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Tested-by: Bharath R <bharath.r@intel.com>
Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Control queues can utilize libeth_rx fill queues, despite working outside
of NAPI context. The only problem is standard fill queues requiring NAPI
that provides them with the device pointer.
Introduce a way to provide the device directly without using NAPI.
Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Tested-by: Bharath R <bharath.r@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
idpf and ixd drivers serve different PCI functions on the same device,
therefore their PCI configuration flow is very similar.
Add support functions for idpf and ixd to configure PCI functionality and
access MMIO space. Add a mapping list which can be traversed by a driver,
e.g. to pass certain I/O mappings to the auxbus devices. Such list is also
traversed by the libie_pci_get_mmio_addr() helper, which allows for easier
memory access.
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Phani R Burra <phani.r.burra@intel.com>
Co-developed-by: Victor Raj <victor.raj@intel.com>
Signed-off-by: Victor Raj <victor.raj@intel.com>
Co-developed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
Tested-by: Bharath R <bharath.r@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
virtchnl2 headers will be used by both idpf and ixd drivers, so they have
to be moved to an include directory. On top of that, it would be useful to
place all iavf headers together with other intel networking headers.
Move abovementioned intel header files into 'include/linux/net/intel'.
While at it, remove the self-include from iavf_types.h.
Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: Victor Raj <victor.raj@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Matthieu Baerts says:
====================
mptcp: out-of-order queue pruning
Under memory pressure, a pruning of the MPTCP-level OoO queue might be
required as last resort, to avoid too long recoveries, or even stalls.
Geliang and Gang managed to reproduce this behaviour, and Paolo
improved the situation thanks to the following patches:
- Patches 1-3: improve the MPTCP-level retransmission schema to make
recoveries from memory pressure/after MPTCP-level drop significantly
faster.
- Patches 4-5: make the admission check way stricter for incoming
packets exceeding the memory limits, with some exceptions for fallback
sockets.
- Patches 6-7: implement OoO queue pruning for MPTCP.
====================
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-0-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When moving incoming skbs in the msk receive queue and the latter
is above limits, prune it as needed quite alike what TCP is doing
at the subflow level. The main difference relies in the stop condition:
since MPTCP does not perform collapsing, it's better off dropping the
bare minimum to fit the (newer) incoming packet.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Tested-by: Gang Yan <yangang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-7-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alike TCP, MPTCP handles in-sequence packets and partially overlapping
ones in a very similar way: we can use the same path to handle both,
avoiding some code duplication.
This will also make the next patch simpler.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-6-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently a wild producer could keep the backlog flushing operation
spinning for an unbound time.
Since the previous patch, the amount of data present in the backlog is
hard-limited. Move the backlog len update at the end of the flush loop to
prevent it spinning forever.
Also, no need to splice back the remaining skbs list into the backlog, as
such list is always empty after each backlog processing loop.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-5-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently the enforcement of the rcvbuf constraint is implemented
when moving the skbs into the msk receive or OoO queue, keeping the
incoming skbs in the subflow queue when over limits.
Under significant memory pressure the above can cause permanent data
transfer stalls, as the skb needed to make forward progress can be
stuck in a subflow queue.
Over memory limits, drop the incoming skb, relying on MPTCP-level
retransmissions.
Note that fallback socket must perform the limit before the skb reaches
the subflow-level queue, as dropping an in-sequence already acked skb
would break the stream.
This is not a complete fix for the stall issue, as the drop strategy
needs refinements that will come in the next patches.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-4-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently the MPTCP core enforces that when MPTCP-level retrans timer
fires, at most a single dfrag is retransmitted. In some corner-cases, it
may be necessary to retransmit multiple dfrags, and the MPTCP socket
will need to wait multiple retrans timeout to accomplish that.
Remove the mentioned constraint, allowing to transmit multiple dfrags
per retrans period, as long as the scheduler keeps selecting subflows
for retransmissions and pending data is available in the rtx queue.
The default scheduler will transmit a dfrag per available subflow.
Tested-by: Gang Yan <yangang@kylinos.cn>
Tested-by: Geliang Tang <geliang@kernel.org>
Acked-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-3-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This allow separating the stale logic invocation and the retrans
scheduler, and will simplify the next patch.
It's also a cleaner design as the retrans scheduler has currently
too many side effects. As a possible downside, the retrans work will
now traverse the subflows list additional times; that does not matter
much, as this is slowpath.
While at it, pick more accurate names for the involved helpers and
explicitly note that the per subflow stale data is under msk socket
lock protection.
The scheduler and the stale logic may observe different subflow
statues, as no subflow lock is acquired. This is intentional and not
harmful, worst case leading to slower retransmissions.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-2-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This is a cleanup in order to make the next patch simpler.
No functional change intended.
Tested-by: Gang Yan <yangang@kylinos.cn>
Tested-by: Geliang Tang <geliang@kernel.org>
Acked-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260807-net-next-mptcp-oooq-pruning-v3-1-dbc1eb853cc3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The devlink port_split test has limited applicability.
NICs (as opposed to switches) require at least a re-probe
to apply the split configuration.
On top of that the test is not compatible with our driver env,
it just splits all ports on the system, not only what NETIF
points at.
Long term we may want to add some indication in devlink whether
the port splitting is runtime (cmode of sorts), and fix the
test to follow driver env. But since no (known) NIC driver can
support runtime anyway let's just hide the test from the selftest
framework by moving it to extra files.
Having this test randomly break unrelated NICs within the DUT
makes people implement allow-lists for ksft, which then means
their setups don't run new tests. It's very useful during test
review to see whether the test works across all the runners.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260811004645.1072124-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The patch mentioned in Fixes missed one main point of implementing
proper PTM support. To make it fully operational it has to be explicitly
enabled. Add missing call in probe callback and disable it in teardown
callback.
Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Link: https://patch.msgid.link/20260806201849.3161402-1-vadim.fedorenko@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Marcelo Mendes Spessoto Junior says:
====================
net: selftests: adjustments to ipv6_flowlabel_mgr
The ipv6_flowlabel_mgr test file was lacking coverage for the
IPV6_FL_A_RENEW action, and the IPV6_FL_F_REMOTE and IPV6_FL_F_REFLECT
flags. The first two patches from this set aim to add a proper test
case for RENEW and REMOTE.
The third patch was added to insert network namespace creation inside
the test suite, instead of relying on external wrapper scripts. This
change conforms to other net test implementations, such as
tools/testing/selftests/net/icmp_rfc4884.c, and it is important for
the fourth and fifth patches.
The fourth patch adds the IPV6_FL_F_REFLECT test.
The fifth patch proposes the adoption of "kselftest_harness.h" helpers,
improving code readability and conforming to the implementation of the most
recent selftests.
====================
Link: https://patch.msgid.link/20260807220942.421382-1-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The kselftest_harness.h file contains modern helpers to build tests
for kselftest. Dropping the custom test helpers in ipv6_flowlabel_mgr
in favor of the harness makes tests more legible and conforms to the
structure of the latest selftests. It also enforces the TAP standard.
Another change made to the structure of the ipv6_flowlabel_mgr test
file was the removal of parse_opts. The supported opts were already
unused: the binary is listed in TEST_GEN_FILES, and is driven solely
by ipv6_flowlabel.sh via "./ipv6_flowlabel_mgr", which never passed -l
or -v. Dropping the -l gate means the two checks it previously guarded
(each with a 13-second sleep, ~26 seconds total) are now
unconditionally enabled on every run instead of never running at all.
The TH_LOG calls and code comments now cover the information that the
removed, custom -v flag used to print.
Finally, FIXTURE_SETUP(flowlabel) ensures each test gets its own
isolated network namespace. The previously added setup() helper was
dropped to conform to the netns setup pattern used in icmp_rfc4884.c.
disable_flowlabel_consistency() was moved next to reflect_flag, the
only test that calls it, and now uses SKIP() instead of an ad hoc
[INFO] message when the sysctl cannot be disabled.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Link: https://patch.msgid.link/20260807220942.421382-6-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
According to the source code, flowlabel_consistency must be
deactivated for the IPV6_FL_F_REFLECT flag to work. Since
ipv6_flowlabel_mgr now runs in its own network namespace, do this
directly from the test binary. Attempt to disable
net.ipv6.flowlabel_consistency and skip the reflect test if that
fails. A disabled flowlabel_consistency does not affect the remaining
features being tested on the file, and failing to disable is not fatal
and skips the reflect test only.
The previously defined tcp_listen and tcp_connect helpers were reused,
since the connection flow required for REFLECT validation is very
similar to REMOTE.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Link: https://patch.msgid.link/20260807220942.421382-5-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Have ipv6_flowlabel_mgr create and configure its own network
namespace (unshare(CLONE_NEWNET) + bring up lo), the same way
ipv6_fragmentation.c and icmp_rfc4884.c already do, instead of
relying on the in_netns.sh wrapper script.
The setup can then be reused across tests through fixtures and
provide isolated network environments for each test in the case
of a future adoption of kselftest_harness.
It also avoids the leak of modifications to the netns in case the
user runs the test file directly, outside the wrapper and without
the in_netns.sh file.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Link: https://patch.msgid.link/20260807220942.421382-4-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This flag retrieves the flow label seen by the socket at connection
setup via a getsockopt query. Therefore, the validation of this flag
requires a brief connection setup (source code for flow label shows
it must be TCP).
The simple TCP connection logic was wrapped inside two simple helpers,
because there are other uncovered features of flow label mgr that
could benefit from it (such as IPV6_FL_F_REFLECT).
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Link: https://patch.msgid.link/20260807220942.421382-3-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
RENEW was the only flow label action without selftests coverage.
Assert renew returns no error on correct usage and fails for labels
that do not exist.
This test is based on the previously implemented EXCL share test,
which demonstrates that a new flow label with the same value can be
created after the linger period. Renew is used here to show that a
flow label can last longer and block a new flow label creation after
the previous linger time. This test, however, demands sleep during
execution, and should be placed as a conditional test under the -l
option.
The addition of the expect_fail_errno helper is necessary to assert
the corresponding error when a function can fail in multiple ways.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Link: https://patch.msgid.link/20260807220942.421382-2-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tariq Toukan says:
====================
devlink: add generic device max_sfs parameter
This series by Nikolay introduces a new generic devlink device
parameter, max_sfs, to control the number of light-weight NIC
subfunctions (SFs) that can be created on a device.
The first patch adds the generic devlink parameter and infrastructure
support.
The second patch implements support for the parameter in the mlx5
driver.
With this addition, users can enable or disable SF creation directly via
devlink, without relying on external vendor-specific tools.
====================
Link: https://patch.msgid.link/20260806073037.3001886-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Implement max_sfs generic parameter to allow users to control the total
light-weight NIC subfunctions that can be created using devlink instead
of external vendor tools. A value of 0 will effectively disable creation
of new subfunction devices. A warning is sent to user-space via extack
(returning extack without error code is interpreted as a warning by
user-space tools). The maximum value is capped at U16_MAX.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260806073037.3001886-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a new generic devlink device parameter (max_sfs) to control if and
how many light-weight NIC subfunctions can be created. Subfunctions are
a light-weight network functions backed by an underlying PCI function.
Their lifecycle can already be managed by devlink, but currently users
cannot enable them in the device. They can be enabled/disabled only via
external vendor tools. This parameter allows subfunctions to be enabled
(>0) or disabled (0) via devlink. A subsequent patch will add support
for max_sfs to the mlx5 driver.
Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260806073037.3001886-2-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
List all the files of the QCA8K DSA Switch driver and add myself as
maintainer.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260810143740.652804-1-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tung Quang Nguyen has been working as the de facto TIPC maintainer
for a few years now. Make sure the MAINTAINERS file reflects this
reality. Dealing with the flood of AI patches is a significant
effort, and Tung's work and responsiveness is exemplary.
Link: https://patch.msgid.link/20260810180148.680425-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jijie Shao says:
====================
net: hns3: some cleanups for hns3 driver
Patch 1 sets msg->desc to NULL after kfree to avoid leaving a
dangling pointer in a struct that is reused across loop iterations.
Patch 2 adds the missing const qualifier to the reg parameter of
hclge_log_error(), which is never modified within the function.
Patch 3 uses the txqueue parameter passed by the ndo_tx_timeout
callback directly, instead of iterating all tx queues to find the
timed out one.
====================
Link: https://patch.msgid.link/20260807095435.2959246-1-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The ndo_tx_timeout callback already provides the timed out txqueue
index. Use it directly instead of iterating all tx queues to find
the timed out one.
Use h->kinfo.num_tqps for the bounds check instead of
ndev->num_tx_queues, as the ring array is allocated with num_tqps
entries and num_tx_queues may be larger. This issue has not been
encountered in practice, so it is folded into this cleanup rather
than tracked as a separate bugfix.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260807095435.2959246-4-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The reg parameter of hclge_log_error() is never modified within the
function, but is declared as 'char *'. Callers pass const strings,
causing a compiler warning about discarding the 'const' qualifier.
Add the missing const to fix the warning.
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260807095435.2959246-3-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In hclge_query_reg_info(), msg->desc is freed by kfree(), but the
caller continues to use msg across loop iterations. Set msg->desc
to NULL to avoid leaving a dangling pointer in the reused struct.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260807095435.2959246-2-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Ivan Vecera says:
====================
dpll: use pin owner's dpll ref for pin-level set callbacks
Pin-level attributes (frequency, phase adjust, embedded sync, reference
sync) are properties of the pin itself. The get callbacks already use
only the pin owner's DPLL reference, but the set callbacks iterate over
all registered DPLL devices, resulting in redundant HW writes for
drivers that share a pin across multiple DPLLs.
This series simplifies the set side to match the get side: call the set
callback only through the owner's reference.
Patch 1 prepares the zl3073x driver whose ref_sync_set callback had
per-channel behavior (setting priority on a single DPLL channel). It now
iterates all channels internally so it remains correct when invoked only
once.
Patch 2 drops the xa_for_each loops from dpll_pin_freq_set(),
dpll_pin_esync_set(), dpll_pin_ref_sync_state_set() and
dpll_pin_phase_adj_set(), along with the rollback logic and the per-ref
-EOPNOTSUPP validation scan. The dpll.rst documentation is updated to
reflect the new behavior.
====================
Link: https://patch.msgid.link/20260807095926.386923-1-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Pin-level attributes (frequency, phase adjust, embedded sync, reference
sync) are properties of the pin itself, not of a particular DPLL device.
The get callbacks already use only the pin owner's DPLL reference
(via dpll_pin_own_dpll_ref_first()), but the set callbacks iterate over
all registered DPLL references and invoke the set operation on each one.
This is redundant because a pin is a single physical entity - setting
its frequency or phase adjust once through the owner's ops is sufficient.
Calling set on every registered DPLL just results in duplicate HW writes
for drivers that share a pin across multiple DPLL devices (e.g. ice
registers each input pin with both the EEC and PPS DPLL, zl3073x
registers input pins with every DPLL channel).
Simplify dpll_pin_freq_set(), dpll_pin_esync_set(),
dpll_pin_ref_sync_state_set() and dpll_pin_phase_adj_set() to call the
set callback only through the owner's DPLL reference, matching the
existing get-side behavior. This removes the xa_for_each iteration
loops, the now-unnecessary rollback logic, and several local variables.
The -EOPNOTSUPP validation loop, which checked ops support across all
owner-matching references, is replaced with a direct check on the
single owner reference returned by dpll_pin_own_dpll_ref_first().
The documentation in dpll.rst is updated to reflect that pin-level
attributes are set through the pin owner's dpll reference only.
No existing driver is affected:
- ptp_ocp and mlx5 register each pin with a single DPLL.
- ice registers input pins with two DPLLs (EEC and PPS) using
identical ops and pin_priv; the set callbacks address the HW by
pin index, not by DPLL, so the second call was a no-op.
- zl3073x registers input pins with every DPLL channel; the set
callbacks address HW by pin/ref ID regardless of DPLL. The
ref_sync_set callback was the only one with per-channel behavior,
addressed by the preceding patch.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://patch.msgid.link/20260807095926.386923-3-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
zl3073x_dpll_input_pin_ref_sync_set() excludes the sync source from
automatic reference selection by setting its priority to NONE, but
currently only does this on the single DPLL channel whose pin_priv
was passed to the callback.
Since input pins are registered with every DPLL channel, the datasheet
recommends covering all channels to prevent the sync source from
remaining a selectable candidate on the other channels. This is
a preparation for the following patch which changes the DPLL core to
invoke pin-level set callbacks only through the pin owner's reference
instead of iterating over all registered DPLL devices.
Replace the single-channel priority write with a list_for_each_entry()
loop over all DPLL channels. Each channel's lock is acquired
individually for its read-modify-write sequence. The guard(mutex) is
replaced with explicit mutex_lock/mutex_unlock to allow releasing the
owner's lock before iterating, avoiding nested locking of the same
mutex class. A change notification is sent for the sync pin if any
channel's priority was actually modified.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Petr Oros <poros@redhat.com>
Link: https://patch.msgid.link/20260807095926.386923-2-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
reuseport_bpf_numa case failed when testing on a platform with CXL
memory:
#./reuseport_bpf_numa
---- IPv4 UDP ----
send node 0, receive socket 0
./reuseport_bpf_numa: failed to pin to node: Invalid argument
The root cause is that the platform has 2 numa nodes: node 0 has
both cpu and memory, while node 1 is a CXL node which only has
memory, and caused numa_run_on_node() to fail.
Add sanity check to skip cpuless numa node for the numa binding test.
Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260807002436.43991-1-feng.tang@linux.alibaba.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
sctp_auth_calculate_hmac() can fail when building the association secret
under memory pressure, but its void return silently leaves the HMAC digest
zeroed. On the receive path, sctp_sf_authenticate() compares this zeroed
digest against the peer-supplied one using crypto_memneq(), potentially
accepting an all-zero HMAC from the peer if the allocation failed. On the
send path, sctp_packet_pack() transmits a packet with a zeroed HMAC that
the peer would reject.
Improve error handling by making sctp_auth_calculate_hmac() return int:
- sctp_sf_authenticate() returns SCTP_IERROR_NOMEM instead of accepting
a zero HMAC.
- sctp_packet_pack() drops the packet on failure instead of transmitting
a zeroed HMAC.
Update the declaration in auth.h accordingly.
Assisted-by: LLM
Signed-off-by: Qing Luo <luoqing@kylinos.cn>
Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20260807064314.500742-1-l1138897701@163.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Thaison Phan says:
====================
update NULL pointer handling in generated code
This series fixes potential NULL pointer dereferences in YNL-generated C
code during dump list freeing and memory allocation in parsing getters.
====================
Link: https://patch.msgid.link/20260807171500.7188-1-thaisonphan@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Generated YNL getter code does not check the return value of malloc() and
calloc() before passing the resulting pointer to memcpy(). This could lead
to a NULL pointer dereference on memory allocation failure.
Updated the C code generator to check for allocation failures and to return
an error code in getters.
Signed-off-by: Thaison Phan <thaisonphan@google.com>
Link: https://patch.msgid.link/20260807171500.7188-3-thaisonphan@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Static analysis detected code paths where freeing a dump list after early
errors when creating the corresponding dump list like in ynl_exec_dump()
can result in a null pointer dereference since the first node in the
ynl_dump_state would still be zero initialized. To prevent this potential
problem updated the ynl c generation script to check for a NULL pointer
before continuing to free the nodes in a dump list.
Signed-off-by: Thaison Phan <thaisonphan@google.com>
Link: https://patch.msgid.link/20260807171500.7188-2-thaisonphan@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bond_reset() waits up to 2 seconds for IPv6 connectivity.
With default settings DAD itself may take almost 2 seconds,
causing flakes on debug builds. It used to flake once or
twice a week, recently it started failing once a day.
Probably some downstream changes to scheduler, or our machines
go busier.
A lot of selftests already use nodad, let's use nodad in bonding, too.
I don't see an obvious reason why DAD would be important to the test.
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260808162345.2442594-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ETF qdiscs drops traffic without a socket or txtime. Even with
parameter skip_sock_check regular traffic is affected by ETF.
This test ran fine when run manually in a pure software environment.
But with drv-net across two hosts tests fail as early as when calling
cfg.remote.deploy due to effectively losing connectivity.
Isolate the intended test traffic:
- mark that with SO_MARK 100
- install a regular permissive root prio qdisc for background traffic
- install the ETF qdisc as leaf
- install a filter that only directs SO_MARK 100 traffic to this leaf
Technically other high prio traffic will map onto this leaf based on
ToS band mapping too. But that is immaterial in practice.
Fixes: 5c6baef388 ("selftests: drv-net: convert so_txtime to drv-net")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260808160129.890119-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
eeprom_wait_ready() returns a negative error when the LBCIF status
cannot be read or the device does not become ready for some other
reason.
eeprom_write() propagates this error before starting a write, but
currently returns 0 when the same readiness check fails after the
write begins.
This behavior was introduced when the EEPROM code was refactored to
use Linux error-return conventions (from 0 = failure to 0 = success).
Return the error so callers do not treat a failed EEPROM write as
successful and the function contract is maintained.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Link: https://patch.msgid.link/20260808194347.813242-1-thnkslprpt@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
hwmon_sanitize_name() allocates sfp->hwmon_name before
hwmon_device_register_with_info() is called. If the registration
fails, sfp->hwmon_dev is left pointing to an error while
sfp->hwmon_name remains allocated.
Later, when the SFP module is removed, sfp_hwmon_remove() only frees
hwmon_name when hwmon_dev is valid. As a result, hwmon_name is leaked
if hwmon_device_register_with_info() fails.
Free hwmon_name independently of hwmon_dev. Continue to unregister the
hwmon device only when hwmon_dev was successfully registered.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Krishan Singh <krishanmohan298@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260809064504.70579-1-krishanmohan298@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Heiko Carstens says:
====================
drivers/s390/net: Enable CONTEXT_ANALYSIS
Enable CONTEXT_ANALYSYS for drivers/s390/net.
Static code checking for acquiring and releasing locks used to be done
with sparse. That was removed with [1] and replaced with a clang based
approach [2]. The new approach requires that each subsystem needs to be
explicitly enabled for checking.
Do that for drivers/s390/net. In order to avoid false positives due to
conditional locking, disable context analysis for specific functions of
the ctcm driver. All comments in ctcm indicate that the code should stay
as it is, and that such warnings should be ignored.
Disabling context analysis for specific functions keeps analysis enabled
for the rest of a file.
[1] 5b63d0ae94 ("compiler-context-analysis: Remove Sparse support")
[2] 3269701cb2 ("compiler-context-analysis: Add infrastructure for Context Analysis with Clang")
====================
Link: https://patch.msgid.link/20260805145032.1409325-1-hca@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Disable context analysis for various functions to get rid of context
analysis compile time warnings using clang caused by conditional
locking like e.g.:
drivers/s390/net/ctcm_fsms.c:1457:8:
warning: spinlock 'arg->cdev->ccwlock' is not held on every path through here
drivers/s390/net/ctcm_fsms.c:1459:4:
warning: releasing spinlock 'arg->cdev->ccwlock' that was not held
Use __context_unsafe() to provide a short comment why context analysis is
disabled for each function. Each of those functions already contains a
comment that the (previous) sparse context analysis warnings due to
conditional locking should be ignored.
Remove those comments everywhere and use the __context_unsafe() attribute
instead.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260805145032.1409325-2-hca@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
