Rust Discussion: What to do about payload data's drop() vs atomic context

[Philipp Stanner <phasta@mailbox.org>]

Yo folks,

we (DRM crowd) are currently in the process of upstreaming DmaFences,
data structures for communication between GPU / driver and userspace.
They are inherently difficult to get right. Our discussions [1] have
now repeatedly circled around a supposedly extremely difficult problem:

struct Foo<T> {
data: T, // `T` defined & passed by API user
}


Sometimes we, the API backend, will drop Foo in atomic context. Should
T have a drop implementation, and should that implementation do
something illegal in atomic context, we might deadlock.

It gets further complicated by the fact that T might often be
refcounted, and illegal actions might only take place sometimes, when
the refcount finally hits 0.

Since T is defined by the user / driver, it can become arbitrarily
complex and might include all sorts of other Rust data types, each with
their own Drop implementation.

So to get this deadlock-safe you'd need to audit all inherited data
types' drop implementations.

Suggested solutions for this problem that I've heard are:

   1. Demand in your API that T implements an unsafe trait, for which
      you document what the rules are (no sleeping etc.).
   2. Demand that T does not implement Drop.
   3. Only allow a T that gets dropped in a deferred way outside of
      atomic context.
   4. Try to ensure that Foo<T> never drops in atomic context (not
      really fully achievable, because the user can always pass
      Option<T>, and take the value in the mut borrow our API needs to
      implement to give (temporary) access to T back to the user in a
      callback.
   5. In your API, implement the most common use-cases (like kicking
      off a work item) in a way that passed data does not need to drop
      from atomic context.

IIRC Gary has it on his radar to get klint to check everything within T
for invalid drop operations? Is that doable any time soon? Would that
be 100% bullet-proof or would it work like "best effort"?

The C side seems to address those problems with might_sleep() et al.,
only detecting problems at runtime.

I'm opening this thread because I suspect that "drop() must not
sleep()" is a very common problem in Kernel Rust and I'd like to hear
how other people have solved the problem.

If we'd agree that demanding an unsafe-trait for T for such APIs is the
strategy with the lowest cost-benefit ratio, I suspect that it would
make sense to define such a trait kernel-wide.

Please share all your thoughts.

For DmaFence, we now need to decide how to deal with the user data,
i.e. which strategy to implement before we land it upstream.

I'm bringing this up because we really want to get DmaFence right.


Greetings
Philipp


[1] https://lore.kernel.org/all/20260530143541.229628-2-phasta@kernel.org/