Re: [PATCH v2 1/3] rust: sync: Add abstraction for synchronize_rcu()

[Philipp Stanner <phasta@mailbox.org>]

On Tue, 2026-06-23 at 12:24 +0200, Miguel Ojeda wrote:
> On Tue, Jun 23, 2026 at 11:49 AM Philipp Stanner <phasta@mailbox.org> wrote:
> > 
> > But it would be interesting to know more about how in general Rust's
> > unsafe comments are related to problems beyond UAF issues, and to what
> > degree we want to document context requirements.
> 
> I am confused by the UAF there. Did you mean UB?
> 
> Rust's `unsafe` is about way more than just use-after-free -- it is
> about all potential undefined behavior.
> 
> At the same time, it is not about merely "dangerous" things.
> 
> If you cannot possibly cause UB, then it is not in scope. Otherwise,
> it is very much in scope and the safety preconditions/requirements
> need to be clearly documented (`# Safety`) or justified (`//
> SAFETY:`).
> 
> Now, sometimes it may not make a lot of sense to duplicate a ton of
> information, so sometimes we lift text to the Rust module docs and
> refer to it; and sometimes it may also make more sense to refer to
> external docs. One way or another, the goal is to document the
> requirements and what is going on as clearly as possible.

Well, commonly, deadlock is not regarded to be UB.

For RCU the question really is to what extend one wants to have it. The
overall robustness requirement here is definitely for the Rust function
rcu::synchronize_rcu(), since the API caller is the one in charge of
the execution context.

If all potential failures one can cause by calling that function at the
wrong place were regarded to be undefined behavior, then a
synchronize_rcu() Rust function would have to be an unsafe function
always, making a wrapper pointless.

Similarly, Rust's drop() implementations might be potentially "unsafe"
with a hyper-strict definition (note that I'm unsure whether calling
synchronize_rcu() in atomic context is actually even defined behavior;
I think it is. I'm just brainstorming here)

I think briefly documenting the context requirement is fine, but from a
consistency and pragmatism perspective I would not make that a formal
safety requirement.


P.

> 
> Cheers,
> Miguel