Linux filesystem development
 help / color / mirror / Atom feed
* [PATCH] rust: seq_file: route seq_print! directly to seq_write
@ 2026-05-14  5:37 Donjuanplatinum
  2026-05-14  7:04 ` Greg KH
  0 siblings, 1 reply; 2+ messages in thread
From: Donjuanplatinum @ 2026-05-14  5:37 UTC (permalink / raw)
  To: ojeda, viro, brauner
  Cc: boqun, gary, bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross,
	dakr, jack, rust-for-linux, linux-fsdevel, linux-kernel,
	Donjuanplatinum

Currently, the `seq_print!` macro formats output by passing a Rust
`fmt::Arguments` object to the C `seq_printf` function using the `%pA`.
This involves crossing the FFI boundary, parsing the
format string in C via `vsnprintf`, and triggering a callback back
into Rust to perform the actual buffer write.

This patch implements `core::fmt::Write` for `&SeqFile` and updates
`call_printf` to use it, routing Rust's formatting directly to
`bindings::seq_write`. This approach leverages the bounded string
slices naturally produced by the Rust formatting machinery and copies
them directly into the `seq_file` buffer.

By mapping to `seq_write`, we bypass the C string parsing state machine
and the `%pA` FFI callback, streamlining the execution path. Since
`seq_write` uses a bounded `memcpy` relying on the explicitly passed
length, it perfectly matches Rust's `&str` semantics and operates
safely without requiring null-termination.

Note that `fmt::Write` chunks the output into multiple `seq_write` calls.
If an overflow occurs during a partial write, `seq_write` sets the
overflow flag. The `seq_file` subsystem inherently handles this by
discarding the current record and retrying with a larger buffer.
Therefore, this optimization introduces no observable semantic change
to user-space.

Signed-off-by: Donjuanplatinum <donplat@barrensea.org>
---
 rust/kernel/seq_file.rs | 26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/rust/kernel/seq_file.rs b/rust/kernel/seq_file.rs
index 518265558..16ba1fdd8 100644
--- a/rust/kernel/seq_file.rs
+++ b/rust/kernel/seq_file.rs
@@ -4,7 +4,7 @@
 //!
 //! C header: [`include/linux/seq_file.h`](srctree/include/linux/seq_file.h)
 
-use crate::{bindings, fmt, str::CStrExt as _, types::NotThreadSafe, types::Opaque};
+use crate::{bindings, ffi::c_void, fmt, types::NotThreadSafe, types::Opaque};
 
 /// A utility for generating the contents of a seq file.
 #[repr(transparent)]
@@ -32,14 +32,26 @@ pub unsafe fn from_raw<'a>(ptr: *mut bindings::seq_file) -> &'a SeqFile {
     /// Used by the [`seq_print`] macro.
     #[inline]
     pub fn call_printf(&self, args: fmt::Arguments<'_>) {
-        // SAFETY: Passing a void pointer to `Arguments` is valid for `%pA`.
+        let mut this = self;
+        let _ = fmt::Write::write_fmt(&mut this, args);
+    }
+}
+
+impl fmt::Write for &SeqFile {
+    fn write_str(&mut self, s: &str) -> fmt::Result {
+        // SAFETY: `self` is a valid reference, ensuring `self.inner.get()` is a valid pointer
+        // to `struct seq_file`. `s` is a valid string slice, guaranteeing `s.as_ptr()` is
+        // readable for `s.len()` bytes. `seq_write` handles bounds checking and does not
+        // require a null-terminated string.
+        //
+        // CAST: `s.as_ptr()` (a `*const u8`) is cast to `*const c_void` because `seq_write`
+        // only reads the buffer via `memcpy` and does not care about the underlying type.
+
         unsafe {
-            bindings::seq_printf(
-                self.inner.get(),
-                c"%pA".as_char_ptr(),
-                core::ptr::from_ref(&args).cast::<crate::ffi::c_void>(),
-            );
+            bindings::seq_write(self.inner.get(), s.as_ptr().cast::<c_void>(), s.len());
         }
+
+        Ok(())
     }
 }
 
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-05-14  7:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-14  5:37 [PATCH] rust: seq_file: route seq_print! directly to seq_write Donjuanplatinum
2026-05-14  7:04 ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox