On 11/15/2013 10:29 AM, Daniel Vetter wrote:
On Fri, Nov 15, 2013 at 12:24:32AM -0800, Thomas Hellstrom wrote:
A lockdep warning is hit when evicting surfaces and reserving the backup
buffer. Since this buffer can only be reserved by the process holding the
surface reservation or by the buffer eviction processes that use tryreserve,
there is no real deadlock here, but there's no other way to silence lockdep
than to use a tryreserve. This means the reservation might fail if the buffer
is about to be evicted or swapped out, but we now have code in place to
handle that reasonably well.
Signed-off-by: Thomas Hellstrom <thellstrom@xxxxxxxxxx>
Hm, for similar cases where there's an additional hirarchy imposed onto
the locking order lockdep supports subclases. Block devices use that to
nest partitions within the overall block device.
Have you looked into wiring this up for ww_mutexes, i.e. fix lockdep
instaed of working around it in the code? I'm thinking of a
ww_mutex_lock_nested similar to mutex_lock_nested.
Cheers, Daniel
Yeah, I've thought of that, and that would definitely come in handy for
upcoming page-table-bos where reservation should not fail, and where I
need to play other tricks, and I might have a chance to look at that
before merging that code.
However in this particular case I'm not sure it will work, because the
same buffers can be reserved at different nesting levels either as part
of command submission or as part of eviction. In the block device
analogy, a mutex could be taken both as a device mutex or a partition
mutex. I haven't looked into the lock_nested semantics close enough to
figure out whether that would work or confuse lockdep beyond recovery :).
In any case, this needs a quick workaround for now.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
