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