| Age | Commit message (Collapse) | Author |
|---|
|
Replace the kernel's own `transmute::FromBytes` and `AsBytes` traits
with their zerocopy equivalents. Specifically, this updates
`GenlMsg::put` to rely on `IntoBytes` for converting attributes into
byte slices.
Also, add `Immutable` trait bound on `GenlMsg::put` as zerocopy
splits the `no interior mutability` guarantee that `AsBytes` bundled
together.
Link: https://github.com/Rust-for-Linux/linux/issues/1241
Signed-off-by: Sagar Taunk <sagartaunk@proton.me>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260915144231.31932-1-sagartaunk@proton.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Paolo Abeni:
"Including fixes from Netfilter, Bluetooth, IPSec and WiFi.
Previous releases - regressions:
- netfilter: hold reference on ct until flow is released
- bridge:
- move switchdev call outside rcu
- vlan: fix bugs caused by switchdev deletion errors
- wifi:
- mac80211: reset state when starting AP fails
- cfg80211: don't free driver-owned scan requests
- tcp: don't call skb_clone_and_charge_r() for close()d listener in
tcp_v6_do_rcv()
- mptcp: return sk_wait_data() errors from recvmsg()
- xfrm: serialize state GC with device state flush
- drop_monitor: synchronize tracepoint unregistration on error path
- bluetooth:
- eir: validate service data length before reading UUID
- hci_sync: serialize local codec list cleanup
- RFCOMM: avoid socket lock inversion in listener cleanup
- eth:
- lan743x: fix RX checksum use-after-free
- mvpp2: prevent buffer overflow in page_pool allocation
Previous releases - always broken:
- core: lock the socket in sock_gettstamp()
- neighbour: enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.
- sched: codel: bound the dropping loop per dequeue call
- wifi: mac80211: include TIM bitmap control for buffered S1G mcast
traffic
- psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
- xfrm: fix stack OOB read in iptfs_skb_reset_frag_walk()
- bluetooth: hci_qca: do not write to the serial port after it is
closed
- dsa: mxl862xx: disable the stats poll on teardown
- eth:
- stmmac: fix TSO header length truncation
- ip_tunnel: initialize `options_len` before referencing options"
* tag 'net-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (159 commits)
mptcp: fix bad accounting in __mptcp_subflow_push_pending()
mptcp: close race between scheduler and state change
mptcp: avoid unneeded actions on subflow reset
net: skbuff: do not leave stale header offsets after pskb_carve()
selftests: net: packetdrill: test exclusion of old ACK from TCP fast path
tcp: exclude old ACKs from tcp fast path
dpll: reject a reference sync pin which is not on the pin's dpll
net: mvpp2: prevent buffer overflow in page_pool allocation
net: macb: fix ordering around PTP timestamp read
selftests: drv-net: psp: test PSP and TCP ULP mutual exclusion
net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
net: stmmac: preserve real_num_tx_queues on mqprio setup failure
net: stmmac: propagate FPE preemption-class mapping errors
net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb()
net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value
net: wwan: mhi_wwan_mbim: guard against a cyclic NDP chain
net: ethernet: cortina: Ack RX overrun interrupt correctly
net: lock the socket in sock_gettstamp()
eth: fbnic: ring the doorbell if a burst ends in a drop
net: netsec: fix device_node reference leak on phy_np
...
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-next
amd-drm-next-7.4-2026-09-10:
amdgpu:
- Freesync fixes
- GPUVM fix
- Debugfs fixes
- HDMI updates
- IPS fix
- GPU reset fix
- RGB quantization fixes
- SMU 13.0.x fixes
- MES updates
- UserQ updates
- UVD fix
- Various bounds checks
- DML fixes
- DCN 6 updates
- NBIO 7.11.5 support
- Audio fixes
- More display KUnit tests
- SMU 15 updates
- RAS updates
- VCN 5.0.2 updates
- JPEG 5.0.2 updates
- DCN 4.2 updates
- PSR fixes
- Misc cleanups
- PSP 15.0.8 updates
- RAS BERT support
- RAS CPER updates
- vblank fixes
- LSDMA updates
- GC 12.1 updates
- MMHUB 4.2 updates
- NBIO 6.3.2 updates
- SMU 15.0.8 updates
- IP discovery updates
- GPU spatial partitioning updates
- HDMI 2.1 freesync support
- HDMI 2.1 ALLM support
- HDMI 2.1 VRR support
- Require jobs for IBs
- Enable FRL for HDMI
- MES oversubscription fixes
- IH 6-7 updates
- GMC 11-12 fault handling updates
- Fixed point cleanup
- Backlight fixes
- GPUVM cleanup
- Devcoredump fixes
- UALoE (UALink over Ethernet) Support
- SDMA userq fixes
- GC 8 fix
amdkfd:
- Various bounds checks
- SVM fixes
- GC 12.1 updates
- MES updates
- Trap handler fixes
- Debugfs fixes
drm:
- Add gem callback for when handle count goes to 0
- Rust fix
UAPI:
- INFO IOCTL fix for 32 bit userspace on 64 bit kernel
- Add syncobj_points to USERQ signal ioctl
Proposed userspace:
* radeonsi NV_timeline_semaphore
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37335
* RADV user queues
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40808
- Add UALink support IOCTLs
Proposed userspace:
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L971
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L1036
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260910213040.826425-1-alexander.deucher@amd.com
|
|
Move drm_plane_helper_display_panic_screen() and the existing panic-
display code into drm_panic_helper.c. Rename symbols accordingly.
Also update the QR-related code and the bindings accordingly.
Link the rsp. object file into drm_kms_helper.ko. Eventually the code
will become a DRM drawing library, together with DRM's format and draw
helpers. This requires more preparation. until then, KMS helpers serve
as a module. All DRM drivers link it anyway.
Add a new section about drawing helpers to the documentation of the KMS
helpers. List format and panic helpers there.
v2:
- fix dependencies on other DRM modules (Randy, Sashiko)
- provide placeholders for drm_panic_helper_{init,exit}() (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260911124540.279841-14-tzimmermann@suse.de
|
|
The hand-written bitfield offsets in is_link_up(), is_autoneg_enabled()
and is_autoneg_completed() were correct when the abstraction was
merged: at that time autoneg, link, and autoneg_complete were at bits
13, 14, and 15 of struct phy_device's first bitfield unit. Commit
2796ff1e3dca ("net: phy: add flag is_genphy_driven to struct phy_device")
later inserted is_genphy_driven just before autoneg, shifting the three
fields up by one, so the accessors now read:
is_link_up() reads bit 14 = autoneg
is_autoneg_enabled() reads bit 13 = is_genphy_driven
is_autoneg_completed() reads bit 15 = link
The official ax88796b Rust driver uses all three accessors in its
read_status() implementation, so it inherits the bug.
phy_attach_direct() sets is_genphy_driven only when it falls back to
the generic driver, and ax88796b has a real driver, so
is_genphy_driven stays 0. The broken is_autoneg_enabled() therefore
reads bit 13 as 0, compares it against AUTONEG_ENABLE (1), and always
returns false, so read_status() never reaches the
resolve_aneg_linkmode() call.
The ordinary bindgen accessors take &self. Calling them through
(*phydev).link() would create a shared reference to the complete
bindings::phy_device, which is not appropriate for an object wrapped in
Opaque.
Use the bindgen-generated raw accessors (link_raw(), autoneg_raw(),
and autoneg_complete_raw()) instead. They retain the bit positions and
endianness handling generated from the C layout without creating a Rust
reference to the complete phy_device. Drop the hand-written numbers
together with the TODO comment that marked them as a stopgap.
The raw accessors are only emitted by bindgen 0.71 and later, and were
added at the Rust-for-Linux project's request, so this fix can only be
backported to stable branches whose minimum bindgen version is at least
that, hence the scope on the Cc: stable line below.
Found by a static equivalence audit (C2RustDrv, a C-to-Rust driver
migration tool) that compares hand-written bitfield offsets against
the bindgen layout of struct phy_device. Verified by building the
bindings and checking the generated accessors; no runtime testing was
possible without PHY hardware.
Fixes: 2796ff1e3dca ("net: phy: add flag is_genphy_driven to struct phy_device")
Cc: stable@vger.kernel.org # Only 7.1.y and later (requires bindgen's raw pointer accessors).
Link: https://github.com/rust-lang/rust-bindgen/issues/2674
Signed-off-by: Chunfeng Song <springbreeze@stu.pku.edu.cn>
Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20260910055110.167110-1-springbreeze@stu.pku.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
A tuple struct whose fields are all set to a value reads better written
like a call to its constructor than with the indices spelled out:
pin_init!(Foo(value, value))
Parse the two forms into separate types and rewrite the constructor
arguments into the indexed fields they are shorthand for, so that only the
parser has to know about the second form.
The arguments have no names, so they cannot use `<-`. Parse it anyway and
reject it afterwards, which reports the position of every offending `<-`
rather than stopping at the first one.
`cfg` needs different treatment for tuple constructor syntax. As non-derive
proc macros are invoked before cfg is resolved, the macro cannot know
whether a field survives, and dropping a tuple field renumbers every field
after it. That cannot be expressed by attaching a `cfg` attribute to the
initializer of a single field. Thus, resolve tuple field cfgs up front
instead, by generating two cfg-gated invocations of the macro with one
field resolved in each. This is the approach of commit 5bbf2b2deb94 ("rust:
pin-init: internal: rework how `#[pin_data]` handles cfg"), and it is
linear time because only one of the two branches is ever expanded. Struct
expression syntax do not renumber, so using tuple structs with struct
syntax can keep using the existing attribute-based handling.
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://github.com/Rust-for-Linux/pin-init/pull/165
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
[ Pre-expand cfgs for tuple init syntax. Use generics instead of separate
types for normalization - Gary ]
Co-developed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260904-tuple-struct-v1-4-72c50bd037fd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
|
|
Extend the initializer syntax so that a field can be named by an index,
addressing tuple struct fields the same way a struct expression does:
pin_init!(Foo { 0: value, 1 <- initializer })
Tuple fields are not exposed by a `let` binding to the fields after them,
since they have no name to bind; `_0` would shadow a user variable.
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
[ Fixed incorrect index calculation and cleaned up the code - Gary ]
Link: https://patch.msgid.link/20260904-tuple-struct-v1-3-72c50bd037fd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
|
|
`#[pin_data]` rejects tuple structs because it assumes every field has a
name, which it uses for the projection field, the `__Unpin` field and the
pin-data accessor.
Identify fields by `syn::Member` instead, so that tuple fields are referred
to by their index in generated field accesses. The names that generated
items still need are derived from the index as `_0`, `_1`, etc.
The projection of a tuple struct is a tuple struct itself, so projected
fields are accessed with the same `.0`, `.1` syntax as on the input
type rather than through synthesised names.
Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
[ Moved utility code to util.rs as extension trait - Gary ]
Link: https://patch.msgid.link/20260904-tuple-struct-v1-2-72c50bd037fd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
|
|
Create a new `util.rs` to host utility code that are generic and can be
shared by multiple macros.
Link: https://patch.msgid.link/20260904-tuple-struct-v1-1-72c50bd037fd@garyguo.net
Signed-off-by: Gary Guo <gary@garyguo.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Work around a 'bindgen' 0.73.2 bug that emits an 'allow' attribute
for 'unnecessary_transmutes', which is unknown in older compilers
- Clean 'clippy::as_underscore' lints in generated code by the new
'bindgen' 0.73.0+ releases
- Clean new 'clippy::needless_range_loop' lint for the upcoming Rust
1.100.0 (expected 2026-11-12)
'kernel' crate:
- 'num' module: fix soundness issue in 'Bounded' by sealing the
'Integer' trait
'pin-init' crate:
- Fix unreachable warning for the upcoming Rust 1.100.0 (expected
2026-11-12) due to 'Infallible' becoming an alias of '!'
Samples:
- Add missing newlines in 'pr_*!'s macro calls"
* tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: allow `unknown_lints` in generated bindings for Rust < 1.88
rust: allow `clippy::as_underscore` in the generated bindings
rust: num: seal Integer
drm/panic: clean new `clippy::needless_range_loop` lint for Rust 1.100.0
rust: samples: add missing newlines in rust_print_main
rust: pin-init: use irrefutable pattern for `stack_pin_init`
|
|
`DeviceId::new()` copies `modname` and `name` into the fixed 40-byte
`auxiliary_device_id::name` array without checking that they fit. An
oversized name is caught by the array bounds check, but the error
reports an out-of-bounds index in the copy loop rather than the
constraint the caller violated.
Check the invariant explicitly instead, so the failure states the length
limit rather than an array index.
This should only be reached when constructing a device ID table, so the
failure is a compile time error. Document that intent.
Signed-off-by: Georgios Androutsopoulos <georgeandrout13@gmail.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260910153844.3987791-1-georgeandrout13@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a `Device::resource_flags()` method to the PCI Rust abstraction,
wrapping the C-side static inline `pci_resource_flags()`.
The flags returned correspond to the `IORESOURCE` bitmask carried by a
PCI BAR's `struct resource`.
The immediate motivation is BAR layout discovery on NVIDIA GPUs: a
64-bit BAR consumes two consecutive Linux PCI resource slots (the lower
32 bits at index N and the upper 32 bits at index N+1, with the latter
having no flags or size of its own).
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260908-pci-resource-flags-v1-1-269f29f81de6@nvidia.com
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
|
|
The C maple_tree struct contains a *mut c_void, which prevents Rust from
auto-deriving Send/Sync. Following is an example error message when
using MapleTree in nova-core's Vmm.
This propagates up through MapleTreeAlloc to Vmm, BarUser, Gpu, and
NovaCore, causing NovaCore to fail the Send bound required by
pci::Driver:
error[E0277]: `*mut c_void` cannot be sent between threads safely
--> drivers/gpu/nova-core/driver.rs:77:22
|
77 | impl pci::Driver for NovaCore {
| ^^^^^^^^ `*mut c_void` cannot be sent between threads safely
|
= help: within `MapleTreeAlloc<()>`, the trait `Send` is not implemented for `*mut c_void`
note: required because it appears within the type `kernel::bindings::maple_tree`
note: required because it appears within the type `Opaque<kernel::bindings::maple_tree>`
note: required because it appears within the type `MapleTree<()>`
note: required because it appears within the type `MapleTreeAlloc<()>`
= note: required for `Box<MapleTreeAlloc<()>, Kmalloc>` to implement `Send`
note: required because it appears within the type `core::pin::Pin<Box<MapleTreeAlloc<()>, Kmalloc>>`
note: required because it appears within the type `Vmm`
note: required because it appears within the type `BarUser`
note: required because it appears within the type `Gpu`
note: required because it appears within the type `NovaCore`
note: required by a bound in `kernel::pci::Driver`
--> rust/kernel/pci.rs:294:19
Implement Send and Sync for MapleTree. The tree contains no thread-local
state, and all shared access goes through the internal ma_lock spinlock.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
[ecourtney: also require T: Sync for the Sync impl]
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Liam R. Howlett (Oracle) <liam@infradead.org>
Link: https://patch.msgid.link/20260908-maple-tree-send-sync-v2-1-24aae5b3a990@nvidia.com
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
|
|
All types in `bindings` implement `Zeroable` if they can, so use
`pin_init::zeroed` instead of relying on `unsafe` code.
If this ends up not compiling in the future, something in bindgen or on
the C side changed and is most likely incorrect.
Link: https://lore.kernel.org/r/20250814093046.2071971-8-lossin@kernel.org
Link: https://github.com/Rust-for-Linux/linux/issues/1189
Signed-off-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Nils Lehnen <nils.lehnen@proton.me>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
[PM: subject tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
|
|
When the commit b67d2d039f64 ("drm/gem: Add callback for when handle
count goes to 0") added the handle_free callback, it did not update the
rust abstraction, which will cause a build failure when that is enabled.
Rather than just adding another None initializer, use
..pin_init::zeroed() to make all unlisted callbacks None, and remove the
existing zero-initializations.
Fixes: b67d2d039f64 ("drm/gem: Add callback for when handle count goes to 0")
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Closes: https://lore.kernel.org/all/aaef18cd-ab55-4fb8-8563-ca3a5ea9cbc6@leemhuis.info
Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
Closes: https://lore.kernel.org/all/4da62a4b-c4ef-492a-9a27-b56bd4784acf@suse.de
Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Klara Modin <klarasmodin@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The dma_fence abstractions added by commit 3282d5916019 ("rust: Add
dma_fence abstractions") are compiled unconditionally, but the C
`dma_fence_*` symbols they reference live in
drivers/dma-buf/dma-fence.c, which is only built when
CONFIG_DMA_SHARED_BUFFER=y. Kernels with CONFIG_RUST=y and
CONFIG_RUST_KERNEL_DOCTESTS=y but CONFIG_DMA_SHARED_BUFFER=n fail
to link:
ld.lld: error: undefined symbol: dma_fence_release
>>> referenced by usercopy_64.c
>>> vmlinux.o:(rust_helper_dma_fence_put)
... dma_fence_signal{,_locked}, dma_fence_context_alloc,
dma_fence_init, dma_fence_{add,remove}_callback ...
Wrap the dma_fence.c helper include in the same
`pub mod dma_buf;` in rust/kernel/lib.rs with a matching #[cfg].
Fixes: 3282d5916019 ("rust: Add dma_fence abstractions")
Signed-off-by: Edwin Peer <epeer@nvidia.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260909202327.33285-1-epeer@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Starting with bindgen 0.73.2 [1], `#[allow(unnecessary_transmutes)]`
are used, even when `--rust-target 1.85` is passed.
However, the lint was introduced in Rust 1.88.0. Thus building with
older Rust versions warns like:
error: unknown lint: `unnecessary_transmutes`
--> rust/uapi/uapi_generated.rs:26294:13
|
26294 | #[allow(unnecessary_transmutes)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: `-D unknown-lints` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unknown_lints)]`
Thus allow `unknown_lints` in the generated bindings -- only when building
with older Rust versions.
I have asked upstream if this is intentional [1], i.e. if we are supposed
to always allow unknown lints in case `bindgen` uses such attributes,
or whether it is an oversight.
[ Emilio said it wasn't intentional -- we will work around it for now
on the kernel side. - Miguel ]
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Cc: Emilio Cobos Álvarez <emilio@crisal.io>
Link: https://github.com/rust-lang/rust-bindgen/pull/3455#issuecomment-5588526559 [1]
Assisted-by: LLM
Link: https://patch.msgid.link/20260908170539.345207-1-ojeda@kernel.org
[ Removed the `cfg` for `allow(unnecessary_transmutes)` as suggested by
Gary. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next
rust: dma: tie DMA allocations to the device's bound lifetime
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Add lifetime parameters to the
DMA allocation types (Coherent, CoherentBox, CoherentHandle) to enforce
at compile time that they are freed before the device is unbound.
Since DMA types with lifetime parameters are exposed through debugfs in
the nova-core driver, first drop the unnecessary T: 'static bound from
the debugfs ScopedDir file creation methods by formalizing a type
invariant on FileOps.
This is a stable tag for other trees to merge.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
lifetime"
Danilo Krummrich <dakr@kernel.org> says:
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Add lifetime parameters to the
DMA allocation types (Coherent, CoherentBox, CoherentHandle) to enforce
at compile time that they are freed before the device is unbound.
Since DMA types with lifetime parameters are exposed through debugfs in
the nova-core driver, first drop the unnecessary T: 'static bound from
the debugfs ScopedDir file creation methods by formalizing a type
invariant on FileOps.
Link: https://patch.msgid.link/20260830193824.471089-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
DMA fences are synchronisation primitives that will be needed by all
Rust GPU drivers.
The dma_fence framework sets a number of rules, notably:
- fences must only be signaled once
- all fences must be signaled at some point
- fence error codes must only be set before signaling
- every pointer to a fence must be backed by a reference
All those rules are being addressed by these abstractions.
To cleanly decouple fence issuers and consumers, two types are provided:
- DriverFence: the only fence type that can be signaled and that
carries driver-specific data.
- Fence: the fence type to be shared with other drivers and / or
userspace. The only type callbacks can be registered on.
Cannot be signaled.
Hereby, a Fence lives in the same chunk of memory as a DriverFence. Both
share the refcount of the underlying C dma_fence. Since this
implementation does not provide a custom dma_fence_backend_ops.release()
function, the memory is freed by the dma_fence backend once the refcount
drops to 0.
To create a DriverFence, the user must first allocate a
DriverFenceAllocation, so that the creation of the DriverFence later on
can always succeed. Otherwise, deadlocks could occur if fences need to
be created in a GPU job submission path.
Synchronization is ensured by the dma_fence backend.
All DriverFence's created through this abstraction must be signaled by
the creator with an error code. In case a DriverFence drops without
being signaled beforehand, it is signaled with -ECANCELLED as its
error and a warning is printed. This allows the Rust abstraction to very
cleanly decouple fence issuer and consumer by relying on the decoupling
mechanisms in the C backend, which ensures through RCU and the
'signaled' fence-flag that dma_fence_backend_ops functions cannot
access the potentially unloaded driver code anymore.
Signalling fences on drop thus grants many advantages. Not signaling
fences on drop would risk deadlock and does not grant real advantages:
By definition only the drivers can ensure that a fence always represents
the hardware's state correctly.
This implementation models a DmaFenceContext object on which fences are
to be created, thereby ensuring correct sequence numbering according to
the timeline.
dma_fence supports a variety of callbacks. The mandatory callbacks
(get_timeline_name() and get_driver_name()) are implemented in this
patch. For convenience, they store those name parameters in the fence
context, saving the driver from implementing these two callbacks.
Support for other callbacks (like for hardware signaling) is prepared
for through the fact that both DriverFence and Fence live in the same
allocation, allowing for usage of container_of from the callback to
access the driver-specific data.
It is expected that other callbacks, added in the future, also mostly
operate on the generic data in the FenceContext. To make this safe, the
implementation ensures through a lifetime that a DriverFence cannot
outlive its FenceContext.
Synchronization for dma_fence_ops callbacks is ensured by only running the
Rust deconstructor delayed with call_rcu(), which prevents UAF-bugs
should a DriverFence drop while a Fence callback is currently operating
on the associated driver data. Since they can also operate on the
FenceContext's data, its drop implementation also performs the necessary
delay with rcu_barrier().
An additional issue discovered during the review process of this code is
that there is (currently) no mechanism in Rust to prevent someone from
circumventing the DriverFence's FenceContext-reference's lifetime by
"forgetting" the fence, e.g. with core::mem::forget(). This would enable
UAF bugs on the FenceContext. Throw a panic if this happens and document
a path towards a more robust solution.
Add abstractions for dma_fence in Rust.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://patch.msgid.link/20260905085343.1827305-3-phasta@kernel.org
[ In dma_fence_callback(), split combined unsafe block into separate
blocks for container_of!() and pointer dereference. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add a compile-time checked variant of `try_cast()` using the minimum size
and alignment information.
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260805-typed_register-v2-1-c3ca142220a0@garyguo.net
[ecourtney: fix the doc example type and doc grammar per v2 review]
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-5-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
A CLIPPY=1 build emitted about 15000 `as _` conversion warnings, all of
them in bindgen's generated output and none in hand-written code.
[ The lint messages look like:
error: using `as _` conversion
--> rust/bindings/bindings_generated.rs:18947:9
|
18947 | self._bitfield_1.get_const::<0usize, 16u8>() as u32 as _
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-
| |
| help: consider giving the type explicitly: `u32`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#as_underscore
= note: `-D clippy::as-underscore` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::as_underscore)]`
- Miguel ]
bindgen 0.73 returns each bitfield read through a trailing `as _`, and
0.72 returns it through a transmute, which the lint ignores. The
bindings and uapi crates allow `clippy::all` over the generated code.
That group does not cover `clippy::as_underscore`, a restriction lint.
Allow `clippy::as_underscore` by name in the bindings and uapi crates.
Assisted-by: LLM
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260906215822.1201022-1-jhubbard@nvidia.com
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
[ Removed CI sentence. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Move the `FixedRegister` from a property of register to become a property
of type. Name the new trait `FixedIoLoc` indicating if I/O location of a
type is unique for a specific base. Thus, bitfields become just a special
case of this (where type is unique because we're generating it in the
register macro), and expose feature to registers without inline bitfield
definition with the `#[unique]` attribute.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-16-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
With the removal of relative registers, there are only two type of
registers left, fixed register and register arrays. There is not much
benefit in having a common super trait for them anymore, thus remove it,
and cleanup the macro rules associated with it.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-15-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Relative registers can be better served by projection to subregion instead
of ad-hoc handling in register macro. Projection composes better (e.g. it
natively allows relative registers of relative registers without needing
additional support).
Remove relative register support, and update the documentation to
demonstrate how projection and subregions can be used to achieve this
instead.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-14-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a rule to allow creating `IoLoc` in `register!()` using an existing
type and not create a bitfield. Add an example to demonstrate this for FIFO
registers.
This rule is also going to be used to create subregions for registers; the
example of doing so will be added later when relative registers are
removed.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-11-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Previously `register!` defined registers can be used on any untyped I/O
regions. With all users specifying their desired register type now,
propagate the specified type and restrict I/O access only when type
matches.
Also, add an `io_project!` example which is enabled by this change.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-10-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently registers work for all untyped I/O regions, which is not ideal.
It allows registers defined for device A to work for another device B and
there is no safeguarding at all.
All users of the `register!` macro know what type it will be operating on,
and that type is consistent across the driver. Therefore, add a `base`
parameter to `register!`.
Currently this parameter is unused in the generated code; it will be used
when all users of `register!` is converted to gain the parameter.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-6-5552b1d59525@garyguo.net
[ Remove unnecessary #[allow(unused)] from the 'base' field. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
`IoLoc`s themselves just describe a projection from a region to a
concrete register. Thus, support it in `io_project` macro too. Also,
update methods that operate on `IoLoc` to use I/O projection.
Documentation of `io_project!` is not expanded yet as the example works
better when `register!` type can specify base type. `io_read!` and
`io_write!` gains the ability to operate on registers as corollary of
the capability of `io_project!`. Examples are not added because `read`
and `write` is still preferably used instead.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-5-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
For types that are layout-compatible with an I/O capable type, we would
want the ability to use them directly for I/O operations. E.g.
bitfield! {
pub struct Foo(u32) {
...
}
}
#[repr(C)]
struct Bar {
foo: Foo,
}
let mmio: Mmio<'_, Bar> = ...;
io_read!(mmio, .foo)
Currently this feature is available from `register!()` macro but not
otherwise available with `io_read!`, `io_write!`. Support this by
performing conversions to I/O primitives via the `AsRepr`/`AsReprMut`
trait.
This makes the `IoLoc::IoType` and `Register::Storage` redundant; thus
remove them; also convert register methods to use the `read_val` and
`write_val` instead.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-4-5552b1d59525@garyguo.net
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Some API like atomics and I/O operate on primitives only; therefore other
types would need to converted to these primitive first. Add two traits
`AsRepr` and `AsReprMut` to indicate that the type can be turned into a
primitive for these operations.
`T: AsRepr` means that `&T` can be viewed as `&T::Repr` and thus it needs
to support transmutability in one direction. `T: AsReprMut` means that
`&mut T` can be viewed as `&mut T::Repr` and thus it needs to support
bi-directional transmutability.
To avoid duplicating implementations, all repr types are normalized to
unsigned integers.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20260901-typed_register-v4-3-5552b1d59525@garyguo.net
[ Fix grammar in from_repr_unchecked() documentation, rephrase confusing
safety comment, use rustdoc links for Self, fix backtick formatting in
comments and use consistent 'must' wording in safety sections.
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Implement a `transmute/safe_transmute` that checks size at
monomorphization time instead of type-checking time. This allows more cases
where we know that the size matches but this is not generically checkable.
The signature is equivalent to the unstable `transmute_neo` function in the
standard library. A safe variant is provided to use with types implementing
`FromBytes` and `IntoBytes`.
Existing users of `transmute_copy` to bypass size checks are converted.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20260901-typed_register-v4-2-5552b1d59525@garyguo.net
[ Fix doc heading to use plural "Examples", add missing closing code
block delimiter and fix a few other nits. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Bounded relies on Integer implementations to describe primitive integer
semantics correctly. In particular, it uses Integer::BITS and Signedness
to justify unchecked operations.
Integer is currently safe and externally implementable, so an
implementation can violate those assumptions and make safe Bounded
operations reach undefined behavior.
For example, an Integer implementation for a u8 wrapper can report
BITS = 16. Safe code can then cast a Bounded<u16, 9> containing 256
to that wrapper. Its TryFrom<u16> implementation returns Err, and
Bounded::cast() calls unwrap_unchecked() on it, causing undefined
behavior.
Seal Integer so only the primitive implementations provided by the
kernel crate can satisfy it.
Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type")
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/rust-for-linux/CANiq72mOfR33s4y+Ueivd5NrC5yre+Pcp57ZOBz0msw9A4AP1Q@mail.gmail.com/
Cc: stable@vger.kernel.org
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Younes Akhouayri <git@younes.io>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260905-feature-rust-num-seal-integer-v2-1-f1311ffbe6e7@younes.io
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Add a lifetime parameter to Coherent and CoherentBox that ties the DMA
allocation to the device's bound scope, ensuring it is freed before the
device is unbound.
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Without a lifetime parameter,
there was no compile-time enforcement that a Coherent or CoherentBox is
dropped before the device is unbound.
Propagate the new lifetime parameter through all users.
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260830193824.471089-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a lifetime parameter to CoherentHandle that ties the DMA allocation
to the device's bound scope, ensuring it is freed before the device is
unbound.
DMA allocations carry device resources (e.g. IOMMU mappings) that must
not outlive the device's bound lifetime. Without a lifetime parameter,
there was no compile-time enforcement that a CoherentHandle is dropped
before the device is unbound.
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260830193824.471089-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Drop the T: 'static bound from ScopedDir's file creation methods
(read_binary_file(), read_only_file(), etc.) to support registering
debugfs files backed by types that contain non-'static references, such
as dma::Coherent<'a, T>.
The previous 'static bound existed because ScopedDir::create_file() took
&'static FileOps<T>, and &'static requires T: 'static for well-
formedness. However, this was overly conservative: the file_operations
pointer passed to the C debugfs API just needs to be 'static, not the
entire FileOps<T>.
Store &'static bindings::file_operations in FileOps<T> instead of the
file_operations by value. In each trait impl, take a reference to the
file_operations struct within the const block; since
bindings::file_operations does not mention T, the reference is promoted
to 'static regardless of T's lifetime parameters.
Replace the Deref impl with an explicit fops() method that returns the
stored &'static reference.
Link: https://lore.kernel.org/driver-core/20260830193824.471089-2-dakr@kernel.org
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260830193824.471089-2-dakr@kernel.org
[ Remove unrelated change from Self to T. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The existing `register!` macro is implemented as a declarative macro.
Reimplement it as proc macro instead, with no functional changes intended.
The old implementation produces unhelpful diagnostics when things go wrong.
For example, for code like
register! {
pub(crate) TESTREG(u32) {
31:0 data;
}
}
which misses out the "@ offset" part of the specification, and the
following error is produced:
error: no rules expected `{`
--> test.rs:42:5
|
42 | / register! {
43 | | pub(crate) TESTREG(u32) {
44 | | 31:0 data;
... |
100 | | }
| |_____^ no rules expected this token in macro call
which isn't very helpful. With the proc macro implementation, the following
error is produced:
error: expected `@` or `=>`
--> tests.rs:43:33
|
43 | pub(crate) TESTREG(u32) {
| ^
which is much more helpful. Apart from diagnostics, proc macro also has a
benefit of not having follow-set restrictions, which makes syntax like
register!(name: ty @ offset);
possible; declarative macro will reject this as `@` is not in the
follow-set of "ty" metavariable kind.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-typed_register-v4-1-5552b1d59525@garyguo.net
[ Fix typo in module-level doc comment and fix ArrayDef syntax
description to match the actual macro syntax. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
IrqVectorRegistration::index() accepts a usize, but pci_irq_vector()
takes an unsigned int. On 64-bit architectures, casting an index larger
than u32::MAX wraps it before the PCI core can validate it. In
particular, u32::MAX + 1 becomes zero and can resolve to the first
allocated vector.
Use a checked conversion and return EINVAL when the index cannot be
represented by the C API.
Fixes: 2fb7755b0a7e ("rust: pci: resolve IRQ in index() and embed IrqRequest in IrqVector")
Signed-off-by: Sophon Zhang <aiqubits@hotmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260901-fix-pci-irq-vector-index-truncation-v4-1-f94aa6932fd9@hotmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
In Rust 1.100.0, `Infallible` will become an alias of `!`. The let
binding in `stack_pin_init` will thus become unreachable and produce
an "unreachable expression" warning for the subsequent match, and thus
will fail a `-Dwarnings` build. For this macro, all we need to know is
that the error type is uninhabited, so replace this with an irrefutable
pattern instead.
[ The error looks like (dummy reproducer):
error: unreachable expression
--> rust/kernel/sync.rs:177:5
|
177 | pin_init::stack_pin_init!(let num = 42u32);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| unreachable expression
| any code following this expression is unreachable
|
= note: `-D unreachable-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unreachable_code)]`
= note: this error originates in the macro `pin_init::stack_pin_init` (in Nightly builds, run with -Z macro-backtrace for more info)
- Miguel ]
Reported-by: Mohamad Alsadhan <mo@sdhn.cc>
Closes: https://github.com/Rust-for-Linux/pin-init/pull/171
Signed-off-by: Gary Guo <gary@garyguo.net>
Cc: stable@vger.kernel.org # Needed in 7.1.y and later (for 6.12.y and 6.18.y a custom one is needed).
Link: https://patch.msgid.link/20260828155033.2101924-1-gary@kernel.org
[ Reworded for typos. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Fix KCFI failures, such as in Rust doctests, by disabling function
merging when CFI is enabled. Gary reported the LLVM bug to upstream
and it is now fixed in their mainline.
- Fix 'objtool' fallthrough warnings under the experimental
'CONFIG_RUST_INLINE_HELPERS' by passing (for the combined Rust and
helpers code) the LLVM options needed to preserve the unreachable
traps that 'rustc' normally emits.
In addition, fix 'objtool' errors when LTO is enabled on top, by
also filtering out the LTO flags (for the combined Rust and helpers
code) so that the traps are kept in place.
- Fix 'objtool' warnings by adding one more 'noreturn' function.
- Fix 'make rusttest' target when the 'rustc-dev' component is
installed and Rust >= 1.82.0, <= 1.87.0 is used.
'kernel' crate:
- 'num' module: fix soundness issue in the 'Bounded' conversion from
'bool' by restricting the conversions to unsigned 'Bounded'.
- 'jump_label' module: fix future 'make rusttest' target failures
when 'ARCH=' is set to an arch different than the host's.
- 'list' module: fix incorrect 'pop_back()' comment"
* tag 'rust-fixes-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: kbuild: disambiguate `zerocopy_derive` for `rusttest`
rust: num: restrict bool conversion to unsigned Bounded
kbuild: rust: keep Rust objects out of Clang LTO with inline helpers
kbuild: rust: preserve unreachable traps with inline helpers
rust: cfi: disable function merging if CFI is enabled
rust: jump_label: skip arch-specific asm in `testlib` builds
objtool/rust: add one more `noreturn` Rust function
rust: kernel: list: fix incorrect pop_back example comment
|
|
The `rustc-dev` components for Rust 1.82.0 through 1.87.0 include a
precompiled `zerocopy_derive` procedural macro in the sysroot. This
range includes Rust 1.85.0, our minimum supported version.
This makes `rusttest` fail because the compiler finds both the sysroot
copy and the copy built in `rust/test`:
error[E0464]: multiple candidates for `dylib` dependency `zerocopy_derive` found
--> rust/kernel/prelude.rs:70:9
|
70 | pub use zerocopy_derive::{
| ^^^^^^^^^^^^^^^
|
= note: candidate #1: .../lib/rustlib/x86_64-unknown-linux-gnu/lib/libzerocopy_derive-54d2b38896fa6bc5.so
= note: candidate #2: .../rust/test/libzerocopy_derive.so
Commit fe39a233ea52 ("rust: kbuild: disambiguate `zerocopy` for
`rusttest`") fixed the equivalent ambiguity for `zerocopy`.
Thus point to the dependency explicitly in this case too.
Cc: Antoni Boucher <bouanto@zoho.com>
Cc: stable@vger.kernel.org
Fixes: 506054980429 ("rust: zerocopy-derive: enable support in kbuild")
Link: https://patch.msgid.link/20260823193529.156066-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the big set of USB and Thunderbolt driver updates for 7.3-rc1.
Lots of driver work for new devices and systems, and many other minor
fixes and updates. Included in here are:
- Thunderbolt subsystem driver updates and additions
- typec driver updates and additions
- usb gadget fixes all over the place, seems like people are finally
paying attention to these drivers for some reason
- xhci driver updates and fixes based on lots of reports
- usb-serial driver updates and additions
- new device ids
- other minor USB driver updates and fixes
All of these have been in linux-next for a while with no reported issues"
* tag 'usb-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (163 commits)
usb: gadget: uvc: fix dangling pointers in uvc_function_bind() and uvc_function_unbind()
usb: typec: hd3ss3220: fix VBUS regulator error message
usb: usbfs: fix use-after-free of usb_device in usbdev_release()
usb: gadget: u_audio: Fix use-after-free on sound card disconnect
usb: dwc3: gadget: Fix use-after-free in dwc3_gadget_free_endpoints due to race condition
usb: gadget: f_tcm: keep port count until LUN teardown completes
usb: usbtest: disable dynamic ID support
usb: typec: tcpci: pass correct rx_type to tcpm_pd_receive()
USB: c67x00: fix use-after-free in c67x00_add_iso_urb()
usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion
usb: gadget: snps_udc_plat: clean up PHY on probe deferral
usb: gadget: f_tcm: fix deadlock in usbg_make_tpg()
usb: dwc2: gadget: Exit partial power down state when changing USB pull-up
usb: gadget: f_fs: Fix Use-After-Free in AIO error path
usb: gadget: f_fs: Prevent deadlock during ep0 read loop
usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed
usb: gadget: midi2: remove default configfs groups on teardown
usb: gadget: uvc: Fix null pointer dereference in uvcg_video_init()
usb: typec: thunderbolt: Disable work before freeing tbt on remove
usb: xhci: Handle bogus TRB pointers in Missed Service Error events
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc/IIO/etc driver updates from Greg KH:
"Here is the big set of char, misc, iio, counter, fpga, and other small
driver subsystems for 7.3-rc1.
Overall, due to some driver removals we only added a bit more code
than removed, which was a nice change. Highlights in this merge
request are:
- Loads of IIO driver updates and additions
- binder driver updates (more on that below...)
- Removal of the SGI XP and GRU drivers as they are not used anymore
and turn out to be pretty insecure overall
- Removal of the obsolete ibmasm driver as it's not being used
anymore
- Coresight driver updates and additions
- Mei driver udpates
- Counter driver updates
- FPGA driver updates
- ICC driver updates
- lots and lots of other tiny driver updates to resolve reported
issues
All of these have been in linux-next for a while"
* tag 'char-misc-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (513 commits)
iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF
iio: adc: pac1921: fix wrong channel used in trigger handler read
iio: light: gp2ap002: re-enable irq if runtime suspend fails
iio: light: gp2ap002: Fix unbalanced runtime PM on repeated event writes
iio: light: apds9306: fix PM reference leak in apds9306_read_data()
iio: gyro: mpu3050: fix sign of raw angular velocity readings
iio: srf04: fix pm_runtime handling on probe error path
iio: adc: ad4080: configure backend data size
iio: adc: adi-axi-adc: add data size support for AD408X backend
iio: chemical: atlas-sensor: fix PM reference leak in buffer postenable
iio: dac: ad5446: fix OF module device table
iio: light: opt4001: Fix reversed GENMASK() arguments in fault count mask
iio: light: opt4001: Reject integration times with a non-zero seconds part
iio: light: opt4001: Fix incompatible pointer type passed to div_u64_rem()
iio: light: opt4001: Fix power down clearing bits of the wrong register
iio: light: opt4060: Fix incorrect register name in threshold read error message
iio: light: opt4060: Fix pointer type passed to div_u64_rem()
iio: light: opt4060: Reject integration times with a non-zero seconds part
iio: light: ltrf216a: fix runtime PM reference leak in error path
iio: pressure: dps310: fix NULL pointer dereference on ACPI probe
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux
Pull more i2c updates from Andi Shyti:
"Fixes and cleanups around probe error handling, resource management
and a minor Rust cleanup.
Drivers:
- several drivers: drop duplicate IRQ error reporting
- imx-lpi2c: improve probe initialization and error cleanup
- mxs: fix DMA channel leak on probe failure
- ocores: fix clock cleanup on resume failure
- rcar: handle reset controllers without status support
Muxes:
- demux-pinctrl: fix OF node leak on allocation failure
Rust:
- mark trivial I2cAdapter reference-counting methods inline"
* tag 'i2c-7.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux:
i2c: rust: mark I2cAdapter methods as inline
i2c: rcar: fix reset handling for Gen5
i2c: mxs: fix DMA channel leak on probe error
i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure
i2c: ocores: Disable clock on failed resume
i2c: imx-lpi2c: reset controller in probe stage
i2c: imx-lpi2c: properly unwind resources on probe failure
i2c: busses: drop redundant dev_err_probe() around irq helpers
|
|
From<bool> turns true into 1. A signed Bounded with N = 1 can hold
only -1 and 0. The current implementation can therefore create a value
that breaks Bounded's invariant. Deref relies on that invariant and
calls unreachable_unchecked() when it is broken, so safe Rust can reach
undefined behavior.
The other primitive conversions require the source and destination to
have the same signedness. Treat bool as an unsigned one-bit value and
allow conversions between bool and Bounded only when the backing integer
type is unsigned.
Fixes: 01e345e82ec3 ("rust: num: add Bounded integer wrapping type")
Closes: https://lore.kernel.org/rust-for-linux/OzuVxu0--J-9@younes.io/
Cc: stable@vger.kernel.org
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Younes Akhouayri <git@younes.io>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260822-fix-rust-bounded-from-bool-submit-v4-1-aa780bfe7f30@younes.io
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux
Pull RCU updates from Paul McKenney:
"Make expedited grace periods expedite normal RCU callbacks
Miscellaneous fixes:
- Improve diagnostic output with character task states
- Mark accesses to inform KCSAN of concurrency design
- Move from kmalloc() to kmalloc_obj()
- Documentation updates
- Improve handling of RCU deferred quiescent states
- Clean up unused function arguments and structure fields
- Reduce show_rcu_gp_kthreads() stack space
Tasks RCU updates:
- Clean up after SRCU re-implementation of Tasks Trace RCU
- Mark accesses to inform KCSAN of concurrency design
- Add ->lazy_timer status to diagnostic output
- Remove an unnecessary memory barrier
- Fix a data race, courtesy of KCSAN
- Documentation updates
- Convert cond_resched_tasks_rcu_qs() from macro to static inline
function
SRCU updates:
- Add Rust helpers for SRCU
- Avoid losing queued work at cleanup_srcu_struct() time
Torture-test updates:
- Preparation work for immediate RCU priority deboosting
- Test RCU readers from real interrupt handlers (as opposed to
softirq)
- Simplify code through use of cpumask_next_wrap()
- Improve diagnostic output with character task states
- Add rcutorture.nwriters parameter to allow lightweight stall
testing, and rcutorture.stall_only to make doing so easier
- Test an RCU Tasks Trace grace period implying an RCU grace period
- Make RCU Tasks Trace torturing track reader batches
- Fix a data race, courtesy of KCSAN
- Plug a shuffle_tmp_mask memory leak on kthread spawn failure"
* tag 'rcu.2026.08.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux: (59 commits)
rcu: Add closing parenthesis in comment in rcu_read_unlock_strict()
rcutorture: Make {,s}rcu_read_delay() better handle forward-progress testing
rcutorture: Announce declining to forward-progress test
torture: Don't leak shuffle_tmp_mask when shuffler kthread fails to start
rcutorture: Use this_cpu_inc() for rcu_torture_count[] and rcu_torture_batch[]
rcutorture: Make RCU Tasks Trace track Reader Batches
rcutorture: Test RCU Tasks Trace GP implying RCU GP
rcutorture: Add a stall_only module parameter
rcutorture: Add nwriters module parameter
rcutorture: Use task_state_to_char() for task-state reporting
rcutorture: Use cpumask_next_wrap() in rcu_torture_preempt()
rcutorture: Test RCU readers from hardware interrupt handlers
rcutorture: Check for immediate deboosting at reader end
srcu: Queue sdp->work when the delay timer is successfully deleted
rcu-tasks: Convert cond_resched_tasks_rcu_qs() to static inline
rcu-tasks: Fix some comments for call_rcu_tasks() and call_rcu_tasks_rude()
rcu-tasks: Rename tasks_rcu_exit_srcu_stall_timer to tasks_rcu_exit_stall_timer
rcu: Mark interrupts-enabled accesses to rdp->cpu_no_qs.s
rcu: Reduce stack usage in show_rcu_gp_kthreads()
rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qs
...
|
|
Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit
`objtool` errors such as:
vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a:
can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd
The reason is that in such builds, the Clang invocation that compiles
the combined Rust plus helpers bitcode emits LLVM bitcode (again) --
the final code generation happens in the linker's LTO step, which the
`-mllvm` trap options passed to Clang do not reach.
This, in turn, means that unreachable traps are missing, and the
impossible paths do not merely fallthrough to the next symbol, but past
the end of their own section, since LTO builds place each function in
its own section.
Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always
emits machine code directly, with the traps in place.
Assisted-by: LLM
Cc: Gary Guo <gary@garyguo.net>
Cc: Boqun Feng <boqun@kernel.org>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Matthew Maurer <mmaurer@google.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit
`objtool` warnings like:
vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init()
falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_()
`rustc` normally emits traps for unreachable paths. However, under
`CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang
performs final code generation after the helper bitcode is linked,
but Clang does not trap unreachable IR by default.
In turn, this means `objtool` follows compiler-generated impossible Rust
`enum` paths through alignment padding into the next function, resulting
in fallthrough warnings.
Thus pass the LLVM `trap-unreachable` option to the final Clang invocation
and suppress traps immediately after `noreturn` calls, which `objtool`
already recognizes as dead ends. The combination of both flags makes it
match `rustc`'s behavior.
Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both
flags are available in LLVM 18.
Assisted-by: LLM
Cc: Gary Guo <gary@garyguo.net>
Cc: Boqun Feng <boqun@kernel.org>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Matthew Maurer <mmaurer@google.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260816133233.197500-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Running `make rusttest` with `ARCH=` set to an architecture other than
the host's may fail in the future, e.g. `ARCH=arm64` on an x86_64 host:
error: alignment must be a power of 2
--> rust/kernel/jump_label.rs:51:13
|
51 | include!(concat!(env!("OBJTREE"), "/rust/kernel/generated_arch_static_branch_asm.rs"));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: instantiated into assembly here
--> <inline asm>:3:10
|
3 | .align 3
| ^
The reason is that `rusttest` builds the kernel crate as a host
library: it passes the `CONFIG_*` cfgs of the configured architecture,
but not `--target`, so code generation happens for the
host. `arch_static_branch!` then selects the arch-specific inline asm
arm based on CONFIG_*, and the host assembler rejects it.
This does not happen with the current master because
`arch_static_branch!` has no user inside the kernel crate itself yet,
but fix it now to avoid surprises later.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20260809134858.1219036-1-tomo@flapping.org
[ Reworded slightly to clarify it "may fail in the future". - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
