| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
|
|
https://gitlab.freedesktop.org/drm/rust/kernel.git
# Conflicts:
# rust/kernel/mem.rs
|
|
# Conflicts:
# drivers/gpu/drm/nouveau/nouveau_connector.c
# drivers/gpu/drm/vc4/vc4_v3d.c
# drivers/gpu/drm/xe/xe_wa_oob.rules
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
# Conflicts:
# drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git
# Conflicts:
# drivers/cpufreq/cppc_cpufreq.c
|
|
# Conflicts:
# fs/coredump.c
# fs/f2fs/f2fs.h
# fs/fuse/dax.c
# fs/xfs/libxfs/xfs_btree.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mm/linux.git
|
|
# Conflicts:
# rust/kernel/Kconfig.test
|
|
|
|
|
|
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/leitao/linux.git
|
|
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>
|
|
mm-unstable into for-next
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
# Conflicts:
# arch/arm64/kvm/mmu.c
# Conflict resolution:
#
# diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
# index 1a4ae299967c..b0ea1a9391da 100644
# --- a/arch/arm64/kvm/mmu.c
# +++ b/arch/arm64/kvm/mmu.c
# @@ -1470,34 +1470,9 @@ transparent_hugepage_adjust(struct kvm *kvm, struct kvm_memory_slot *memslot,
#
# static int get_vma_page_shift(struct vm_area_struct *vma)
# {
# -<<<<<<< HEAD
# - if (is_vm_hugetlb_page(vma))
# - return huge_page_shift(hstate_vma(vma));
# -
# -=======
# - unsigned long pa;
# -
# if (vma_is_hugetlb(vma))
# return huge_page_shift(hstate_vma(vma));
#
# - if (!(vma->vm_flags & VM_PFNMAP))
# - return PAGE_SHIFT;
# -
# - pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
# -
# -#ifndef __PAGETABLE_PMD_FOLDED
# - if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
# - ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
# - ALIGN(hva, PUD_SIZE) <= vma->vm_end)
# - return PUD_SHIFT;
# -#endif
# -
# - if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
# - ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
# - ALIGN(hva, PMD_SIZE) <= vma->vm_end)
# - return PMD_SHIFT;
# -
# ->>>>>>> akpm/mm-unstable
# return PAGE_SHIFT;
# }
|
|
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>
|
|
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>
|
|
* for-7.4/block:
rust: block: implement `Send` and `Sync` for `TagSet`
|
|
`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>
|
|
* for-7.4/block:
rust: block: require `Sync` for `Operations::QueueData`
rnull: configfs: add power to configfs features
rnull: fix geometry store check-then-act across lock scopes
rust: block: Fix GenDiskBuilder block size documentation
rust: block: gen_disk: set fops.owner from driver module pointer
rust: block: fix `Send` bound for `GenDisk`
rust: block: rnull: use vertical import style
rust: block: mq: remove redundant imports and format
rust: block: mq: use vertical import style
|
|
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>
|
|
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>
|
|
`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
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 attribute structure defined in driver code never need to be
modified. Allow them to be marked as const.
As there are many drivers which use these attributes, prepare for a
phased transition by using a union of const and non-const attributes.
After all drivers have been migrated to the const variant, the non-const
one can be replaced by the const one and the transition machinery will
be removed again.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260716-configfs-const-base-v1-5-c545a4053cb5@weissschuh.net
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
The configfs_bin_attribute structures defined by driver are never
modified. Make them const.
As there are only two users of these attributes, adapt them in the same
commit to avoid a phased transition.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260716-configfs-const-base-v1-4-c545a4053cb5@weissschuh.net
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
These fields do not require mutable pointers.
Use regular immutable ones.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260716-configfs-const-base-v1-1-c545a4053cb5@weissschuh.net
Signed-off-by: Breno Leitao <leitao@debian.org>
|
|
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>
|
