Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset
Date: Wed, 6 Sep 2023 13:02:41 +0200	[thread overview]
Message-ID: <ZPhcUQrROMrftxfr@phenom.ffwll.local> (raw)
In-Reply-To: <87jzt3hb3d.fsf@intel.com>

On Wed, Sep 06, 2023 at 01:04:06PM +0300, Jani Nikula wrote:
> On Wed, 06 Sep 2023, Andi Shyti <andi.shyti@linux.intel.com> wrote:
> > It's the developer's responsibility to test its code with
> > debug_lockdep and fix all the potential deadlocks and ignore the
> > false ones.
> 
> No. Manual validation of lockdep reports is not feasible. Lockdep is the
> tool to validate locking. It's the developer's responsibility to make
> lockdep understand the design.

Yeah I guess I need to drop my locking design principle once more:

If lockdep doesn't understand your locking design, your design is shit.

You need to fix the design, not play whack-a-mole with lockdep. Or worse,
pretend there's no problem and just disable lockdep outright.

If you don't understand your design, and can't succinctly explain it (or
demonstrate the full hierarchy with lockdep priming, testing in CI isn't
good enough for anything remotely complex), then you have a _really_ big
problem. Yes CI is good at catching accidental changes in locking design,
but if you use it for anything more than that you're in deep trouble.

Cheers, Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2023-09-06 11:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11 18:20 [Intel-gfx] [PATCH v5] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset Zhanjun Dong
2023-08-11 19:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid circular locking dependency when flush delayed work on gt reset (rev5) Patchwork
2023-08-11 19:15 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-08-11 19:34 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-08-21 14:09 ` [Intel-gfx] [PATCH v5] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset Andi Shyti
2023-08-22 13:50 ` Daniel Vetter
2023-08-22 14:14   ` Dong, Zhanjun
2023-08-22 14:28     ` Daniel Vetter
2023-08-22 18:53 ` John Harrison
2023-08-23 16:00   ` Daniel Vetter
2023-08-23 17:37     ` John Harrison
2023-08-28 23:01       ` John Harrison
2023-09-06  6:50         ` Daniel Vetter
2023-09-06 18:40           ` John Harrison
2023-08-31 14:00       ` Andi Shyti
2023-08-31 22:27         ` John Harrison
2023-09-06  9:17           ` Andi Shyti
2023-09-06 10:04             ` Jani Nikula
2023-09-06 11:02               ` Daniel Vetter [this message]
2023-09-06 18:49             ` John Harrison
2023-08-29 10:11   ` Andi Shyti

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=ZPhcUQrROMrftxfr@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox