| Age | Commit message (Collapse) | Author |
|---|
|
Raise IB_EVENT_DEVICE_SPEED_CHANGE whenever the speed of one of the
device's ports changes. Usually all ports of the device changes
together.
This ensures user applications and upper-layer software are immediately
notified when bandwidth changes, improving traffic management in dynamic
environments. This is especially useful for vports which are part of a
LAG configuration, to know if the effective speed of the LAG was
changed.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Add new ibv_query_port_speed() verb to enable applications to query
the effective bandwidth of a port.
This verb is particularly useful when the speed is not a multiplication
of IB speed and width where width is 2^n.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Update sysfs rate_show() to rely on ib_port_attr_to_speed_info() for
converting IB port speed and width attributes to data rate and speed
string.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Introduce ib_port_attr_to_rate() to compute the data rate in 100 Mbps
units (deci-Gb/sec) from a port's active_speed and active_width
attributes. This generic helper removes duplicated speed-to-rate
calculations, which are used by sysfs and the upcoming new verb.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Add IB_EVENT_DEVICE_SPEED_CHANGE for notifying user applications on
device's ports speed changes.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Currently, mlx5 driver exposes only the parent function's speed to VFs,
providing no way to query the actual effective bandwidth in LAG and
MPESW configurations. This limitation prevents userspace and
upper-layer software from obtaining accurate bandwidth information,
which impacts traffic scheduling decisions.
This series addresses this by:
1. Adding mlx5 internal logic to calculate and propagate the effective
aggregated LAG speed to all attached vports. The vport speeds are
dynamically updated when LAG member link states change.
2. Extending RDMA core with a new ib_query_port_speed() verb and an
IB_EVENT_DEVICE_SPEED_CHANGE async event. These interfaces expose
the effective port speed to userspace, supporting speeds that are
not expressible as IB speed * width (where width is 2^n).
This series enables userspace applications to query the effective
port speed and receive notifications on speed changes in real-time.
In LAG configurations, each mlx5 port reports the aggregated bandwidth
of all active LAG members.
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Add mlx5_lag_query_bond_speed() to query the aggregated speed of
lag configurations with a bond device.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Add port change event handling logic for MPESW LAG mode, ensuring
VFs are updated when the speed of LAG physical ports changes.
This triggers a speed update workflow when relevant port state changes
occur, enabling consistent and accurate reporting of VF bandwidth.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Currently, vports report only their parent's uplink speed, which in LAG
setups does not reflect the true aggregated bandwidth. This makes it
hard for upper-layer software to optimize load balancing decisions
based on accurate bandwidth information.
Fix the issue by calculating the possible maximum speed of a LAG as
the sum of speeds of all active uplinks that are part of the LAG.
Propagate this effective max speed to vports associated with the LAG
whenever a relevant event occurs, such as physical port link state
changes or LAG creation/modification.
With this change, upper-layer components receive accurate bandwidth
information corresponding to the active members of the LAG and can
make better load balancing decisions.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Introduce the max_tx_speed field to the query and modify_vport_state
structures.
Add the esw_vport_state_max_tx_speed capability bit, indicating
the firmware support modifying the max_tx_speed field via the
MODIFY_VPORT_STATE command.
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Edward Srouji <edwards@nvidia.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Use scoped for-each loop when iterating over device nodes to make code a
bit simpler.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
https://gitlab.freedesktop.org/drm/rust/kernel into drm-fixes
DRM Rust fixes for v6.19-rc4
MAINTAINERS:
- Fix Nova GPU driver git links.
- Fix typo in TYR driver entry preventing correct behavior of
scripts/get_maintainer.pl.
- Exclude TYR driver from DRM MISC.
Nova Core:
- Correctly select RUST_FW_LOADER_ABSTRACTIONS to prevent build
errors.
- Regenerate nova-core bindgen bindings with '--explicit-padding' to
avoid uninitialized bytes.
- Fix length of received GSP messages, due to miscalculated message
payload size.
- Regenerate bindings to derive MaybeZeroable.
- Use a bindings alias to derive the firmware version.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: "Danilo Krummrich" <dakr@kernel.org>
Link: https://patch.msgid.link/DFATYVSQRQ4W.1R030NZ34XUZK@kernel.org
|
|
When requesting a directory delegation, it is imperative to hold the
slot until the delegation state has been recorded. Otherwise, if a
recall comes in, the call to referring_call_exists() will assume the
processing is done, and when it doesn't find a delegation, it will
assume it has been returned.
Fixes: 156b09482933 ("NFS: Request a directory delegation on ACCESS, CREATE, and UNLINK")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
If the client returns a directory delegation, then look up all the child
dentries, and clear their 'verifier delegated' bit, unless subject to a
file delegation.
Similarly, if a file delegation is being returned, check if there is a
directory delegation before clearing a 'verifier delegated' bit.
Reported-by: Christoph Hellwig <hch@lst.de>
Fixes: 156b09482933 ("NFS: Request a directory delegation on ACCESS, CREATE, and UNLINK")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
Doing this check in nfs_check_verifier() resulted in many, many more
lookups on the wire when running Christoph's delegation benchmarking
script. After some experimentation, I found that we can treat directory
delegations exactly the same as having a delegated verifier when we
reach nfs4_lookup_revalidate() for the best performance.
Reported-by: Christoph Hellwig <hch@lst.de>
Fixes: 156b09482933 ("NFS: Request a directory delegation on ACCESS, CREATE, and UNLINK")
Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
In bl_parse_scsi(), if the block device length is zero, the function
returns immediately without releasing the file reference obtained via
bl_open_path(), leading to a memory leak.
Fix this by jumping to the out_blkdev_put label to ensure the file
reference is properly released.
Fixes: d76c769c8db4c ("pnfs/blocklayout: Don't add zero-length pnfs_block_dev")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,
the function jumps to the out_scratch label without freeing the already
allocated dsaddrs list, leading to a memory leak.
Fix this by jumping to the out_err_drain_dsaddrs label, which properly
frees the dsaddrs list before cleaning up other resources.
Fixes: d67ae825a59d6 ("pnfs/flexfiles: Add the FlexFile Layout Driver")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery
waiting on kthreadd, which is attempting to reclaim memory by calling
nfs_release_folio(). The latter cannot make progress due to state
recovery being needed.
It seems that the only safe thing to do here is to kick off a writeback
of the folio, without waiting for completion, or else kicking off an
asynchronous commit.
Reported-by: Wang Zhaolong <wangzhaolong@huaweicloud.com>
Fixes: 96780ca55e3c ("NFS: fix up nfs_release_folio() to try to release the page")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
Ben Coddington reports seeing a hang in the following stack trace:
0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415
1 [ffffd0b50e177548] schedule at ffffffff9ca05717
2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1
3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb
4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5
5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]
6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]
7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]
8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]
9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]
10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]
11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]
12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]
13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]
14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]
15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]
16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]
17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea
18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e
19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935
The issue is that the delegreturn is being asked to wait for a layout
return that cannot complete because a state recovery was initiated. The
state recovery cannot complete until the open() finishes processing the
delegations it was given.
The solution is to propagate the existing flags that indicate a
non-blocking call to the function pnfs_roc(), so that it knows not to
wait in this situation.
Reported-by: Benjamin Coddington <bcodding@hammerspace.com>
Fixes: 29ade5db1293 ("pNFS: Wait on outstanding layoutreturns to complete in pnfs_roc()")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree fixes from Rob Herring:
- Fix an error path memory leak in DT unittest
- Update Saravana's bouncing email
* tag 'devicetree-fixes-for-6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
of: unittest: Fix memory leak in unittest_data_add()
MAINTAINERS: Update Saravana Kannan's email address
|
|
Fix the following warning:
rust/kernel.o: warning: objtool: _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix()
falls through to next function _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated()
The commit 51d9ee90ea90 ("rust: str: add radix prefixed integer
parsing functions") introduces u64::from_str_radix(), whose
implementation contains a panic path for out-of-range radix values.
The panic helper is core::num::from_ascii_radix_panic().
Note that radix is derived from strip_radix() here and is always
within the valid range, so kernel never panics.
Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251223113538.1016078-1-fujita.tomonori@gmail.com
[ Reworded typo. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Allow usage like `pr_info!("one + 1 = {}", one + 1)` to compile by
ensuring that a reference is taken to the entire expression.
[ The errors we would get otherwise look like:
error[E0277]: `kernel::fmt::Adapter<i32>` doesn't implement `core::fmt::Display`
--> ../samples/rust/rust_minimal.rs:34:9
|
34 | pr_info!("one + 1 = {}", one + 1);
| ^^^^^^^^^^^^^^^^^^^^--^^^^^^^^^^^
| | |
| | required by this formatting parameter
| `kernel::fmt::Adapter<i32>` cannot be formatted with the default formatter
|
= help: the trait `core::fmt::Display` is not implemented for `kernel::fmt::Adapter<i32>`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= help: the trait `core::fmt::Display` is implemented for `kernel::fmt::Adapter<&T>`
= note: this error originates in the macro `$crate::print_macro` which comes from the expansion of the macro `pr_info` (in Nightly builds, run with -Z macro-backtrace for more info)
- Miguel ]
Fixes: c5cf01ba8dfe ("rust: support formatting of foreign types")
Reported-by: Janne Grunau <j@jannau.net>
Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Custom.20formatting/near/566219493
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Janne Grunau <j@jannau.net>
Reviewed-by: Janne Grunau <j@jannau.net>
Link: https://patch.msgid.link/20260104-fmt-paren-v1-1-6b84bc0da78f@gmail.com
[ Added Signed-off-by back. Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
When the `#![allow]` line was added, the doctest line number anchor
isn't updated which causes the line number printed in kunit test to be
off-by-one.
Fixes: ab844cf32058 ("rust: allow `unreachable_pub` for doctests")
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: David Gow <davidgow@google.com>
Link: https://patch.msgid.link/20251211182208.2791025-1-gary@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Fix several typos and grammatical errors in the Bounded type documentation:
- "less significant bits" -> "least significant bits"
- "with in" -> "within"
- "withheld" -> "upheld"
- "// This" -> "// This" (double space)
- "doesn't fits" -> "doesn't fit" (2 occurrences)
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://github.com/Rust-for-Linux/linux/issues/1210
Signed-off-by: Nakamura Shuta <nakamura.shuta@gmail.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Yury Norov (NVIDIA) <yury.norov@nvidia.com>
Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type")
Link: https://patch.msgid.link/20251204024336.246587-1-nakamura.shuta@gmail.com
[ Removed Link tag due to duplicated URL. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Add a missing `and` in the description of the `Adapter`.
Fixes: c5cf01ba8dfe ("rust: support formatting of foreign types")
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Acked-by: Tamir Duberstein <tamird@gmail.com>
Link: https://patch.msgid.link/20260102084821.1077864-1-dirk.behme@de.bosch.com
[ Reworded for typo. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The peek_next method's doc comment incorrectly stated it accesses the
"previous" node when it actually accesses the next node.
Fix the documentation to accurately reflect the method's behavior.
Fixes: 98c14e40e07a ("rust: rbtree: add cursor")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Hang Shu <m18080292938@163.com>
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://github.com/Rust-for-Linux/linux/issues/1205
Cc: stable@vger.kernel.org
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20251107093921.3379954-1-m18080292938@163.com
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Fix a typo in a comment to improve clarity and readability.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1206
Signed-off-by: Atharv Dubey <atharvd440@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251201165601.31484-1-atharvd440@gmail.com
[ Removed one of the cases that is gone now. Reworded accordingly
(and to avoid mentioning 'documentation', since it is just
a comment). - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
Don't populate the read-only array scale_us on the stack at run time,
instead make it static const.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20251219214428.492744-1-colin.i.king@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
configfs_group_operations
'struct configfs_item_operations' and 'configfs_group_operations' are
not modified in this driver.
Constifying these structures moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
151831 80058 4832 236721 39cb1 drivers/target/target_core_configfs.o
45200 16658 0 61858 f1a2 drivers/target/target_core_fabric_configfs.o
After:
=====
text data bss dec hex filename
152599 79290 4832 236721 39cb1 drivers/target/target_core_configfs.o
46352 15506 0 61858 f1a2 drivers/target/target_core_fabric_configfs.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/a0f25237ae86b8c4dd7a3876c4ed2dc3de200173.1767008082.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The variable tpgt in sbp_make_tpg() is defined as unsigned long and is
assigned to tpgt->tport_tpgt, which is defined as u16. This may cause an
integer overflow when tpgt is greater than USHRT_MAX (65535). I haven't
tried to trigger it myself, but it is possible to trigger it by calling
sbp_make_tpg() with a large value for tpgt.
Modify the type of tpgt to match tpgt->tport_tpgt and adjusted the
relevant code accordingly.
This patch is similar to commit 59c816c1f24d ("vhost/scsi: potential
memory corruption").
Signed-off-by: ReBeating <rebeating@163.com>
Link: https://patch.msgid.link/20251226031936.852-1-rebeating@163.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The function bfa_lps_is_brcd_fabric() was eliminated, being a one-line
function, in commit f7f73812e950 ("[SCSI] bfa: clean up one line
functions"). Replace the call in the comment by its inlined
counterpart, referring to the parameter of the subsequent function.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://patch.msgid.link/20251231165027.142443-1-Julia.Lawall@inria.fr
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
As an active participant in the development of the mpt3sas driver, add
myself to the maintainers list.
Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com>
Link: https://patch.msgid.link/20251223104721.16882-1-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Commit f46b9a595fa9 ("scsi: ufs: core: Allocate the SCSI host earlier")
did not only cause scsi_add_host() to be called earlier. It also swapped
the order of link startup and enabling and configuring MCQ mode. Before
that commit, the call chains for link startup and enabling MCQ were as
follows:
ufshcd_init()
ufshcd_link_startup()
ufshcd_add_scsi_host()
ufshcd_mcq_enable()
Apparently this change causes link startup to fail. Fix this by configuring
MCQ after link startup has completed.
Reported-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Fixes: f46b9a595fa9 ("scsi: ufs: core: Allocate the SCSI host earlier")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20251218230741.2661049-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Some low-level drivers (LLD) access block layer crypto fields, such as
rq->crypt_keyslot and rq->crypt_ctx within `struct request`, to
configure hardware for inline encryption. However, SCSI Error Handling
(EH) commands (e.g., TEST UNIT READY, START STOP UNIT) should not
involve any encryption setup.
To prevent drivers from erroneously applying crypto settings during EH,
this patch saves the original values of rq->crypt_keyslot and
rq->crypt_ctx before an EH command is prepared via scsi_eh_prep_cmnd().
These fields in the 'struct request' are then set to NULL. The original
values are restored in scsi_eh_restore_cmnd() after the EH command
completes.
This ensures that the block layer crypto context does not leak into EH
command execution.
Signed-off-by: Brian Kao <powenkao@google.com>
Link: https://patch.msgid.link/20251218031726.2642834-1-powenkao@google.com
Cc: stable@vger.kernel.org
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
If scsi_test_unit_ready() returns zero, TEST UNIT READY was executed
successfully.
Signed-off-by: Miao Li <limiao@kylinos.cn>
Link: https://patch.msgid.link/20251218023129.284307-1-limiao870622@163.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Fix several grammar errors.
Signed-off-by: Zhaoming Luo <zhml@posteo.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20251217-fix-minor-grammar-err-v3-1-9be220cdd56a@posteo.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The dm-verity kconfig options make the common mistake of selecting a
dependency from a bool "sub-option" rather than the main tristate
option. This unnecessarily forces the dependency to built-in ('y').
Fix this by moving the selections of REED_SOLOMON and REED_SOLOMON_DEC8
into DM_VERITY, conditional on DM_VERITY_FEC.
This allows REED_SOLOMON to be 'm' if DM_VERITY is 'm'.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
If either of the calls to dm_bufio_client_create() in verity_fec_ctr()
fails, then dm_bufio_client_destroy() is later called with an ERR_PTR()
argument. That causes a crash. Fix this.
Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
Cc: stable@vger.kernel.org
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
verity_fec_is_enabled() is very short and is called in quite a few
places, so make it an inline function.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
Since verity_fec_decode() has a !CONFIG_DM_VERITY_FEC stub, it can just
be called unconditionally, similar to the other calls in the same file.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
Make verity_finish_io() call verity_fec_finish_io() unconditionally,
instead of skipping it when 'in_bh' is true.
Although FEC can't have been done when 'in_bh' is true,
verity_fec_finish_io() is a no-op when FEC wasn't done. An earlier
change also made verity_fec_finish_io() very lightweight when FEC wasn't
done. So it should just be called unconditionally.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
When correcting a data block, the FEC code performs optimally when it
has enough buffers to hold all the needed RS blocks. That number of
buffers is '1 << (v->data_dev_block_bits - DM_VERITY_FEC_BUF_RS_BITS)'.
However, since v->data_dev_block_bits isn't a compile-time constant, the
code actually used PAGE_SHIFT instead.
With the traditional PAGE_SIZE == data_block_size == 4096, this was
fine. However, when PAGE_SIZE > data_block_size, this wastes space.
E.g., with data_block_size == 4096 && PAGE_SIZE == 16384, struct
dm_verity_fec_io is 9240 bytes, when in fact only 3096 bytes are needed.
Fix this by making dm_verity_fec_io::bufs a variable-length array.
This makes the macros DM_VERITY_FEC_BUF_MAX and
fec_for_each_extra_buffer() no longer apply, so remove them. For
consistency, and because DM_VERITY_FEC_BUF_PREALLOC is fixed at 1 and
was already assumed to be 1 (considering that mempool_alloc() shouldn't
be called in a loop), also remove the related macros
DM_VERITY_FEC_BUF_PREALLOC and fec_for_each_prealloc_buffer().
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
Currently, struct dm_verity_fec_io is allocated in the front padding of
struct bio using dm_target::per_io_data_size. Unfortunately, struct
dm_verity_fec_io is very large: 3096 bytes when CONFIG_64BIT=y &&
PAGE_SIZE == 4096, or 9240 bytes when CONFIG_64BIT=y && PAGE_SIZE ==
16384. This makes the bio size very large.
Moreover, most of dm_verity_fec_io gets iterated over up to three times,
even on I/O requests that don't require any error correction:
1. To zero the memory on allocation, if init_on_alloc=1. (This happens
when the bio is allocated, not in dm-verity itself.)
2. To zero the buffers array in verity_fec_init_io().
3. To free the buffers in verity_fec_finish_io().
Fix all of these inefficiencies by moving dm_verity_fec_io to a mempool.
Replace the embedded dm_verity_fec_io with a pointer
dm_verity_io::fec_io. verity_fec_init_io() initializes it to NULL,
verity_fec_decode() allocates it on the first call, and
verity_fec_finish_io() cleans it up. The normal case is that the
pointer simply stays NULL, so the overhead becomes negligible.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
The clone target already exposes both source and destination devices via
clone_iterate_devices(), so dm-table's device_area_is_invalid() helper
ensures that the mapping does not extend past either underlying block
device.
The manual comparisons between ti->len and the source/destination device
sizes in parse_source_dev() and parse_dest_dev() are therefore
redundant. Remove these checks and rely on the core validation instead.
This changes the error strings reported when the devices are too small,
but preserves the failure behaviour.
Signed-off-by: Li Chen <me@linux.beauty>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
The cache target already exposes the origin device through
cache_iterate_devices(), which allows dm-table to call
device_area_is_invalid() and verify that the mapping fits inside the
underlying block device.
The explicit ti->len > origin_sectors test in parse_origin_dev() is
therefore redundant. Drop this check and rely on the core device
validation instead. This changes the user-visible error string when the
origin is too small, but preserves the failure behaviour.
Signed-off-by: Li Chen <me@linux.beauty>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
Due to a change of employer, I'll be using a permanent and personal
email address.
Signed-off-by: Justin Iurman <justin.iurman@gmail.com>
Link: https://patch.msgid.link/20260103165331.20120-1-justin.iurman@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Florian Westphal says:
====================
netfilter: updates for net
The following patchset contains Netfilter fixes for *net*:
1) Fix overlap detection for nf_tables with concatenated ranges.
There are cases where element could not be added due to a conflict
with existing range, while kernel reports success to userspace.
2) update selftest to cover this bug.
3) synproxy update path should use READ/WRITE once as we replace
config struct while packet path might read it in parallel.
This relies on said config struct to fit sizeof(long).
From Fernando Fernandez Mancera.
4) Don't return -EEXIST from xtables in module load path, a pending
patch to module infra will spot a warning if this happens.
From Daniel Gomez.
5) Fix a memory leak in nf_tables when chain hits 2**32 users
and rule is to be hw-offloaded, from Zilin Guan.
6) Avoid infinite list growth when insert rate is high in nf_conncount,
also from Fernando.
* tag 'nf-26-01-02' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_conncount: update last_gc only when GC has been performed
netfilter: nf_tables: fix memory leak in nf_tables_newrule()
netfilter: replace -EEXIST with -EBUSY
netfilter: nft_synproxy: avoid possible data-race on update operation
selftests: netfilter: nft_concat_range.sh: add check for overlap detection bug
netfilter: nft_set_pipapo: fix range overlap detection
====================
Link: https://patch.msgid.link/20260102114128.7007-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging
leaked skbs/conntrack references more obvious.
syzbot reports this as triggering, and I can also reproduce this via
ip_defrag.sh selftest:
conntrack cleanup blocked for 60s
WARNING: net/netfilter/nf_conntrack_core.c:2512
[..]
conntrack clenups gets stuck because there are skbs with still hold nf_conn
references via their frag_list.
net.core.skb_defer_max=0 makes the hang disappear.
Eric Dumazet points out that skb_release_head_state() doesn't follow the
fraglist.
ip_defrag.sh can only reproduce this problem since
commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this
problem could happen with TCP as well if pmtu discovery is off.
The relevant problem path for udp is:
1. netns emits fragmented packets
2. nf_defrag_v6_hook reassembles them (in output hook)
3. reassembled skb is tracked (skb owns nf_conn reference)
4. ip6_output refragments
5. refragmented packets also own nf_conn reference (ip6_fragment
calls ip6_copy_metadata())
6. on input path, nf_defrag_v6_hook skips defragmentation: the
fragments already have skb->nf_conn attached
7. skbs are reassembled via ipv6_frag_rcv()
8. skb_consume_udp -> skb_attempt_defer_free() -> skb ends up
in pcpu freelist, but still has nf_conn reference.
Possible solutions:
1 let defrag engine drop nf_conn entry, OR
2 export kick_defer_list_purge() and call it from the conntrack
netns exit callback, OR
3 add skb_has_frag_list() check to skb_attempt_defer_free()
2 & 3 also solve ip_defrag.sh hang but share same drawback:
Such reassembled skbs, queued to socket, can prevent conntrack module
removal until userspace has consumed the packet. While both tcp and udp
stack do call nf_reset_ct() before placing skb on socket queue, that
function doesn't iterate frag_list skbs.
Therefore drop nf_conn entries when they are placed in defrag queue.
Keep the nf_conn entry of the first (offset 0) skb so that reassembled
skb retains nf_conn entry for sake of TX path.
Note that fixes tag is incorrect; it points to the commit introducing the
'ip_defrag.sh reproducible problem': no need to backport this patch to
every stable kernel.
Reported-by: syzbot+4393c47753b7808dac7d@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/693b0fa7.050a0220.4004e.040d.GAE@google.com/
Fixes: 6471658dc66c ("udp: use skb_attempt_defer_free()")
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260102140030.32367-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Initial rss_hdr allocation uses virtio_device->device,
but virtnet_set_queues() frees using net_device->device.
This device mismatch causing below devres warning
[ 3788.514041] ------------[ cut here ]------------
[ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463
[ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]
[ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT
[ 3788.514067] Tainted: [W]=WARN
[ 3788.514069] Hardware name: Marvell CN106XX board (DT)
[ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[ 3788.514074] pc : devm_kfree+0x84/0x98
[ 3788.514076] lr : devm_kfree+0x54/0x98
[ 3788.514079] sp : ffff800084e2f220
[ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f
[ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080
[ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018
[ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000
[ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff
[ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff
[ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c
[ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f
[ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080
[ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000
[ 3788.514123] Call trace:
[ 3788.514125] devm_kfree+0x84/0x98 (P)
[ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]
[ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]
[ 3788.514139] virtio_dev_probe+0x1e0/0x338
[ 3788.514144] really_probe+0xc8/0x3a0
[ 3788.514149] __driver_probe_device+0x84/0x170
[ 3788.514152] driver_probe_device+0x44/0x120
[ 3788.514155] __device_attach_driver+0xc4/0x168
[ 3788.514158] bus_for_each_drv+0x8c/0xf0
[ 3788.514161] __device_attach+0xa4/0x1c0
[ 3788.514164] device_initial_probe+0x1c/0x30
[ 3788.514168] bus_probe_device+0xb4/0xc0
[ 3788.514170] device_add+0x614/0x828
[ 3788.514173] register_virtio_device+0x214/0x258
[ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]
[ 3788.514179] vdpa_dev_probe+0xa8/0xd8
[ 3788.514183] really_probe+0xc8/0x3a0
[ 3788.514186] __driver_probe_device+0x84/0x170
[ 3788.514189] driver_probe_device+0x44/0x120
[ 3788.514192] __device_attach_driver+0xc4/0x168
[ 3788.514195] bus_for_each_drv+0x8c/0xf0
[ 3788.514197] __device_attach+0xa4/0x1c0
[ 3788.514200] device_initial_probe+0x1c/0x30
[ 3788.514203] bus_probe_device+0xb4/0xc0
[ 3788.514206] device_add+0x614/0x828
[ 3788.514209] _vdpa_register_device+0x58/0x88
[ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]
[ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0
[ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158
[ 3788.514222] genl_rcv_msg+0x218/0x298
[ 3788.514225] netlink_rcv_skb+0x64/0x138
[ 3788.514229] genl_rcv+0x40/0x60
[ 3788.514233] netlink_unicast+0x32c/0x3b0
[ 3788.514237] netlink_sendmsg+0x170/0x3b8
[ 3788.514241] __sys_sendto+0x12c/0x1c0
[ 3788.514246] __arm64_sys_sendto+0x30/0x48
[ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8
[ 3788.514255] do_el0_svc+0x48/0xd0
[ 3788.514259] el0_svc+0x48/0x210
[ 3788.514264] el0t_64_sync_handler+0xa0/0xe8
[ 3788.514268] el0t_64_sync+0x198/0x1a0
[ 3788.514271] ---[ end trace 0000000000000000 ]---
Fix by using virtio_device->device consistently for
allocation and deallocation
Fixes: 4944be2f5ad8c ("virtio_net: Allocate rss_hdr with devres")
Signed-off-by: Kommula Shiva Shankar <kshankar@marvell.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Link: https://patch.msgid.link/20260102101900.692770-1-kshankar@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
