Mark device faulty and exit at once when setting badblocks fails in
narrow_write_error(). No need to continue processing remaining sections.
With this change, narrow_write_error() no longer needs to return a value,
so adjust its return type to void.
Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-5-linan666@huaweicloud.com
Signed-off-by: Li Nan <linan122@huawei.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
When badblocks.shift < 0 (badblocks disabled), narrow_write_error()
return false, preventing write error handling. Since narrow_write_error()
only splits IO into smaller sizes and re-submits, it can work with
badblocks disabled.
Adjust to use the logical block size for block_sectors when badblocks is
disabled, allowing narrow_write_error() to function in this case.
Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-4-linan666@huaweicloud.com
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai@fnnas.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
The 'ok' parameter in md_done_sync() is redundant for most callers that
always pass 'true'. Factor error handling logic into a separate helper
function md_sync_error() to eliminate unnecessary parameter passing and
improve code clarity.
No functional changes introduced.
Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-3-linan666@huaweicloud.com
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
In end_sync_write, r1bio state is always set to either R1BIO_WriteError
or R1BIO_MadeGood. Consequently, put_sync_write_buf() never takes the
'else' branch that calls md_done_sync(), making the uptodate parameter
have no practical effect.
Pass 1 to put_sync_write_buf(). A more complete cleanup will be done in
a follow-up patch.
Link: https://lore.kernel.org/linux-raid/20260105110300.1442509-2-linan666@huaweicloud.com
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai@fnnas.com>
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
Otherwise, even if user issue IO by io_opt, such IO will be split
by max_sectors before they are submitted to raid5. For consequence,
full stripe IO is impossible.
BTW, dm-raid5 is not affected and still have such problem.
Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-7-yukuai@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
On the one hand, stripe_request_ctx is 72 bytes, and it's a bit huge for
a stack variable.
On the other hand, the bitmap sectors_to_do is a fixed size, result in
max_hw_sector_kb of raid5 array is at most 256 * 4k = 1Mb, and this will
make full stripe IO impossible for the array that chunk_size * data_disks
is bigger. Allocate ctx during runtime will make it possible to get rid
of this limit.
Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-6-yukuai@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fnnas.com>
Reviewed-by: Li Nan <linan122@huawei.com>
Since commit f63f17350e ("md/raid5: use the atomic queue limit
update APIs"), the abort path in raid5_run() returns 'ret' instead of
-EIO. However, if log_init() fails, 'ret' is still 0 from the previous
successful call, causing raid5_run() to return success despite the
failure.
Fix this by capturing the return value from log_init().
Link: https://lore.kernel.org/linux-raid/20260114171241.3043364-2-yukuai@fnnas.com
Fixes: f63f17350e ("md/raid5: use the atomic queue limit update APIs")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202601130531.LGfcZsa4-lkp@intel.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Li Nan <linan122@huawei.com>
Reviewed-by: Xiao Ni <xni@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
'fork' implements copy-on-write (COW) by making pages readonly in both
child and parent.
ptep_set_wrprotect() and pte_wrprotect() clear _PAGE_WRITE in PTE.
The assumption is that the page is readable and, on a fault,
copy-on-write happens.
To implement COW on shadow stack pages, clearing the W bit makes them
XWR = 000. This will result in the wrong PTE setting, which allows no
permissions, but with V=1 and the PFN field pointing to the final
page. Instead, the desired behavior is to turn it into a readable
page, take an access (load/store) fault on sspush/sspop (shadow stack)
and then perform COW on such pages. This way regular reads would still
be allowed and not lead to COW maintaining current behavior of COW on
non-shadow stack but writeable memory.
On the other hand, this doesn't interfere with existing COW for
read-write memory. The assumption is always that _PAGE_READ must have
been set, and thus, setting _PAGE_READ is harmless.
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Reviewed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-9-b55691eacf4f@rivosinc.com
[pjw@kernel.org: clarify patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
pte_mkwrite() creates PTEs with WRITE encodings for the underlying
architecture. The underlying architecture can have two types of
writeable mappings: one that can be written using regular store
instructions, and another one that can only be written using
specialized store instructions (like shadow stack stores).
pte_mkwrite can select write PTE encoding based on VMA range (i.e.
VM_SHADOW_STACK)
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Reviewed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-8-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
This patch implements the creation of a shadow stack pte on
riscv. Creating shadow stack PTE on riscv means clearing RWX and then
setting W=1.
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Reviewed-by: Zong Li <zong.li@sifive.com>
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-7-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
'arch_calc_vm_prot_bits' is implemented on risc-v to return VM_READ |
VM_WRITE if PROT_WRITE is specified. Similarly 'riscv_sys_mmap' is
updated to convert all incoming PROT_WRITE to (PROT_WRITE | PROT_READ).
This is to make sure that any existing apps using PROT_WRITE still work.
Earlier 'protection_map[VM_WRITE]' used to pick read-write PTE encodings.
Now 'protection_map[VM_WRITE]' will always pick PAGE_SHADOWSTACK PTE
encodings for shadow stack. The above changes ensure that existing apps
continue to work because underneath, the kernel will be picking
'protection_map[VM_WRITE|VM_READ]' PTE encodings.
Reviewed-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-6-b55691eacf4f@rivosinc.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Carve out space in the RISC-V architecture-specific thread struct for
cfi status and shadow stack in usermode.
This patch:
- defines a new structure cfi_status with status bit for cfi feature
- defines shadow stack pointer, base and size in cfi_status structure
- defines offsets to new member fields in thread in asm-offsets.c
- saves and restores shadow stack pointer on trap entry (U --> S) and exit
(S --> U)
Shadow stack save/restore is gated on feature availability and is
implemented using alternatives. CSR_SSP can be context-switched in
'switch_to' as well, but as soon as kernel shadow stack support gets
rolled in, the shadow stack pointer will need to be switched at trap
entry/exit point (much like 'sp'). It can be argued that a kernel
using a shadow stack deployment scenario may not be as prevalent as
user mode using this feature. But even if there is some minimal
deployment of kernel shadow stack, that means that it needs to be
supported. Thus save/restore of shadow stack pointer is implemented
in entry.S instead of in 'switch_to.h'.
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-5-b55691eacf4f@rivosinc.com
[pjw@kernel.org: cleaned up patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The Zicfiss and Zicfilp extensions are enabled via b3 and b2 in
*envcfg CSRs. menvcfg controls enabling for S/HS mode. henvcfg
controls enabling for VS. senvcfg controls enabling for U/VU mode.
The Zicfilp extension extends *status CSRs to hold an 'expected
landing pad' bit. A trap or interrupt can occur between an indirect
jmp/call and target instruction. The 'expected landing pad' bit from
the CPU is recorded into the xstatus CSR so that when the supervisor
performs xret, the 'expected landing pad' state of the CPU can be
restored.
Zicfiss adds one new CSR, CSR_SSP, which contains the current shadow
stack pointer.
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-4-b55691eacf4f@rivosinc.com
[pjw@kernel.org: grouped CSR_SSP macro with the other CSR macros; clarified patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
This patch adds support for detecting the RISC-V ISA extensions
Zicfiss and Zicfilp. Zicfiss and Zicfilp stand for the unprivileged
integer spec extensions for shadow stack and indirect branch tracking,
respectively.
This patch looks for Zicfiss and Zicfilp in the device tree and
accordingly lights up the corresponding bits in the cpu feature
bitmap. Furthermore this patch adds detection utility functions to
return whether shadow stack or landing pads are supported by the cpu.
Reviewed-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: Deepak Gupta <debug@rivosinc.com>
Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6
Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com>
Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-3-b55691eacf4f@rivosinc.com
[pjw@kernel.org: updated to apply; cleaned up patch description]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Reduce nested max() calls by a single max3() call in this
function implementation.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: https://patch.msgid.link/d1a384c9-f154-4537-94d6-c3613f4167bc@web.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
NLS_ISO8859_1 was enabled as a module with commit efe1e08bca ("riscv:
defconfig: enable NLS_CODEPAGE_437, NLS_ISO8859_1"), but the
NLS_CODEPAGE_437 counterpart is selected as built-in. The commit does
not explain the reason behind, and it is not consistent with the
defconfig for ARM64 that also enables these modules to mount EFI system
partitions.
Select NLS_ISO8859_1 as built-in to provide both requirements within the
kernel image.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://patch.msgid.link/20260111-nls_iso8859_1_y_riscv-v1-1-2c992bb2c00d@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Currently, the implementation of copy_user_page() is identical to
copy_page().
Align riscv with other architectures (alpha, arc, arm64, hexagon,
longarch, m68k, openrisc, s390, um, xtensa) and map copy_user_page()
to copy_page() given that their implementation is identical.
In addition to following a common pattern, this centralizes the
implementation. Any changes to the underlying page copy logic (e.g.,
for CHERI) will now automatically propagate to copy_user_page().
Signed-off-by: Florian Schmaus <florian.schmaus@codasip.com>
Link: https://patch.msgid.link/20260113134025.905627-1-florian.schmaus@codasip.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
When both the SiFive and MIPS errata are enabled then
sifive_errata_patch_func emits a wrong and misleading warning claiming
that the SiFive errata haven't been applied. This happens because
sifive_errata_patch_func is being called twice, once for the kernel image
and once for the vdso image. The vdso image has alternative entries
for the MIPS errata, but none for the SiFive errata.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Link: https://patch.msgid.link/mvmv7i8q8gg.fsf@suse.de
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Some developers may be confused because RISC-V does not have
a register named r0. Also, orig_r0 is not available in pt_regs structure,
which is specific to riscv. So we had better fix this minor typo.
Signed-off-by: Austin Kim <austin.kim@lge.com>
Link: https://patch.msgid.link/aW3Z4zTBvGJpk7a7@adminpc-PowerEdge-R7525
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Clean up a few warnings reported by sparse in
arch/riscv/kernel/signal.c. These come from code that was added
recently; they were missed when I initially reviewed the patch.
Fixes: 818d78ba1b ("riscv: signal: abstract header saving for setup_sigcontext")
Cc: Andy Chiu <andybnac@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601171848.ydLTJYrz-lkp@intel.com/
[pjw@kernel.org: updated to apply]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-26-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-19-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-12-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-11-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Acked-by: Andrew Ballance <andrewjballance@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-10-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-8-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-3-51da5f454a67@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`GspInitDone` has no payload whatsoever, so the unit type `()` is the
correct way to represent its message content. We can use it now that
`()` implements `FromBytes`.
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251215-transmute_unit-v4-2-477d71ec7c23@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is useful when using types that may or may not be empty in generic
code relying on these traits. It is also safe because technically a
no-op.
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Link: https://patch.msgid.link/20251215-transmute_unit-v4-1-477d71ec7c23@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Some doc comments use `NULL` while others use plain NULL. Make it
consistent by adding backticks everywhere, matching the majority of
existing usage.
Signed-off-by: Peter Novak <seimun018r@gmail.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: David Gow <davidgow@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251130211233.367946-1-seimun018r@gmail.com
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This entry will handle the support for `rust-analyzer`, which at the
moment is essentially about the `scripts/generate_rust_analyzer.py`
script.
It is one more subentry of the Rust subsystem. The new branch is
already part of linux-next and will be used to send PRs to be merged
into rust-next.
Tamir and Jesung will take care of it. They have both been active around
the `rust-analyzer` support for a while.
Acked-by: Tamir Duberstein <tamird@kernel.org>
Acked-by: Jesung Yang <y.j3ms.n@gmail.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260115214545.63262-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Following commit 3a1ec424dd ("rust: num: bounded: mark __new as
unsafe"), remove the redundant paragraph in the documentation of __new now
that the Safety section explicitly covers the requirement.
Additionally, add an INVARIANT comment inside the function body where
the Bounded instance is actually constructed to document that the type
invariant is upheld.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/CANiq72mUCUh72BWP4eD1PTDpwdb1ML+Xgfom-Ys6thJooqQPwQ@mail.gmail.com/
Signed-off-by: Shivam Kalra <shivamklr@cock.li>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260123132132.53854-1-shivamklr@cock.li
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Shawn is no longer interested in maintaining i.MX platform, and would like
to step down. On the other hand, Frank seems to be the best successor
for this role.
- He has been one of the most outstanding contributors to i.MX platform
in the recent years.
- He has been actively working as a co-maintainer reviewing i.MX
patches and keep the platform support in good shape.
- He works for NXP and could be the bridge and coordinator between
NXP internal developers and community contributors.
Acked-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Currently, rust-analyzer fails to properly resolve structs annotated with
`#[pin_data]`. This prevents IDE features like "Go to Definition" from
working correctly for those structs.
Add the missing configuration to `generate_rust_analyzer.py` to ensure
the `pin-init` crate macros are handled correctly.
Signed-off-by: SeungJong Ha <engineer.jjhama@gmail.com>
Fixes: d7659acca7 ("rust: add pin-init crate build infrastructure")
Cc: stable@vger.kernel.org
Tested-by: Tamir Duberstein <tamird@kernel.org>
Acked-by: Tamir Duberstein <tamird@kernel.org>
Acked-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Jesung Yang <y.j3ms.n@gmail.com>
Link: https://patch.msgid.link/20260123-fix-pin-init-crate-dependecies-v2-1-bb1c2500e54c@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Tyr needs `CONFIG_COMMON_CLK` to build:
error[E0432]: unresolved import `kernel::clk::Clk`
--> drivers/gpu/drm/tyr/driver.rs:3:5
|
3 | use kernel::clk::Clk;
| ^^^^^^^^^^^^^^^^ no `Clk` in `clk`
error[E0432]: unresolved import `kernel::clk::OptionalClk`
--> drivers/gpu/drm/tyr/driver.rs:4:5
|
4 | use kernel::clk::OptionalClk;
| ^^^^^^^^^^^^^^^^^^^^^^^^ no `OptionalClk` in `clk`
Thus add the dependency to fix it.
Fixes: cf4fd52e32 ("rust: drm: Introduce the Tyr driver for Arm Mali GPUs")
Cc: stable@vger.kernel.org
Acked-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260124160948.67508-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
For arm32, on a x86_64 builder, running the `rusttest` target yields:
error[E0080]: evaluation of constant value failed
--> rust/kernel/static_assert.rs:37:23
|
37 | const _: () = ::core::assert!($condition $(,$arg)?);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: size_of::<isize>() == size_of::<isize_atomic_repr>()', rust/kernel/sync/atomic/predefine.rs:68:1
|
::: rust/kernel/sync/atomic/predefine.rs:68:1
|
68 | static_assert!(size_of::<isize>() == size_of::<isize_atomic_repr>());
| -------------------------------------------------------------------- in this macro invocation
|
= note: this error originates in the macro `::core::assert` which comes from the expansion of the macro `static_assert` (in Nightly builds, run with -Z macro-backtrace for more info)
The reason is that `rusttest` runs on the host, so for e.g. a x86_64
builder `isize` is 64 bits but it is not a `CONFIG_64BIT` build.
Fix it by providing a stub for `rusttest` as usual.
Fixes: 84c6d36bca ("rust: sync: atomic: Add Atomic<{usize,isize}>")
Cc: stable@vger.kernel.org
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Acked-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260123233432.22703-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reported by the following Smatch static checker warning:
drivers/net/dsa/yt921x.c:702 yt921x_read_mib()
warn: was expecting a 64 bit value instead of '(~0)'
Fixes: 186623f4aa ("net: dsa: yt921x: Add support for Motorcomm YT921x")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/netdev/aPsjYKQMzpY0nSXm@stanley.mountain/
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://patch.msgid.link/20260122170512.2713738-1-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says:
====================
refactor IDPF resource access
Pavan Kumar Linga says:
Queue and vector resources for a given vport, are stored in the
idpf_vport structure. At the time of configuration, these
resources are accessed using vport pointer. Meaning, all the
config path functions are tied to the default queue and vector
resources of the vport.
There are use cases which can make use of config path functions
to configure queue and vector resources that are not tied to any
vport. One such use case is PTP secondary mailbox creation
(it would be in a followup series). To configure queue and interrupt
resources for such cases, we can make use of the existing config
infrastructure by passing the necessary queue and vector resources info.
To achieve this, group the existing queue and vector resources into
default resource group and refactor the code to pass the resource
pointer to the config path functions.
This series also includes patches which generalizes the send virtchnl
message APIs and mailbox API that are necessary for the implementation
of PTP secondary mailbox.
* '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
idpf: generalize mailbox API
idpf: avoid calling get_rx_ptypes for each vport
idpf: generalize send virtchnl message API
idpf: remove vport pointer from queue sets
idpf: add rss_data field to RSS function parameters
idpf: reshuffle idpf_vport struct members to avoid holes
idpf: move some iterator declarations inside for loops
idpf: move queue resources to idpf_q_vec_rsrc structure
idpf: introduce idpf_q_vec_rsrc struct and move vector resources to it
idpf: introduce local idpf structure to store virtchnl queue chunks
====================
Link: https://patch.msgid.link/20260122223601.2208759-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
SR_WR_REG and SR_WR_REGS may be confused at a cursory glance. Rename
them to be more easily differentiated to prevent this.
Suggested-by: Andrew Lunn <andrew+netdev@lunn.ch>
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Peter Korsgaard <peter@korsgaard.com>
Link: https://patch.msgid.link/20260123080409.64165-1-enelsonmoore@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The driver hardcodes the number 6 as the number of bytes to write to
the SR_PAR register, which stores the MAC address. Use ETH_ALEN instead
to make the code clearer.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Peter Korsgaard <peter@korsgaard.com>
Link: https://patch.msgid.link/20260123070645.56434-1-enelsonmoore@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Petr Machata says:
====================
net: neighbour: Notify changes atomically
Andy Roulin and Francesco Ruggeri have apparently independently both hit an
issue with the current neighbor notification scheme. Francesco reported the
issue in [1]. In a response[2] to that report, Andy said:
neigh_update sends a rtnl notification if an update, e.g.,
nud_state change, was done but there is no guarantee of
ordering of the rtnl notifications. Consider the following
scenario:
userspace thread kernel thread
================ =============
neigh_update
write_lock_bh(n->lock)
n->nud_state = STALE
write_unlock_bh(n->lock)
neigh_notify
neigh_fill_info
read_lock_bh(n->lock)
ndm->nud_state = STALE
read_unlock_bh(n->lock)
-------------------------->
neigh:update
write_lock_bh(n->lock)
n->nud_state = REACHABLE
write_unlock_bh(n->lock)
neigh_notify
neigh_fill_info
read_lock_bh(n->lock)
ndm->nud_state = REACHABLE
read_unlock_bh(n->lock)
rtnl_nofify
RTNL REACHABLE sent
<--------
rtnl_notify
RTNL STALE sent
In this scenario, the kernel neigh is updated first to STALE and
then REACHABLE but the netlink notifications are sent out of order,
first REACHABLE and then STALE.
The solution presented in [2] was to extend the critical region to include
both the call to neigh_fill_info(), as well as rtnl_notify(). Then we have
a guarantee that whatever state was captured by neigh_fill_info(), will be
sent right away. The above scenario can thus not happen.
This is how this patchset begins: patches #1 and #2 add helper duals to
neigh_fill_info() and __neigh_notify() such that the __-prefixed function
assumes the neighbor lock is held, and the unprefixed one is a thin wrapper
that manages locking. This extends locking further than Andy's patch, but
makes for a clear code and supports the following part.
At that point, the original race is gone. But what can happen is the
following race, where the notification does not reflect the change that was
made:
userspace thread kernel thread
================ =============
neigh_update
write_lock_bh(n->lock)
n->nud_state = STALE
write_unlock_bh(n->lock)
-------------------------->
neigh:update
write_lock_bh(n->lock)
n->nud_state = REACHABLE
write_unlock_bh(n->lock)
neigh_notify
read_lock_bh(n->lock)
__neigh_fill_info
ndm->nud_state = REACHABLE
rtnl_notify
read_unlock_bh(n->lock)
RTNL REACHABLE sent
<--------
neigh_notify
read_lock_bh(n->lock)
__neigh_fill_info
ndm->nud_state = REACHABLE
rtnl_notify
read_unlock_bh(n->lock)
RTNL REACHABLE sent again
Here, even though neigh_update() made a change to STALE, it later sends a
notification with a NUD of REACHABLE. The obvious solution to fix this race
is to move the notifier to the same critical section that actually makes
the change.
Sending a notification in fact involves two things: invoking the internal
notifier chain, and sending the netlink notification. The overall approach
in this patchset is to move the netlink notification to the critical
section of the change, while keeping the internal notifier intact. Since
the motion is not obviously correct, the patchset presents the change in
series of incremental steps with discussion in commit messages. Please see
details in the patches themselves.
Reproducer
==========
To consistently reproduce, I injected an mdelay before the rtnl_notify()
call. Since only one thread should delay, a bit of instrumentation was
needed to see where the call originates. The mdelay was then only issued on
the call stack rooted in the RTNL request.
Then the general idea is to issue an "ip neigh replace" to mark a neighbor
entry as failed. In parallel to that, inject an ARP burst that validates
the entry. This is all observed with an "ip monitor neigh", where one can
see either a REACHABLE->FAILED transition, or FAILED->REACHABLE, while the
actual state at the end of the sequence is always REACHABLE.
With the patchset, only FAILED->REACHABLE is ever observed in the monitor.
Alternatives
============
Another approach to solving the issue would be to have a per-neighbor queue
of notification digests, each with a set of fields necessary for formatting
a notification. In pseudocode, a neighbor update would look something like
this:
neighbor_update:
- lock
- do update
- allocate notification digest, fill partially, mark not-committed
- unlock
- critical-section-breaking stuff (probes, ARP Q, etc.)
- lock
- fill in missing details to the digest (notably neigh->probes)
- mark the digest as committed
- while (front of the digest queue is committed)
- pop it, convert to notifier, send the notification
- unlock
This adds more complexity and would imply more changes to the code, which
is why I think the approach presented in this patchset is better. But it
would allow us to retain the overall structure of the code while giving us
accurate notifications.
A third approach would be to consider the second race not very serious and
be OK with seeing a notification that does not reflect the change that
prompted it. Then a two-patch prefix of this patchset would be all that is
needed.
[1]: https://lore.kernel.org/20220606230107.D70B55EC0B30@us226.sjc.aristanetworks.com
[2]: https://lore.kernel.org/ed6768c1-80b8-aee2-e545-b51661d49336@nvidia.com
====================
Link: https://patch.msgid.link/cover.1769012464.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Similarly to the issue from the previous patch, neigh_timer_handler() also
updates the neighbor separately from formatting and sending the netlink
notification message. We have not seen reports to the effect of this
causing trouble, but in theory, the same sort of issues could have come up:
neigh_timer_handler() would make changes as necessary, but before
formatting and sending a notification, is interrupted before sending by
another thread, which makes a parallel change and sends its own message.
The message send that is prompted by an earlier change thus contains
information that does not reflect the change having been made.
To solve this, the netlink notification needs to be in the same critical
section that updates the neighbor. The critical section is ended by the
neigh_probe() call which drops the lock before calling solicit. Stretching
the critical section over the solicit call is problematic, because that can
then involved all sorts of forwarding callbacks. Therefore, like in the
previous patch, split the netlink notification away from the internal one
and move it ahead of the probe call.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/e440118511cbdbe1d88eb0d71c9047116feb96e0.1769012464.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
