All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Li, Yunxiang (Teddy)" <Yunxiang.Li@amd.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm: get lock before accessing vblank refcount
Date: Tue, 6 Sep 2022 23:58:58 +0200	[thread overview]
Message-ID: <YxfCoj096m97QtQv@phenom.ffwll.local> (raw)
In-Reply-To: <BL0PR12MB2532B9036E590FDAB14755DAED7E9@BL0PR12MB2532.namprd12.prod.outlook.com>

On Tue, Sep 06, 2022 at 08:18:30PM +0000, Li, Yunxiang (Teddy) wrote:
> [Public]
> 
> Hi Daniel,
> 
> I added the check because I saw that the refcount was always
> updated/read with lock held elsewhere, and the pattern looked very
> similar to in the put e.g. drm_crtc_vblank_reset. This patchset is
> outdated by now and I've sent a fix to amd-gfx for the specific issue in
> amdgpu.
> 
> However, I think the way drm_crtc_vblank_on/off functions increments the
> refcount without enabling the vblank is still a bit risky given how many
> unchecked calls to drm_vblank_get there is elsewhere. Maybe it's more
> appropriate to simply add an WARN to drm_vblank_get when it's called
> with inmodeset set? This way the WARN happens right at the problematic
> point, instead of far into the future when the put is called.

drm_crtc_vblank_get failing when the crtc is off is how this is supposed
to work, calling WARN_ON or similar in there would upset everything.

What might be an option is adding __must_check or similar annotations, but
the problem is that in many cases the driver knows that it cannot fail, so
this isn't great either.

Another option would be to split this up into drm_crtc_vblank_get with
void return value (and a WARN_ON when it fails), and
drm_crtc_vblank_try_get, which can fail. And then go through _all_ the
callers and audit them.

Imo not really worth the work, but we could do that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2022-09-06 21:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-22 21:52 [PATCH 1/2] drm: Fix vblank refcount during modeset Yunxiang Li
2022-07-22 21:52 ` [PATCH 2/2] drm: get lock before accessing vblank refcount Yunxiang Li
2022-09-06 19:20   ` Daniel Vetter
2022-09-06 20:18     ` Li, Yunxiang (Teddy)
2022-09-06 21:58       ` Daniel Vetter [this message]
2022-08-02 14:51 ` [PATCH 1/2] drm: Fix vblank refcount during modeset Li, Yunxiang (Teddy)

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=YxfCoj096m97QtQv@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Yunxiang.Li@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    /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.