linux-kernel - Re: [PATCH v10 7/8] rust: Add read_poll

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: <20250214113740.156faaf4@eugeo>
Date: Fri, 14 Feb 2025 11:37:40 +0000
From: Gary Guo <gary@...yguo.net>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
 netdev@...r.kernel.org, andrew@...n.ch, hkallweit1@...il.com,
 tmgross@...ch.edu, ojeda@...nel.org, alex.gaynor@...il.com,
 bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, a.hindborg@...sung.com,
 aliceryhl@...gle.com, anna-maria@...utronix.de, frederic@...nel.org,
 tglx@...utronix.de, arnd@...db.de, jstultz@...gle.com, sboyd@...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,
 tgunders@...hat.com, me@...enk.dev
Subject: Re: [PATCH v10 7/8] rust: Add read_poll_timeout functions

On Fri, 14 Feb 2025 13:05:30 +0900 (JST)
FUJITA Tomonori <fujita.tomonori@...il.com> wrote:

> On Sun, 9 Feb 2025 16:20:48 +0000
> Gary Guo <gary@...yguo.net> wrote:
> 
> >> +fn might_sleep(loc: &Location<'_>) {
> >> +    // SAFETY: FFI call.
> >> +    unsafe {
> >> +        crate::bindings::__might_sleep_precision(
> >> +            loc.file().as_ptr().cast(),
> >> +            loc.file().len() as i32,
> >> +            loc.line() as i32,
> >> +        )
> >> +    }
> >> +}  
> > 
> > One last Q: why isn't `might_sleep` marked as `track_caller` and then
> > have `Location::caller` be called internally?
> >
> > It would make the API same as the C macro.  
> 
> Equivalent to the C side __might_sleep(), not might_sleep(). To avoid
> confusion, it might be better to change the name of this function.
> 
> The reason why __might_sleep() is used instead of might_sleep() is
> might_sleep() can't always be called. It was discussed in v2:
> 
> https://lore.kernel.org/all/ZwPT7HZvG1aYONkQ@boqun-archlinux/

I don't follow. `__might_sleep` or `might_sleep` wouldn't make a
difference here, given that this function may actually sleep.

- Gary

> 
> > Also -- perhaps this function can be public (though I guess you'd need
> > to put it in a new module).  

> 
> Wouldn't it be better to keep it private until actual users appear?