On 11/18/25 16:00, Thomas Hellström wrote: > Hi, Pierre-Eric > > On Thu, 2025-11-13 at 17:05 +0100, Pierre-Eric Pelloux-Prayer wrote: >> Until now ttm stored a single pipelined eviction fence which means >> drivers had to use a single entity for these evictions. >> >> To lift this requirement, this commit allows up to 8 entities to >> be used. >> >> Ideally a dma_resv object would have been used as a container of >> the eviction fences, but the locking rules makes it complex. >> dma_resv all have the same ww_class, which means "Attempting to >> lock more mutexes after ww_acquire_done." is an error. >> >> One alternative considered was to introduced a 2nd ww_class for >> specific resv to hold a single "transient" lock (= the resv lock >> would only be held for a short period, without taking any other >> locks). > > Wouldn't it be possible to use lockdep_set_class_and_name() to modify > the resv lock class for these particular resv objects after they are > allocated? Reusing the resv code certainly sounds attractive.
Even when we can convince lockdep that this is unproblematic I don't think re-using the dma_resv code here is a good idea. We should avoid dynamic memory allocation is much as possible and a static array seems to do the job just fine. Regards, Christian. > > Thanks, > Thomas >
