All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Martin Peres <martin.peres@labri.fr>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH v3 3/4] drm/ttm: convert to unified vma offset manager
Date: Thu, 18 Jul 2013 13:02:40 +0200	[thread overview]
Message-ID: <CAKMK7uG6YT2peaCvMP5iLhFGKrb-mHRTHAQsdEDNic9cmsTsdg@mail.gmail.com> (raw)
In-Reply-To: <51E7AD18.4050100@vmware.com>

On Thu, Jul 18, 2013 at 10:53 AM, Thomas Hellstrom
<thellstrom@vmware.com> wrote:
> A quick look, but not a full review:
>
> Looks mostly good, but it looks like the TTM vm lock isn't needed at all
> anymore (provided the vma offset manager is properly protected), since
> kref_get_unless_zero() is used when a reference after lookup is taken.
> (please see the kref_get_unless_zero documentation examples). When
> drm_vma_offset_remove() is called, the kref value is unconditionally zero,
> and that should block any successful lookup.
>
> Otherwise, if the vma offset manager always needs external locking to make
> lookup + referencing atomic, then perhaps locking should be completely
> left to the caller?

Somehow I've thought plain gem drivers had this fixed, but looks like
I've never gotten around to it. So we need to rework things anyway.

What about a drm_vma_offset_lookup_unlocked which just checks that the
caller is holding the offset manager's lock? That way everyone can
follow up with the get_unless_zero dance correctly. And ttm could drop
it's own vm lock.

I've considered whether we should just move the vma node into struct
drm_gem_object and let the offset manager do the dance, but that's
much more invasive. And I'm not sure it's the right thing to do yet.
So I think we should consider this only as a follow-up series.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2013-07-18 11:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 18:14 [PATCH v3 0/4] Unified VMA Offset Manager v3 David Herrmann
2013-07-17 18:14 ` [PATCH v3 1/4] drm: add unified vma offset manager David Herrmann
2013-07-17 18:14 ` [PATCH v3 2/4] drm/gem: convert to new unified vma manager David Herrmann
2013-07-18 19:01   ` Patrik Jakobsson
2013-07-17 18:14 ` [PATCH v3 3/4] drm/ttm: convert to unified vma offset manager David Herrmann
2013-07-18  8:53   ` Thomas Hellstrom
2013-07-18 11:02     ` Daniel Vetter [this message]
2013-07-18 11:07     ` David Herrmann
2013-07-18 11:24       ` Thomas Hellstrom
2013-07-18 20:54         ` David Herrmann
2013-07-19  2:03           ` Jerome Glisse
2013-07-19  7:24           ` Maarten Lankhorst
2013-07-19  9:13           ` Thomas Hellstrom
     [not found]             ` <CANq1E4SSLtezptzo18TD3fLG_zoRwR17kMxEi96-e957F5wL1A@mail.gmail.com>
2013-07-22 10:55               ` David Herrmann
2013-07-22 11:45                 ` Thomas Hellstrom
2013-07-17 18:14 ` [PATCH v3 4/4] drm/vma: provide drm_vma_node_unmap() helper David Herrmann
2013-07-23 12:47 ` [PATCH v4 0/4] Unified VMA Offset Manager David Herrmann
2013-07-23 12:47   ` [PATCH v4 1/4] drm: add unified vma offset manager David Herrmann
2013-07-24 15:35     ` Daniel Vetter
2013-07-24 16:10       ` David Herrmann
2013-07-24 19:06     ` [PATCH v5 " David Herrmann
2013-07-23 12:47   ` [PATCH v4 2/4] drm/gem: convert to new unified vma manager David Herrmann
2013-07-24 15:52     ` Daniel Vetter
2013-07-24 16:27       ` David Herrmann
2013-07-24 19:07     ` [PATCH v5 " David Herrmann
2013-07-23 12:47   ` [PATCH v4 3/4] drm/ttm: convert to unified vma offset manager David Herrmann
2013-07-24 15:57     ` Daniel Vetter
2013-07-24 19:08     ` [PATCH v5 " David Herrmann
2013-07-23 12:47   ` [PATCH v4 4/4] drm/vma: provide drm_vma_node_unmap() helper David Herrmann
2013-07-24 15:58     ` Daniel Vetter
2013-07-24 19:10     ` [PATCH v5 " David Herrmann

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=CAKMK7uG6YT2peaCvMP5iLhFGKrb-mHRTHAQsdEDNic9cmsTsdg@mail.gmail.com \
    --to=daniel@ffwll.ch \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=martin.peres@labri.fr \
    --cc=thellstrom@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.