All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Petr Mladek <pmladek@suse.com>
Cc: "Ke Sun" <sunke@kylinos.cn>, "Dirk Behme" <dirk.behme@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Benno Lossin" <lossin@kernel.org>,
	"John Ogness" <john.ogness@linutronix.de>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Tamir Duberstein" <tamird@gmail.com>,
	"Ke Sun" <sk.alvin.x@gmail.com>,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v8 3/4] rust: fmt: Default raw pointer formatting to HashedPtr
Date: Mon, 5 Jan 2026 08:19:49 +0000	[thread overview]
Message-ID: <aVt0JYbbXLeuqFBt@google.com> (raw)
In-Reply-To: <aVgC1qXp1La6E9p0@pathway.suse.cz>

On Fri, Jan 02, 2026 at 06:39:34PM +0100, Petr Mladek wrote:
> On Thu 2026-01-01 16:16:03, Ke Sun wrote:
> > Make raw pointers (*const T, *mut T) automatically use HashedPtr when
> > formatted with {:p}, providing safe default behavior for kernel pointers.
> >
> > This allows users to format raw pointers directly:
> >     pr_info!("{:p}\n", ptr);  // Automatically hashed
> 
> It should check no_hash_pointers variable, see default_pointer() in
> lib/vsprintf.c.  See also "no_hash_pointers" and "hash_pointers=never"
> kernel command line options.
> 
> Hashed pointers prevent leaking information but are not good for
> debugging. The "no_hash_pointers" variable allows to print
> raw pointers without changing the code.
> 
> I am not sure how this should be implemented in Rust. If you need
> to keep HashPtr then it should become an implementation detail
> and should not get exported. Nobody wants always hashed pointers.
> 
> I hope that we could find a better solution which would allow
> to reduce the code duplication.
> 
> For example, I wonder what would be needed to allow calling
> snprintf() from Rust code. The fn fmt() might call
> it with "%p" format...  It would make it easier to get
> also other "%p?" formats.
> 
> It seems that something similar has been discussed at
> https://lore.kernel.org/rust-for-linux/CALpAb9MoT20Ch4pe-oMz8kpqaZsvmgNwPk1XSC+faZi7huwQKg@mail.gmail.com/
> And it was said that it would need bigger changes.
> 
> Maybe, we could create C wrappers which would allow to call
> snprintf() with some specific format, e.g.
> 
> int scnprintf_p(char *buf, int size, const void *p)
> {
> 	return scnprintf(buf, size, "%p", p);
> }
> EXPORT_SYMBOL_NS_GPL(scnprintf_p, "RUST_INTERNAL");
> 
> And use the same approach for any other %p? format, e.g. for %pU:
> 
> int scnprintf_pU(char *buf, int size, const u8 *addr)
> {
> 	return scnprintf(buf, size, "%pU", addr);
> }
> EXPORT_SYMBOL_NS_GPL(scnprintf_pU, "RUST_INTERNAL");
> 
> Best Regards,
> Petr
> 
> PS: I suggest to wait longer before sending a new version. It would
>     allow to get feedback from more people who might see it from
>     different angles.

I think there are two approaches we could take:

1. Have the C side provide a method that returns the correct integer
   address to print.
2. Have the C side provide a method that returns the correct string
   to print.

In general, for cases where the output is an integer formatted in some
standard way (e.g. hex), I think the first option is stronger because
the Rust formatting machinery lets you specify different modifiers such
as "prefix with zeroes or spaces" or "how many zeroes/spaces to prefix
with" or "hex uppercase or lowercase" or "hex vs octal vs base10" etc.
By having the C side pass an integer back to Rust, these modifiers are
taken into account automatically.

Now, just using scnprintf to write the resulting string to a buffer and
passing that string into the Rust formatting machinery is also an option
of course. Especially for modifiers such as %pF that prints something
like versatile_init+0x0/0x110.

Alice

  reply	other threads:[~2026-01-05  8:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-01  8:16 [PATCH v8 0/4] rust: Add safe pointer formatting support Ke Sun
2026-01-01  8:16 ` [PATCH v8 1/4] lib/vsprintf: Export ptr_to_hashval() for Rust kernel crate use Ke Sun
2026-01-02 12:15   ` Andy Shevchenko
2026-01-01  8:16 ` [PATCH v8 2/4] rust: kernel: Add pointer wrapper types for safe pointer formatting Ke Sun
2026-01-02  7:57   ` Dirk Behme
2026-01-02 11:06     ` Gary Guo
2026-01-02 11:13   ` Gary Guo
2026-01-02 12:17   ` Andy Shevchenko
2026-01-02 12:33     ` Danilo Krummrich
2026-01-02 12:43       ` Ke Sun
2026-01-01  8:16 ` [PATCH v8 3/4] rust: fmt: Default raw pointer formatting to HashedPtr Ke Sun
2026-01-02 11:17   ` Gary Guo
2026-01-02 17:39   ` Petr Mladek
2026-01-05  8:19     ` Alice Ryhl [this message]
2026-01-06  3:06       ` Ke Sun
2026-01-06 16:45       ` Petr Mladek
2026-01-06 17:18         ` Alice Ryhl
2026-01-06 21:00           ` Andy Shevchenko
2026-01-06 21:06             ` Alice Ryhl
2026-01-01  8:16 ` [PATCH v8 4/4] docs: rust: Add pointer formatting documentation Ke Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aVt0JYbbXLeuqFBt@google.com \
    --to=aliceryhl@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dirk.behme@gmail.com \
    --cc=gary@garyguo.net \
    --cc=john.ogness@linutronix.de \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sk.alvin.x@gmail.com \
    --cc=sunke@kylinos.cn \
    --cc=tamird@gmail.com \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.