Remove the temporary FIXME(read_once) comments and replace the
read_volatile implementations with the proper native atomic_load.

The generic `atomic_load` with `Relaxed` ordering maps directly to the
C side `READ_ONCE()` macro, providing the intended behavior and
correct hardware memory guarantees without relying on pure volatile reads.

Signed-off-by: Alessio Maroni <alessiomaroni0@gmail.com>
---
 rust/kernel/fs/file.rs      | 12 +++++++-----
 rust/kernel/time/hrtimer.rs |  7 ++++---
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/rust/kernel/fs/file.rs b/rust/kernel/fs/file.rs
index 23ee689bd..63f309f5c 100644
--- a/rust/kernel/fs/file.rs
+++ b/rust/kernel/fs/file.rs
@@ -335,12 +335,14 @@ pub fn cred(&self) -> &Credential {
     /// The flags are a combination of the constants in [`flags`].
     #[inline]
     pub fn flags(&self) -> u32 {
-        // This `read_volatile` is intended to correspond to a READ_ONCE call.
-        //
         // SAFETY: The file is valid because the shared reference guarantees a nonzero refcount.
-        //
-        // FIXME(read_once): Replace with `read_once` when available on the Rust side.
-        unsafe { core::ptr::addr_of!((*self.as_ptr()).f_flags).read_volatile() }
+        // `atomic_load` safely performs an atomic read equivalent to `READ_ONCE()`.
+        unsafe {
+            crate::sync::atomic::atomic_load(
+                core::ptr::addr_of!((*self.as_ptr()).f_flags).cast_mut(),
+                crate::sync::atomic::ordering::Relaxed,
+            )
+        }
     }
 }
 
diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
index 2d7f1131a..cb1b5a2ae 100644
--- a/rust/kernel/time/hrtimer.rs
+++ b/rust/kernel/time/hrtimer.rs
@@ -576,9 +576,10 @@ pub fn expires(&self) -> HrTimerInstant<T>
         // - There's no actual locking here, a racy read is fine and expected
         unsafe {
             Instant::from_ktime(
-                // This `read_volatile` is intended to correspond to a READ_ONCE call.
-                // FIXME(read_once): Replace with `read_once` when available on the Rust side.
-                core::ptr::read_volatile(&raw const ((*c_timer_ptr).node.expires)),
+                crate::sync::atomic::atomic_load(
+                    (&raw const ((*c_timer_ptr).node.expires)) as *mut i64,
+                    crate::sync::atomic::ordering::Relaxed,
+                )
             )
         }
     }
-- 
2.55.0

Please disregard this patch. 

As pointed out by the Sashiko AI review, using `atomic_load` here
introduces critical alignment issues on 32-bit platforms for ktime_t
and violates the safety contract regarding concurrent non-atomic stores
on the C side.

We definitely need a proper `read_once` abstraction in Rust before 
handling these cases. Sorry for the noise!

Best regards,
Alessio

On Sun Jul 12, 2026 at 1:34 PM BST, Alessio Maroni wrote:
> Please disregard this patch. 
>
> As pointed out by the Sashiko AI review, using `atomic_load` here
> introduces critical alignment issues on 32-bit platforms for ktime_t
> and violates the safety contract regarding concurrent non-atomic stores
> on the C side.
>
> We definitely need a proper `read_once` abstraction in Rust before 
> handling these cases. Sorry for the noise!

The symptom is correct but your conclusion is wrong. Tearing is not allowed for
hrtimer!

This is already being worked on, though:

https://lore.kernel.org/rust-for-linux/20260303061000.73970-1-tomo@aliasing.net/

Best,
Gary