linux-kernel - Re: [PATCH v3 2/2] rust: task: Add Rust version of might

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250617.120453.1403624234989149033.fujita.tomonori@gmail.com>
Date: Tue, 17 Jun 2025 12:04:53 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: miguel.ojeda.sandonis@...il.com
Cc: boqun.feng@...il.com, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, ojeda@...nel.org, alex.gaynor@...il.com,
 gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
 a.hindborg@...sung.com, aliceryhl@...gle.com, tmgross@...ch.edu,
 dakr@...nel.org, mingo@...hat.com, peterz@...radead.org,
 juri.lelli@...hat.com, vincent.guittot@...aro.org,
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, vschneid@...hat.com, pmladek@...e.com,
 fujita.tomonori@...il.com, mingo@...nel.org
Subject: Re: [PATCH v3 2/2] rust: task: Add Rust version of might_sleep()

On Mon, 16 Jun 2025 23:28:31 +0200
Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:

> On Mon, Jun 16, 2025 at 5:36 PM Boqun Feng <boqun.feng@...il.com> wrote:
>>
>> +/// Equivalent to the C side [`might_sleep()`], this function serves as
> 
> I am always pleased to see intra-doc links, but wouldn't this one
> point to the Rust item? :) i.e. we need to add the link, right?

Ah, you're right.

> I would normally ask for an example of typical usage, but do we have
> some good C docs on that already that we could link otherwise?

I can't find C docs on might_sleep(). Device driver developers
probably don't need to use might_sleep() directly. I can't think of a
good example.

How about adding a link to the header file where the might_sleep macro
is defined, like this?

/// Annotation for functions that can sleep.
///
/// Equivalent to the C side [`might_sleep`] macro, this function serves as
/// a debugging aid and a potential scheduling point.
///
/// This function can only be used in a nonatomic context.
///
/// [`might_sleep`]: srctree/include/linux/kernel.h
#[track_caller]
#[inline]
pub fn might_sleep() {
    #[cfg(CONFIG_DEBUG_ATOMIC_SLEEP)]
    {
        let loc = core::panic::Location::caller();
        let file = kernel::file_from_location(loc);

        // SAFETY: `file.as_ptr()` is valid for reading and guaranteed to be nul-terminated.
        unsafe { crate::bindings::__might_sleep(file.as_ptr().cast(), loc.line() as i32) }
    }

    // SAFETY: Always safe to call.
    unsafe { crate::bindings::might_resched() }
}