On Wed, Nov 27, 2024 at 2:19 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>
> On 11/27/24 1:21 PM, Alice Ryhl wrote:
> > On Tue, Oct 22, 2024 at 11:33 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
> >> +impl<T> Drop for Devres<T> {
> >> + fn drop(&mut self) {
> >> + // Revoke the data, such that it gets dropped already and the actual resource is freed.
> >> + // `DevresInner` has to stay alive until the devres callback has been called. This is
> >> + // necessary since we don't know when `Devres` is dropped and calling
> >> + // `devm_remove_action()` instead could race with `devres_release_all()`.
> >> + self.revoke();
> >
> > When the destructor runs, it's guaranteed that nobody is accessing the
> > inner resource since the only way to do that is through the Devres
> > handle, but its destructor is running. Therefore, you can skip the
> > synchronize_rcu() call in this case.
>
> Yeah, I think this optimization should be possible.
>
> We'd require `Revocable` to have a `revoke_nosync` method for that I guess...
Agreed, you could have an unsafe method for revoking where you assert
that nobody else is accessing the value.
Alice
