linux-kernel - Re: [PATCH v3 1/2] rust: Introduce file_from

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: <aFGv7-0PzewfS5kr@tardis.local>
Date: Tue, 17 Jun 2025 11:11:59 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: 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 1/2] rust: Introduce file_from_location()

On Tue, Jun 17, 2025 at 07:21:06PM +0200, Miguel Ojeda wrote:
> On Tue, Jun 17, 2025 at 6:58 PM Boqun Feng <boqun.feng@...il.com> wrote:
> >
> > This actually helped me find a bug in the current implementation: I
> > should use core::ffi::CStr::to_bytes_with_nul() instead of to_bytes().
> > Please see below for the update "Examples" section:
> 
> Yeah, writing examples can force us to find issues :)
> 
> I guess we could conditionally (`cfg`) assert in the "otherwise" case,
> since we already had one case, but I didn't suggest it earlier because
> it is a bit heavy, and the interesting case is the other one anyway so
> it wouldn't have caught the issue. I guess we could assert it ends
> with `.rs` for the interesting one.
> 

We already know the full function name from Location::file() ;-) so the
assertion is easy:

	assert_eq!(Ok(caller.file()), file_from_location(caller).to_str());

I didn't add the assertion of the otherwise case because that would
involve either writing another string "<Location ... not supported>" or
define it as a const, both are a bit overkilling to me.

> By the way, I would avoid the actual filename, i.e. I would give a
> more "normal" example instead of the `doctests_kernel_generated` one

Good point.

> of the example itself. Something like:
> 
>     // Output:
>     // - A path like `rust/kernel/example.rs` if `file_with_nul()` is available.
>     // - `<Location::file_with_nul() not supported>` otherwise.
> 
> It could make sense to have an intermediate variable (especially if
> you end up asserting anything), then you could put the comment on top
> of that instead. Then the `pr_*` call could then perhaps show a
> "realistic" example, and could inline the variable name, e.g.
> something like `{caller_file}: my message\n`.
> 

How aobut something below? (I use "" instead of `` on purpose because
the output variable there is a string)

/// Gets the C string file name of a [`Location`].
///
/// If `file_with_nul()` is not available, returns a string that warns about it.
///
/// [`Location`]: core::panic::Location
///
/// # Examples
///
/// ```
/// # use kernel::file_from_location;
///
/// #[track_caller]
/// fn foo() {
///     let caller = core::panic::Location::caller();
///
///     // Output:
///     // - A path like "rust/kernel/example.rs" if file_with_nul() available.
///     // - "<Location::file_with_nul() not supported>" otherwise.
///     let caller_file: &kernel::str::CStr = file_from_location(caller);
///
///     // Prints out the message with caller's file name.
///     pr_info!("foo() called in file {caller_file}\n");
///
///     # if cfg!(CONFIG_RUSTC_HAS_FILE_WITH_NUL) {
///     #     assert_eq!(Ok(caller.file()), caller_file.to_str());
///     # }
/// }
///
/// # foo();
/// ```


> Anyway, no big deal either way, what you had is also OK.
> 
> By the way, I noticed a typo in "with a NUL terminated." above.
> 

You mean it should be "with an NUL terminated"? Or it should be "with
a `NUL` byte terminated"?

Regards,
Boqun

> Cheers,
> Miguel