| Age | Commit message (Collapse) | Author |
|---|
|
The flags argument to drm_dev_register() is only passed to the
deprecated .load() callback. Rust DRM drivers always set this callback
to NULL, so the argument has no effect.
Remove the argument from drm::Registration::new(), pass zero to
drm_dev_register(), and update the Nova and Tyr callers.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260929190024.2248099-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Convert drm::Registration to return an impl PinInit<Self, Error> rather
than creating a separate allocation. This removes an otherwise
unnecessary allocation.
Update both in-tree callers (nova, tyr) to construct their bus device
private data using try_pin_init!().
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260929190024.2248099-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Linux 7.3-rc6
This was requested by Thomas to have a new base to start some branch from
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Previously, the per-VMA locking could fail in the face of writers which
necessitate a fallback to mmap_lock. The new vma_start_read_unlocked()
will wait for writers instead of failing.
Use the new helper. Wait for writers. Remove the fallback to mmap_lock.
Link: https://lore.kernel.org/20260831203056.838265-5-surenb@google.com
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Carlos Llamas <cmllamas@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
|
|
Patch series "mm: Unconditional per-VMA locks and cleanups", v7.
tl;dr: Make per-VMA locks available in all configs. Simplify some of the
per-VMA lock users now that they can rely on them being always available.
Binder and networking folks: Your code is the target of the cleanups. I'm
cc'ing you now on v2 because there's emerging consensus on the mm side
that the approach here is sane. I'm not quite sure how this pile would
get merged, but ack/review tags would be appreciated if this looks good to
you.
Longer version:
When working on some x86 shadow stack code, it was a real pain to avoid
causing recursive locking problems with mmap_lock. One way to avoid those
was to avoid mmap_lock and use per-VMA locks instead. They are great, but
they are not available in all configs which makes them unusable in generic
code, or if you want to completely avoid mmap_lock.
Make per-VMA locks available in all configs. Right now, they are only
available on select architectures when SMP and MMU are enabled. But all
of the primitives that per-VMA locks are built on (RCU, maple trees,
refcounts) work just fine without SMP or MMU.
The only real downside is that making VMAs a wee bit bigger on !MMU and
!SMP builds.
The upside is much cleaner code, lower complexity and less #ifdeffery.
Clean up a binder VMA locking site now that it can rely on per-VMA locks.
Building on top of universally-available per-VMA locks, introduce a new
helper. Since the new API does not require callers to have a fallback to
mmap_lock, it's much easier to use. Callers can potentially replace this
very common kernel idiom:
mmap_read_lock(mm);
vma = vma_lookup()
// fiddle with vma
mmap_read_unlock(mm);
with:
vma = vma_start_read_unlocked(mm, address);
// fiddle with vma
vma_end_read(vma);
Which avoids mmap_lock entirely in the fast path.
Use that new API for another binder site and one in the TCP code.
This patch (of 7):
The per-VMA locks have been around for several years. They've had some
bugs worked out of them and have seen quite wide use. However, they are
still only available when architectures explicitly enable them. Remove
the conditional compilation around the per-VMA locks, making them
available on all architectures and configs.
The approach up to now seemed to be to add ARCH_SUPPORTS_PER_VMA_LOCK when
the architecture started using per-VMA locks in the fault handler. But,
contrary to the naming, the Kconfig option does not really indicate
whether the architecture supports per-VMA locks or not. It is more of a
marker for whether the architecture is likely to benefit from per-VMA
locks.
To me, the most important thing side-effect of universal availability is
letting per-VMA locks be used in SMP=n configs. This lets us use
per-VMA locking in all x86 code without fallbacks.
Overall, this just generally makes the kernel simpler. Just look at the
diffstat. It also opens the door to users that want to use the per-VMA
locks in common code. Doing *that* brings additional simplifications.
The downside of this is adding some fields to vm_area_struct and
mm_struct. There are likely ways to optimize this, especially for things
like SMP=n configs. For now, do the simplest thing: use the same
implementation everywhere.
== Considerations for NOMMU config ==
NOMMU systems do not write-lock VMAs, therefore read-locking a VMA would
always succeed unless VMA is detached. Therefore for NOMMU config we make
vma_mark_attached() a NOOP, which keeps VMAs always in detached state.
This causes VMA read-locking to always fail and the caller falls back to
locking mmap_lock.
The following functions will have a different implementation in NOMMU
config:
- vma_mark_attached(), vma_mark_detached() are made NOOPs, keeping VMAs
always in a detached state and preventing assertions and refcount
underflows;
- vma_start_write(), vma_start_write_killable() are made NOOPs to avoid
warnings in __vma_start_write() due to VMAs being detached. These
functions are not used in NOMMU code but __vma_start_write() is an
exported function, therefore might be used by drivers.
- vma_assert_attached() is made NOOP because it's reachable from NOMMU
code via split_vma()->vma_iter_store_new()->vma_iter_store_overwrite();
- vma_assert_write_locked() is asserting vma->vm_mm is write-locked, as
was done before this change;
- vma_assert_locked() is asserting vma->vm_mm is locked, as was done
before this change;
The following functions work for both MMU and NOMMU configs:
- vma_lock_init() performs the same initialization as for MMU config;
- mm_lock_seqcount_init(), mm_lock_seqcount_begin(),
mm_lock_seqcount_end() are called from mmap_write_{lock|unlock} and
update mm_lock_seq correctly.
- mmap_lock_speculate_try_begin(), mmap_lock_speculate_retry() work as
is because mm_lock_seq is updated correctly;
- vma_start_read(), vma_start_read_locked() will always fail because
VMAs are always detached;
- vma_end_read() will never be called because vma_start_read() never
succeeds;
- vma_is_attached() always return false because VMAs are always
detached;
- vma_assert_detached() will never trigger because VMAs are never
attached;
- vma_start_read_locked() always return false because VMAs are always
detached;
- lock_vma_under_rcu() will be safe as the attempted read lock will bail;
Changes in the following files are not affecting NOMMU config:
task_mmu.c - not compiled when CONFIG_MMU=n;
pagewalk.c - not compiled when CONFIG_MMU=n;
userfaultfd.c - not compiled when CONFIG_MMU=n (CONFIG_USERFAULTFD depends
on CONFIG_MMU);
The following changes in the BPF code are made to keep NOMMU config
working like before:
stack_map_lock_vma() - keeps mmap_lock in NOMMU config;
bpf_iter_task_vma_new() - bails out in NOMMU config;
Link: https://lore.kernel.org/20260831203056.838265-1-surenb@google.com
Link: https://lore.kernel.org/20260831203056.838265-2-surenb@google.com
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Carlos Llamas <cmllamas@google.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Arve Hjønnevåg <arve@android.com>
|
|
`next_bit()` and `next_zero_bit()` use `bitmap_assert!()` to check
that `start` is less than `self.len()`, which panics when
`CONFIG_RUST_BITMAP_HARDENED` is enabled. However, neither function
has a `# Panics` section, and both document that `None` is returned
for exactly the input that triggers the panic.
Update the documentation of `next_bit()` and `next_zero_bit()` to add
the missing `# Panics` sections, add the missing blank doc comment line
before `Returns` in `next_zero_bit()`, and simplify the wording.
Fixes: 11eca92a2cae ("rust: add bitmap API.")
Closes: https://github.com/Rust-for-Linux/linux/issues/1252
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Georgios Androutsopoulos <georgeandrout13@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
|
`find_unused_id()` calls `Bitmap::next_zero_bit()` and `release_id()`
calls `Bitmap::clear_bit()`, both of which panic when
`CONFIG_RUST_BITMAP_HARDENED` is enabled and the index is out of
bounds. Neither `IdPool` method documents this.
Add the missing `# Panics` sections and state the bounds requirement
on `offset` and `id`.
Fixes: 2cdae413cd3e ("rust: add dynamic ID pool abstraction for bitmap")
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Georgios Androutsopoulos <georgeandrout13@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
|
cpufreq_cpu_get() returns either a referenced policy or NULL.
PolicyCpu::from_cpu() passed its return value to from_err_ptr(), which
rejects ERR_PTR values but accepts NULL.
If the lookup fails, Policy::from_raw_mut() therefore constructs a mutable
reference from NULL. Dropping the resulting PolicyCpu then passes the
invalid pointer to cpufreq_cpu_put(), causing an oops in kobject_put().
Reject NULL with NonNull before constructing the Policy reference. Return
ENODEV instead.
A KUnit negative-control run reproduced the oops with the original
conversion. The same test passed with this change. The reproducer is
available on request.
Fixes: 6ebdd7c93177 ("rust: cpufreq: Extend abstractions for policy and driver ops")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Mehmet Koseoglu <mehmet.mkoseoglu@gmail.com>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: spidermana <xuyiwen14@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
The `diff` parameter is needed currently because doctests want to override
the line number. Simplify it by changing it to use `line!()`. Have doctests
override `line!()` macro to achieve the current behavior.
An existing doctest requires `line!()` to expand to a literal; so update
it to use `::core::line!()` instead.
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260902-kunit-v2-2-eda3ed6c00c5@garyguo.net
[ Removed spurious `///`-to-`//` change and adjusted `line!` to match.
Added a comment to match `file!`'s. Made `NOTE:` more precise. Reworded
to say it is only one doctest being updated. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
This parameter is needed currently because doctests want to override the
file. Simplify it by changing it to use `file!()`. Have doctests override
`file!()` macro to achieve the current behavior.
This allows us to remove the `file` helper and associated Kconfig options.
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260902-kunit-v2-1-eda3ed6c00c5@garyguo.net
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Replace the `build_error!(VTABLE_DEFAULT_ERROR)` boilerplate with the
`#[optional]` attribute.
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20260811-vtable_macro-v1-3-50c5aab3c211@garyguo.net
[ Reworded title for prefix. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Rust's `repr(align())` only works with integers. Add an `Align` type so it
can also be specified via const generics.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260610-const-align-v2-1-ccd12f0aedb7@garyguo.net
[ Adjusted the title of the new module to match the one used in patch
"rust: mem: add `transmute` with deferred size check" (landing via
driver-core), which is also closer to the upstream standard library
title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The kernel provides impl_flags! for declaring a bitmask type alongside
the enum of its individual flags, generating the bit operators and the
containment queries.
IrqTypes open-coded that pattern with a with() builder, so a caller
naming two interrupt types chained two calls onto IrqTypes::default().
Declare both types through impl_flags!, so the same set reads as
IrqType::Msi | IrqType::MsiX.
Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260930034148.590687-2-jhubbard@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
`ResourceSize` is a bare type alias for `resource_size_t`, so it
inherits every integer operation and `as` cast. That allows operations
that make no sense for the size of a hardware resource, such as mixing
it with unrelated integers or truncating it with a cast.
Wrap it in a `#[repr(transparent)]` newtype so each conversion at a
boundary is explicit. The representation is unchanged, so this is
ABI-identical; only the spelling at the FFI boundary changes. Provide
`from_raw`/`into_raw`, `From` in both directions, and a fallible
`TryFrom<ResourceSize> for usize`, since `resource_size_t` can be wider
than `usize` on 32-bit.
Update the producer, `Resource::size`, and its consumers in `Region`
and `request_region`.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1203
Signed-off-by: Lorenzo Delgado <lnsdev@proton.me>
Link: https://patch.msgid.link/20260927-resource-size-newtype-v4-2-447a08af23fb@proton.me
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
`SGEntry::dma_len()` returns `ResourceSize`, but the length of a DMA
segment is not the size of a resource. The C side stores it as an
`unsigned int` (`dma_length` in `struct scatterlist`), the helper
returns `unsigned int`, and a single segment is bounded by the
device's `max_segment_size`, which is an `unsigned int` as well. The
method only widens the value to `resource_size_t`.
Return `u32`, which is what the binding already produces, and drop the
`.into()` along with its `clippy::useless_conversion` allow.
Tyr widens the length to `u64`, which is now a real conversion on
every architecture, so drop its `useless_conversion` allow too.
nova-core converts it to `usize` through `FromSafeCast`, which already
covers `u32`, so it needs no change.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/DLNPXJ4WPH4L.2MBUGV1TAESYY@kernel.org
Signed-off-by: Lorenzo Delgado <lnsdev@proton.me>
Link: https://patch.msgid.link/20260927-resource-size-newtype-v4-1-447a08af23fb@proton.me
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The `#[allow(non_camel_case_types)]` was there because register names can
be commonly SCREAMING_CASE and thus not CamelCase. However, when a bitfield
type is created by itself, this justification does not apply. Thus, remove
it.
Users that want to use non-standard styles can add the `#[allow]`
themselves. For example, the invocation of `bitfield!` inside `register!`
macro carry this annotation.
Signed-off-by: Gary Guo <gary@garyguo.net>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260910170542.92010-1-gary@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The test runs warn_on!(false) and warn_on!(true) inside a KUnit warning
suppression block, then checks that one warning was counted. The counter
is incremented by the kernel warning path, not by warn_on! itself, so a
count of one means the warning was really reported.
warn_flags! has a different definition per architecture. The test does not
look at any of them, so it runs on every architecture that supports Rust.
The new CONFIG_RUST_BUG_KUNIT_TEST depends on BUG. With CONFIG_BUG=n,
warn_on! does nothing and no warning is counted.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20260916140952.3290924-1-tomo@flapping.org
[ Added newlines for clarity. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
On UML, `warn_flags!` calls `warn_slowpath_fmt()` directly. Its third
argument is a taint number, but `warn_on!` passes its bug flags there.
As a result, `add_taint()` gets 2304 instead of 9 (`TAINT_WARN`). The
warning is not recorded: `/proc/sys/kernel/tainted` stays 0 after
`warn_on!` fires, where it should be 512. It also causes an
out-of-bounds write in `add_taint()`.
Pass `TAINT_WARN` directly, as C does on UML.
Cc: stable@vger.kernel.org
Fixes: dff64b072708 ("rust: Add warn_on macro")
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20261001123103.2198104-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Cross-merge networking fixes after downstream PR (net-7.3-rc6).
Conflicts:
net/mac80211/tx.c
net/mac80211/ieee80211_i.h
8effab902fa34 ("wifi: mac80211: prevent AP VLAN tx from other interfaces")
78b843974fb83 ("wifi: mac80211: report multicast transmission from lookup_ra_sta()")
https://lore.kernel.org/arJmcuhpJ69wAvYK@sirena.co.uk
drivers/net/ethernet/realtek/r8169_main.c
3cdeaef1754ab ("r8169: disable EEE on RTL8168h/8111h")
8a3c76523e449 ("r8169: add support for phylink")
https://lore.kernel.org/ar5vAxEqS8tO8aVT@sirena.org.uk
Adjacent changes:
rust/kernel/net/netlink.rs
5e5916923759 ("rust: net: netlink: Migrate to zerocopy's IntoBytes")
0923198be4ae ("rust: net: netlink: validate attribute length before casting to `c_int`")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
`TagSet` never implemented `Send` or `Sync`. This did not matter until
commit "rust: block: fix `Send` bound for `GenDisk`" made `GenDisk: Send`
depend on `Arc<TagSet<T>>: Send`, which in turn requires `TagSet<T>: Send +
Sync`. With that bound unsatisfiable, `GenDisk` is never `Send`, and the
rnull driver fails to build once configfs requires `GroupOperations::Child:
Send`.
`TagSet` owns no data typed by `T`. It only wraps the C `struct
blk_mq_tag_set`, which can be dropped from any thread by calling
`blk_mq_free_tag_set`. Thus, implement `Send` and `Sync` for `TagSet`
unconditionally.
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Closes: https://lore.kernel.org/r/d1381ed8-eab8-4fd7-8b15-1e94876d7099@leemhuis.info
Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Tested-by: Thorsten Leemhuis <linux@leemhuis.info>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260930-tag-set-send-sync-v1-1-51acdb36f4bb@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
`NumaNode` wraps an `i32` but offers no way to read it back. Add a
trivial `id()` getter so callers that need to pass the node id to a
C binding can recover the underlying `c_int` without reaching into
the private field.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-numa-node-id-v2-1-fdd2c0a49412@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Previously, `KBox::pin_slice` required the initializer error type to match
the return error type via `E: From<AllocError>`. This prevented using
infallible initializers like `new_mutex!` inside `pin_slice`, because
`Infallible` does not implement `From<AllocError>`.
Introduce a separate type parameter `E2` for the initializer error type
and require `E: From<AllocError>` and `E: From<E2>` instead. This allows
the initializer to return a different error type that can be converted
into the final error type, enabling use of infallible pin initializers
in fallible allocation contexts.
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/.E2.9C.94.20Constructing.20Mutex.20from.20PinInit.3CT.2C.20Error.3E
Co-developed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260605-pin-slice-init-v2-1-b197e84040ba@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The queue data installed in a `GenDisk` is stored in the request queue and
handed back to the driver as a shared borrow through the `queue_rq` and
`commit_rqs` callbacks. Both callbacks obtain that borrow via
`ForeignOwnable::borrow` and may execute concurrently on several CPUs,
since the block layer runs one hardware queue per CPU. That means a shared
reference to the same queue data can be live on multiple threads at once,
which is only sound when the referent is `Sync`.
The initial `GenDisk` private data support omitted this bound, so a
driver could install a non-`Sync` type as queue data and then access
it concurrently from multiple CPUs without synchronization. Add a
`Sync` bound to the `QueueData` associated type to rule that out.
Fixes: 90d952fac8ac ("rust: block: add `GenDisk` private data support")
Cc: stable@vger.kernel.org
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://msgid.link/20260608-queue-data-sync-v1-1-0efff051aaf3@kernel.org
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-9-642a4c1aebd7@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
GenDiskBuilder::validate_block_size() accepts powers of two from 512
through PAGE_SIZE, but the documentation for logical_block_size() and
physical_block_size() states that the maximum is 4096.
Use PAGE_SIZE for both documented upper bounds so that the documentation
matches validation on architectures with larger page sizes.
Signed-off-by: Sophon Z <aiqubits@hotmail.com>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://msgid.link/20260831-fix-gendisk-block-size-docs-v1-1-900546005799@hotmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-6-642a4c1aebd7@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Set `fops.owner` from the driver module pointer via
`this_module::<T::OwnerModule>().as_ptr()` instead of defaulting to
null, so the module cannot be unloaded while a block device is still
in use.
Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Link: https://msgid.link/20260811-fix-gendisk-owner-v1-1-c0fe4a449ecb@linux.dev
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-5-642a4c1aebd7@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The `Send` implementation for `GenDisk<T>` was conditioned on `T: Send`.
This constrains the wrong type. `T` is the `Operations` implementation,
which is typically a zero-sized marker type that carries no data, so `T:
Send` says nothing about whether the data a `GenDisk` actually owns can be
moved to another thread.
A `GenDisk<T>` owns the queue data `T::QueueData` (stored as the
`gendisk`'s `queuedata` and dropped when the `GenDisk` is dropped) and an
`Arc<TagSet<T>>`. These are the values transferred when a `GenDisk` is sent
across a thread boundary, so the `Send` bound must constrain exactly them.
Bound `T::QueueData: Send` and `Arc<TagSet<T>>: Send` instead.
Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
Cc: stable@vger.kernel.org
Reported-by: Priya Bala Govindasamy <pgovind2@uci.edu>, Dylan Zueck <dzueck@uci.edu>, Yuan Tan <ytan089@ucr.edu>
Closes: https://lore.kernel.org/all/cover.1780633578.git.ytan089@ucr.edu
Signed-off-by: Yuan Tan <ytan089@ucr.edu>
Link: https://msgid.link/20260709100100.604252-1-yuantan098@gmail.com
[ Andreas: Fix tags to make checkpatch happy. Change summary line. ]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-4-642a4c1aebd7@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Drop `Result`, `Pin`, `pin_data`, `pinned_drop`, `PinInit`, and
`try_pin_init` imports already provided by `kernel::prelude`.
Simplify `error` imports and flatten parameters formatting.
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://msgid.link/20260521-miscdev-use-format-v3-5-56240ca70d0c@linux.dev
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-2-642a4c1aebd7@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Convert `use` imports to vertical layout for better readability and
maintainability.
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Link: https://msgid.link/20260521-miscdev-use-format-v3-4-56240ca70d0c@linux.dev
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260929-rust-block-for-v7-4-rc1-b4-v1-1-642a4c1aebd7@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
`put()` trusted an unchecked `as` cast from `usize` to `c_int`.
When the length exceeds `i32::MAX` that cast wraps around to a
negative value.
This ultimately resulted in a kernel panic when the reinterpreted
value via `__nla_reserve()` and `skb_put()` became enormous.
Validate payload and header both fit together in a `u16`, rejecting
any payload that wouldn't leave room for `NLA_HDRLEN`.
Fixes: 5eaa5fbb6e6c ("rust: netlink: add raw netlink abstraction")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Sagar Taunk <sagartaunk@proton.me>
Link: https://patch.msgid.link/20260925085449.22553-1-sagartaunk@proton.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
`get_group_data()` chooses between `Group::<Parent>::container_of()` and
`Subsystem::<Parent>::container_of()` based on whether `this` represents
the root group of a configfs subsystem. It detects this by checking
`(*this).cg_subsys.is_null()`, but `link_group()` in `fs/configfs/dir.c`
unconditionally sets `cg_subsys` for every `config_group` attached anywhere
in a registered subsystem, including the subsystem's own `su_group`. The
only `config_group` with a NULL `cg_subsys` is the configfs root, on which
userspace cannot trigger callbacks. The check is therefore always false at
runtime, and the `Subsystem` branch is dead. Subsystem-level callbacks
reach the `Group` branch and may read `data` at the wrong offset.
Thus change the `is_root` check to correctly identify whether a group is a
root group by comparing `this` to `subsys.su_group`.
Cc: stable@vger.kernel.org
Fixes: 446cafc295bf ("rust: configfs: introduce rust support for configfs")
Link: https://msgid.link/20260608-configfs-fix-offset-v1-1-7f01b8fb9e5f@kernel.org
[ Andreas: Fix clippy warning on 1.85.0 by moving safety comment. ]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
Add implementation notes explaining why the hrtimer abstraction uses a
handle based approach.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun@kernel.org>
Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://msgid.link/20260215-hrtimer-docs-v1-1-bff6a6c0d923@kernel.org
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
The boundaries of __msecs_to_jiffies() and nsecs_to_jiffies64() depend
on which HZ branch is compiled. With CONFIG_HZ_300
nsecs_to_jiffies64() overflows after 64.99 years, which is less than
the 292 years a Delta can hold. With HZ=1000 a jiffy is a millisecond,
so __msecs_to_jiffies() returns its argument unchanged and never caps
it at MAX_JIFFY_OFFSET.
Compute the conversion in Rust with mul_u64_add_u64_div_u64() instead. It
returns (a * b + c) / d, computing a * b internally in 128 bits, so
ceil(nanos * HZ / NSEC_PER_SEC) needs no input clamp and rounds once. The
bound then follows from the arithmetic: with HZ <= NSEC_PER_SEC, which a
static_assert() checks, the result is at most the nanosecond count.
Unless the result saturates, the value is rounded up, so the timeout is
never shorter than the requested span. It saturates at zero jiffies for a
negative span, i.e. an immediate timeout, and at MAX_JIFFY_OFFSET, the
upper bound the kernel uses for a jiffies span. Since MAX_JIFFY_OFFSET is
derived from long, only 32 bit can reach it, and a saturated timeout there
is finite, so it can be shorter than the requested span.
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://msgid.link/20260924232530.446588-3-tomo@flapping.org
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
The Rust configfs abstractions do not fully constrain callback data for
cross-thread use. Add the missing `Send` and `Sync` requirements.
Specifically, make the following changes:
1. Require `Data: Send` when implementing `Send` for `Subsystem<Data>`,
since the subsystem stores its data by value.
2. Make `GroupOperations` a `Sync` supertrait because `make_group` and
`drop_item` receive `&self` from foreign threads. Require `Child: Send`
because configfs may release child groups on an arbitrary thread.
3. Require `AttributeOperations::Data: Sync` because its callbacks receive
`&Data` from foreign threads.
4. Update the safety comments in FFI callbacks that call `get_group_data`
to cite these bounds as justification for sharing the returned
references with the callback thread.
5. Remove redundant `Child: 'static` bounds from `GroupOperationsVTable`
and `new_with_child_ctor`.
Fixes: 446cafc295bf ("rust: configfs: introduce rust support for configfs")
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Should.20add.20Data.3A.20Send.2FSync.20bounds.20in.20configfs.3A.3ASubsystem.3F/with/623719979
Assisted-by: Gpt-5.6 Sol
Signed-off-by: Yilin Chen <1479826151@qq.com>
Link: https://msgid.link/tencent_5449081195EDDF5726C709CF648DD4044A08@qq.com
[ Andreas: Add Send/Sync bounds for `Group<Data>`, add `Send` bounds to
`GroupOperationsVTable`, `ItemOperationsVTable` and `ItemType` macro
implementation. ]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a helper that writes as much of an AsBytes value as fits in the
remaining userspace buffer and returns the number of bytes copied. This
avoids requiring callers of versioned UAPIs to convert values to byte
slices and truncate them manually.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/nova-gpu/DKC6T1DQX2L3.HTHPB2L167TC@kernel.org/
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://patch.msgid.link/20260909064506.910162-7-apopple@nvidia.com
[ Inline write_slice_partial() and use it to simplify write_truncated().
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
sub-fields
The closure passed to registration_data_with() currently receives
`Pin<&'a F::Of<'a>>` with `'a` universally quantified. This prevents the
closure from returning references derived from the registration data,
even for sub-fields that are covariant in their lifetime, because the
compiler cannot relate `'a` to any lifetime the caller knows about.
Tie the outer reference to the `&self` lifetime instead, i.e. pass
`Pin<&'this F::Of<'a>>`. This gives the closure the implied bound
`'a: 'this`, so covariant sub-fields such as `&'a T` can be coerced to
`'this` and returned directly, while invariant fields still cannot be
coerced and therefore cannot escape with an incorrect lifetime.
This allows auxiliary child drivers to project covariant data out of
invariant registration data without having to wrap every use in a
closure.
Link: https://lore.kernel.org/nova-gpu/DL3WPTVM033J.33RWYCZOC67Z1@kernel.org/
Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-2-apopple@nvidia.com
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
SGTable::new() caps segment length at dma_max_mapping_size() only, which
limits the DMA mapping path (e.g. swiotlb), not the device itself. The
per-device limit from dma_set_max_seg_size() is ignored, so contiguous
page segments can be longer than the declared max segment size,
potentially causing problems for future drivers that use this
abstraction.
Fixes: 05aa6fb1c21d ("rust: scatterlist: Add abstraction for sg_table")
Signed-off-by: Matteo Kloiber <kernel@matt3o12.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260913210828.125655-3-kernel@matt3o12.de
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
`Hertz::from_khz()`, `from_mhz()` and `from_ghz()` multiply their
argument by 1_000, 1_000_000 and 1_000_000_000 respectively without
checking for overflow. When `CONFIG_RUST_OVERFLOW_CHECKS` is enabled,
each panics once its argument exceeds `c_ulong::MAX` divided by that
factor. None of the three documents this. The panic occurs only at
runtime, when the argument is not a constant expression.
Add the missing `# Panics` sections stating the bound for each unit.
Fixes: d01d70205601 ("rust: clk: Add initial abstractions")
Signed-off-by: Georgios Androutsopoulos <georgeandrout13@gmail.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
The `ClockSource` trait has nothing to do with the C `struct clocksource`
in `include/linux/clocksource.h`, which abstracts the hardware counter
used as a source of time for the majority of the clockids. The trait
instead carries a `clockid_t` `ID`, i.e. one of the IDs of "the various
system clocks (for POSIX.1b interval timers)" as described in
include/uapi/linux/time.h (CLOCK_MONOTONIC, CLOCK_REALTIME, ...). It thus
plays the role of a `clockid_t`, and the `ClockSource` name overlaps
confusingly with the C `clocksource` concept when reading across C and
Rust code.
Rename the trait to `ClockId` to reflect that it represents a
`clockid_t`. This is a pure rename; there is no functional change.
Suggested-by: John Stultz <jstultz@google.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://lore.kernel.org/rust-for-linux/CANDhNCrKMdHCmL76LWCROVF2Ly-9NxmfmQ2T+P=iv34aVkO2uQ@mail.gmail.com/
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://msgid.link/20260722001050.4115708-1-tomo@flapping.org
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
ItemOperationsVTable<Group<Data>, Data>::release() receives a pointer
to a config_item, not a config_group.
The old Safety docs described the pointer as a config_group embedded in
Group<Parent>. Update them to state that the pointer must be the cg_item
field of a config_group embedded in a valid Group<Data>.
Assisted-by: Codex:GPT-5
Signed-off-by: Yilin Chen <1479826151@qq.com>
Link: https://msgid.link/tencent_9FAFC60382D724C608F0F6BFABFC63BB6707@qq.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
fsleep() documents out-of-range input as a bug but does not check
it, unlike udelay(). Add `debug_assert!` calls to catch it in
debug builds.
Also add `pr_warn_once!` calls in both fsleep() and udelay() so
the clamped path is observable at runtime.
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://msgid.link/20260621105909.4055210-1-ekffu200098@gmail.com
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
|
|
Linux 7.3-rc4
Requested by Philipp Stanner for
2ab510e63197360945f915dd5631a77c63ac6b27 would be needed as a groundlayer
for further patches that extend the locking in drm_sched
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
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
|
|
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>
|
|
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>
|
