<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/rust/kernel/sync/atomic/ordering.rs, branch v7.3-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>rust: sync: Add generic memory barriers</title>
<updated>2026-08-04T12:52:54+00:00</updated>
<author>
<name>Gary Guo</name>
<email>gary@garyguo.net</email>
</author>
<published>2026-06-09T15:38:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=72856afd33f2fa166c06f1536003e300e51ecf09'/>
<id>72856afd33f2fa166c06f1536003e300e51ecf09</id>
<content type='text'>
Implement a generic interface for memory barriers (full system/DMA/SMP).
The interface uses a parameter to force user to specify their intent
with barriers.

Provide `Read`, `Write`, `Full` orderings which map to the existing
`rmb()`, `wmb()` and `mb()`. Generic is used here instead of providing
individual standalone functions to reduce code duplication; for example,
the `CONFIG_SMP` check in `smp_mb` is uniformly implemented for all SMP
barriers. This could extend to `virt_mb`'s if they're introduced in the
future. It would also make it easier if new ordering types are
introduced in the future (e.g. `Acquire`, `Release`).

Signed-off-by: Gary Guo &lt;gary@garyguo.net&gt;
Signed-off-by: Boqun Feng &lt;boqun@kernel.org&gt;
Link: https://patch.msgid.link/20260609-rust-barrier-v2-2-30fcc48e1cd0@garyguo.net
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Implement a generic interface for memory barriers (full system/DMA/SMP).
The interface uses a parameter to force user to specify their intent
with barriers.

Provide `Read`, `Write`, `Full` orderings which map to the existing
`rmb()`, `wmb()` and `mb()`. Generic is used here instead of providing
individual standalone functions to reduce code duplication; for example,
the `CONFIG_SMP` check in `smp_mb` is uniformly implemented for all SMP
barriers. This could extend to `virt_mb`'s if they're introduced in the
future. It would also make it easier if new ordering types are
introduced in the future (e.g. `Acquire`, `Release`).

Signed-off-by: Gary Guo &lt;gary@garyguo.net&gt;
Signed-off-by: Boqun Feng &lt;boqun@kernel.org&gt;
Link: https://patch.msgid.link/20260609-rust-barrier-v2-2-30fcc48e1cd0@garyguo.net
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: sync: atomic: Add ordering annotation types</title>
<updated>2025-09-15T07:38:33+00:00</updated>
<author>
<name>Boqun Feng</name>
<email>boqun.feng@gmail.com</email>
</author>
<published>2025-09-05T04:41:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b638c9bc471030ebd898b57c5bf7c96f6d70cda4'/>
<id>b638c9bc471030ebd898b57c5bf7c96f6d70cda4</id>
<content type='text'>
Preparation for atomic primitives. Instead of a suffix like _acquire, a
method parameter along with the corresponding generic parameter will be
used to specify the ordering of an atomic operations. For example,
atomic load() can be defined as:

	impl&lt;T: ...&gt; Atomic&lt;T&gt; {
	    pub fn load&lt;O: AcquireOrRelaxed&gt;(&amp;self, _o: O) -&gt; T { ... }
	}

and acquire users would do:

	let r = x.load(Acquire);

relaxed users:

	let r = x.load(Relaxed);

doing the following:

	let r = x.load(Release);

will cause a compiler error.

Compared to suffixes, it's easier to tell what ordering variants an
operation has, and it also make it easier to unify the implementation of
all ordering variants in one method via generic. The `TYPE` associate
const is for generic function to pick up the particular implementation
specified by an ordering annotation.

Signed-off-by: Boqun Feng &lt;boqun.feng@gmail.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Reviewed-by: Elle Rhumsaa &lt;elle@weathered-steel.dev&gt;
Link: https://lore.kernel.org/all/20250719030827.61357-4-boqun.feng@gmail.com/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Preparation for atomic primitives. Instead of a suffix like _acquire, a
method parameter along with the corresponding generic parameter will be
used to specify the ordering of an atomic operations. For example,
atomic load() can be defined as:

	impl&lt;T: ...&gt; Atomic&lt;T&gt; {
	    pub fn load&lt;O: AcquireOrRelaxed&gt;(&amp;self, _o: O) -&gt; T { ... }
	}

and acquire users would do:

	let r = x.load(Acquire);

relaxed users:

	let r = x.load(Relaxed);

doing the following:

	let r = x.load(Release);

will cause a compiler error.

Compared to suffixes, it's easier to tell what ordering variants an
operation has, and it also make it easier to unify the implementation of
all ordering variants in one method via generic. The `TYPE` associate
const is for generic function to pick up the particular implementation
specified by an ordering annotation.

Signed-off-by: Boqun Feng &lt;boqun.feng@gmail.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Reviewed-by: Elle Rhumsaa &lt;elle@weathered-steel.dev&gt;
Link: https://lore.kernel.org/all/20250719030827.61357-4-boqun.feng@gmail.com/
</pre>
</div>
</content>
</entry>
</feed>
