All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: jglisse@redhat.com, linux-graphics-maintainer@vmware.com,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/vmwgfx: Fix false lockdep warning
Date: Fri, 15 Nov 2013 11:28:02 +0100	[thread overview]
Message-ID: <5285F732.70001@vmware.com> (raw)
In-Reply-To: <20131115092946.GQ22741@phenom.ffwll.local>

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@vmware.com>
> 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

      reply	other threads:[~2013-11-15 10:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-15  8:24 [PATCH 0/2] Fix a false lockdep warning on vmwgfx Thomas Hellstrom
2013-11-15  8:24 ` [PATCH 1/2] drm/ttm: Allow execbuf util reserves without ticket Thomas Hellstrom
2013-11-15  8:24 ` [PATCH 2/2] drm/vmwgfx: Fix false lockdep warning Thomas Hellstrom
2013-11-15  9:29   ` Daniel Vetter
2013-11-15 10:28     ` Thomas Hellstrom [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5285F732.70001@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jglisse@redhat.com \
    --cc=linux-graphics-maintainer@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.