linux-stable.git/rust, branch v6.12.2

rust: block: fix formatting of `kernel::block::mq::request` module

2024-12-05T13:02:21+00:00

[ Upstream commit 28e848386b92645f93b9f2fdba5882c3ca7fb3e2 ]

Fix several issues with rustdoc formatting for the
`kernel::block::mq::Request` module, in particular:

  - An ordered list not rendering correctly, fixed by using numbers
    prefixes instead of letters.

  - Code snippets formatted as regular text, fixed by wrapping the
    code with `back-ticks`.

  - References to types missing intra-doc links, fixed by wrapping the
    types with [square brackets].

Reported-by: Miguel Ojeda 
Closes: https://github.com/Rust-for-Linux/linux/issues/1108
Signed-off-by: Francesco Zardi 
Acked-by: Andreas Hindborg 
Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
Link: https://lore.kernel.org/r/20240903173027.16732-3-frazar00@gmail.com
[ Added an extra intra-doc link. Took the chance to add some periods
  for consistency. Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: macros: fix documentation of the paste! macro

2024-12-05T13:02:21+00:00

[ Upstream commit 15541c9263ce34ff95a06bc68f45d9bc5c990bcd ]

One of the example in this section uses a curious mix of the constant
and function declaration syntaxes; fix it.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Alice Ryhl 
Fixes: 823d4737d4c2 ("rust: macros: add `paste!` proc macro")
Link: https://lore.kernel.org/r/20241019072208.1016707-1-pbonzini@redhat.com
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: kernel: fix THIS_MODULE header path in ThisModule doc comment

2024-12-05T13:02:20+00:00

[ Upstream commit 8b55dc8610acf816a66373be53ca6e3bbe2d313a ]

The doc comment for `ThisModule` incorrectly states the C header file
for `THIS_MODULE` as `include/linux/export.h`, while the correct path is
`include/linux/init.h`. This is because `THIS_MODULE` was moved in
commit 5b20755b7780 ("init: move THIS_MODULE from  to
").

Update the doc comment for `ThisModule` to reflect the correct header
file path for `THIS_MODULE`.

Fixes: 5b20755b7780 ("init: move THIS_MODULE from  to ")
Signed-off-by: Yutaro Ohno 
Reviewed-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/ZxXDZwxWgoEiIYkj@ohnotp
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: rbtree: fix `SAFETY` comments that should be `# Safety` sections

2024-12-05T13:02:19+00:00

[ Upstream commit 8333ff4d0799aafbe4275cddcbaf45e545e4efba ]

The tag `SAFETY` is used for safety comments, i.e. `// SAFETY`, while a
`Safety` section is used for safety preconditions in code documentation,
i.e. `/// # Safety`.

Fix the three instances recently added in `rbtree` that Clippy would
have normally caught in a public item, so that we can enable checking
of private items in one of the following commits.

Fixes: 98c14e40e07a ("rust: rbtree: add cursor")
Reviewed-by: Trevor Gross 
Reviewed-by: Alice Ryhl 
Tested-by: Gary Guo 
Reviewed-by: Gary Guo 
Link: https://lore.kernel.org/r/20240904204347.168520-14-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Sasha Levin

rust: helpers: Avoid raw_spin_lock initialization for PREEMPT_RT

2024-12-05T13:01:23+00:00

[ Upstream commit 5c2e7736e20d9b348a44cafbfa639fe2653fbc34 ]

When PREEMPT_RT=y, spin locks are mapped to rt_mutex types, so using
spinlock_check() + __raw_spin_lock_init() to initialize spin locks is
incorrect, and would cause build errors.

Introduce __spin_lock_init() to initialize a spin lock with lockdep
rquired information for PREEMPT_RT builds, and use it in the Rust
helper.

Fixes: d2d6422f8bd1 ("x86: Allow to enable PREEMPT_RT.")
Closes: https://lore.kernel.org/oe-kbuild-all/202409251238.vetlgXE9-lkp@intel.com/
Reported-by: kernel test robot 
Signed-off-by: Eder Zulian 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Boqun Feng 
Tested-by: Boqun Feng 
Link: https://lore.kernel.org/r/20241107163223.2092690-2-ezulian@redhat.com
Signed-off-by: Sasha Levin

Merge tag 'driver-core-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2024-10-13T16:10:52+00:00

Pull driver core fixes from Greg KH:
 "Here is a single driver core fix, and a .mailmap update.

  The fix is for the rust driver core bindings, turned out that the
  from_raw binding wasn't a good idea (don't want to pass a pointer to a
  reference counted object without actually incrementing the pointer.)
  So this change fixes it up as the from_raw binding came in in -rc1.

  The other change is a .mailmap update.

  Both have been in linux-next for a while with no reported issues"

* tag 'driver-core-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  mailmap: update mail for Fiona Behrens
  rust: device: change the from_raw() function

rust: device: change the from_raw() function

2024-10-03T11:54:48+00:00

The function Device::from_raw() increments a refcount by a call to
bindings::get_device(ptr). This can be confused because usually
from_raw() functions don't increment a refcount.
Hence, rename Device::from_raw() to avoid confuion with other "from_raw"
semantics.

The new name of function should be "get_device" to be consistent with
the function get_device() already exist in .c files.

This function body also changed, because the `into()` will convert the
`&'a Device` into `ARef` and also call `inc_ref` from the
`AlwaysRefCounted` trait implemented for Device.

Signed-off-by: Guilherme Giacomo Simoes 
Acked-by: Danilo Krummrich 
Closes: https://github.com/Rust-for-Linux/linux/issues/1088
Reviewed-by: Boqun Feng 
Link: https://lore.kernel.org/r/20241001205603.106278-1-trintaeoitogc@gmail.com
Signed-off-by: Greg Kroah-Hartman

rust: kunit: use C-string literals to clean warning

2024-10-01T21:46:42+00:00

Starting with upstream Rust commit a5e3a3f9b6bd ("move
`manual_c_str_literals` to complexity"), to be released in Rust 1.83.0
[1], Clippy now warns on `manual_c_str_literals` by default, e.g.:

    error: manually constructing a nul-terminated string
      --> rust/kernel/kunit.rs:21:13
       |
    21 |             b"\x013%pA\0".as_ptr() as _,
       |             ^^^^^^^^^^^^^ help: use a `c""` literal: `c"\x013%pA"`
       |
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_c_str_literals
       = note: `-D clippy::manual-c-str-literals` implied by `-D warnings`
       = help: to override `-D warnings` add `#[allow(clippy::manual_c_str_literals)]`

Apply the suggestion to clean up the warnings.

Link: https://github.com/rust-lang/rust-clippy/pull/13263 [1]
Reviewed-by: Trevor Gross 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20240927164414.560906-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT

2024-09-26T19:22:15+00:00

In case CONFIG_PREEMPT_RT is enabled __mutex_init() becomes a macro
instead of an extern function (simplified from
include/linux/mutex.h):

    #ifndef CONFIG_PREEMPT_RT
    extern void __mutex_init(struct mutex *lock, const char *name,
    			 struct lock_class_key *key);
    #else
    #define __mutex_init(mutex, name, key)		\
    do {						\
	rt_mutex_base_init(&(mutex)->rtmutex);		\
    	__mutex_rt_init((mutex), name, key);		\
    } while (0)
    #endif

The macro isn't resolved by bindgen, then. What results in a build
error:

error[E0425]: cannot find function `__mutex_init` in crate `bindings`
     --> rust/kernel/sync/lock/mutex.rs:104:28
      |
104   |           unsafe { bindings::__mutex_init(ptr, name, key) }
      |                              ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init`
      |
     ::: rust/bindings/bindings_generated.rs:23722:5
      |
23722 | /     pub fn __mutex_rt_init(
23723 | |         lock: *mut mutex,
23724 | |         name: *const core::ffi::c_char,
23725 | |         key: *mut lock_class_key,
23726 | |     );
      | |_____- similarly named function `__mutex_rt_init` defined here

Fix this by adding a helper.

As explained by Gary Guo in [1] no #ifdef CONFIG_PREEMPT_RT
is needed here as rust/bindings/lib.rs prefers externed function to
helpers if an externed function exists.

Reported-by: Conor Dooley 
Link: https://lore.kernel.org/rust-for-linux/20240913-shack-estate-b376a65921b1@spud/
Link: https://lore.kernel.org/rust-for-linux/20240915123626.1a170103.gary@garyguo.net/ [1]
Fixes: 6d20d629c6d8 ("rust: lock: introduce `Mutex`")
Signed-off-by: Dirk Behme 
Tested-by: Conor Dooley 
Reviewed-by: Gary Guo 
Link: https://lore.kernel.org/r/20240916073752.3123484-1-dirk.behme@de.bosch.com
[ Reworded to include the proper example by Dirk. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: fix `ARCH_SLAB_MINALIGN` multiple definition error

2024-09-26T15:52:35+00:00

We use const helpers in form of

    const size_t RUST_CONST_HELPER_ARCH_SLAB_MINALIGN = ARCH_SLAB_MINALIGN;

to aid generation of constants by bindgen because it is otherwise a
macro definition of an expression and bindgen doesn't expand the
constant. The helpers are then have `RUST_CONST_HELPER` prefix stripped
and exposed to Rust code as if `ARCH_SLAB_MISALIGN` is generated
natively by bindgen.

This works well for most constants, but on RISC-V, `ARCH_SLAB_MINALIGN`
is defined directly as literal constant if `!CONFIG_MMU`, and bindgen
would generate `ARCH_SLAB_MINALIGN` directly, thus conflict with the
one generated through the helper.

To fix this, we simply need to block bindgen from generating directly
without going through helper.

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202409160804.eSg9zh1e-lkp@intel.com/
Signed-off-by: Gary Guo 
Reviewed-by: Christian Schrefl 
Link: https://lore.kernel.org/r/20240916003347.1744345-1-gary@garyguo.net
Signed-off-by: Miguel Ojeda