Re: [PATCH v2 7/7] rust: drm: make Driver::File lifetime-parameterized

[Alice Ryhl]

On Sat, Nov 7, 2026 at 2:26 PM Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>
> On Sat Nov 7, 2026 at 9:16 AM CET, Alice Ryhl wrote:
> > On Sat, Nov 07, 2026 at 03:03:25AM +0100, Danilo Krummrich wrote:
> >> +        // Run driver destructors without `filelist_mutex`. Take each link before dropping its
> >> +        // allocation to avoid recursively dropping the entire chain.
> >> +        while let Some(mut data) = files {
> >> +            files = data.as_mut().project().next.take();
> >> +            drop(data);
> >> +            drm.open_count.fetch_sub(1, Release);
> >> +        }
> >
> > Instead of transferring all the files to another linked list, how about
> > taking them off the file list one-by-one? If you release the mutex in
> > between dropping each file, then we still avoid deadlocks if the file
> > private data destructor takes the lock.
>
> I did consider this, and technically it would (currently) work with
> list_del_init(), but I did not like it because it would be a very subtle change
> in semantics from the perspective of the C code. (I.e. for C drivers the list
> entry would remain intact after this callback, whereas for Rust drivers it would
> be removed.)
>
> Actually, I did hesitate to move drop() out of the filelist_mutex protected path
> at all because I don't think there's a way this could actually ever produce a
> lock inversion, but the "move to a separate list" approach was pretty simple and
> very few code so I thought it's worth ruling it out anyway.
>
> (In any case, I'll soon start working on the C code to implement a common
> lifecycle scheme.  Once we have that, the Rust code becomes even more straight
> foward.)

As per discussion on chat, my suggestion doesn't quite work. The point
of moving to a separate list is that we don't want to modify the
existing file list.

Reviewed-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>

Alice