From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>,
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
Jocelyn Falempe <jfalempe@redhat.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Intel-xe] [PATCH v5 1/7] drm: fix drmm_mutex_init()
Date: Wed, 17 May 2023 19:03:10 +0200 [thread overview]
Message-ID: <79df281c4b74ef7de401b6f93ea65301377a5319.camel@linux.intel.com> (raw)
In-Reply-To: <dcaf0964-3264-6a35-469d-75ff520d5f6b@intel.com>
On Wed, 2023-05-17 at 17:29 +0100, Matthew Auld wrote:
> On 17/05/2023 17:05, Stanislaw Gruszka wrote:
> > On Wed, May 17, 2023 at 04:22:38PM +0100, Matthew Auld wrote:
> > > In mutex_init() lockdep seems to identify a lock by defining a
> > > static
> > > key for each lock class. However if we wrap the whole thing in a
> > > function the static key will be the same for everything calling
> > > that
> > > function, which looks to be the case for drmm_mutex_init(). This
> > > then
> > > results in impossible lockdep splats since lockdep thinks
> > > completely
> > > unrelated locks are the same lock class. The other issue is that
> > > when
> > > looking at splats we lose the actual lock name, where instead of
> > > seeing
> > > something like xe->mem_access.lock for the name, we just see
> > > something
> > > generic like lock#8.
> > >
> > > Attempt to fix this by converting drmm_mutex_init() into a macro,
> > > which
> > > should ensure that mutex_init() behaves as expected.
> >
> > Nice catch :-) we observed lockdep deadlock false alarms too, but I
> > could
> > not spot it out and were adding lockdep_set_class(key) to avoid
> > those.
> >
> >
> > > +static inline void __drmm_mutex_release(struct drm_device *dev,
> > > void *res)
> >
> > Can this be inline if used in drmm_add_action_or_reset() ?
>
> I think so. Did I missing something here? It at least builds for me.
I think in each file that contains a drmm_mutex_init(), the code will
need a pointer to the function __drmm_mutex_release() and the compiler
will therefore need to emit a non-inlined static version of the
function in that file. Not sure if that's a problem, though. If so
could make it extern?
/Thomas
>
> >
> >
> > > +{
> > > + struct mutex *lock = res;
> > > +
> > > + mutex_destroy(lock);
> > > +}
> > > +
> > > +/**
> > > + * drmm_mutex_init - &drm_device-managed mutex_init()
> > > + * @dev: DRM device
> > > + * @lock: lock to be initialized
> > > + *
> > > + * Returns:
> > > + * 0 on success, or a negative errno code otherwise.
> > > + *
> > > + * This is a &drm_device-managed version of mutex_init(). The
> > > initialized
> > > + * lock is automatically destroyed on the final drm_dev_put().
> > > + */
> > > +#define drmm_mutex_init(dev, lock)
> > > ({ \
> > > + mutex_init(lock);
> > > \
> > > + drmm_add_action_or_reset(dev, __drmm_mutex_release,
> > > lock); \
> > > +})
> > > \
> >
> > Regards
> > Stanislaw
> >
> >
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>,
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
Jocelyn Falempe <jfalempe@redhat.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH v5 1/7] drm: fix drmm_mutex_init()
Date: Wed, 17 May 2023 19:03:10 +0200 [thread overview]
Message-ID: <79df281c4b74ef7de401b6f93ea65301377a5319.camel@linux.intel.com> (raw)
In-Reply-To: <dcaf0964-3264-6a35-469d-75ff520d5f6b@intel.com>
On Wed, 2023-05-17 at 17:29 +0100, Matthew Auld wrote:
> On 17/05/2023 17:05, Stanislaw Gruszka wrote:
> > On Wed, May 17, 2023 at 04:22:38PM +0100, Matthew Auld wrote:
> > > In mutex_init() lockdep seems to identify a lock by defining a
> > > static
> > > key for each lock class. However if we wrap the whole thing in a
> > > function the static key will be the same for everything calling
> > > that
> > > function, which looks to be the case for drmm_mutex_init(). This
> > > then
> > > results in impossible lockdep splats since lockdep thinks
> > > completely
> > > unrelated locks are the same lock class. The other issue is that
> > > when
> > > looking at splats we lose the actual lock name, where instead of
> > > seeing
> > > something like xe->mem_access.lock for the name, we just see
> > > something
> > > generic like lock#8.
> > >
> > > Attempt to fix this by converting drmm_mutex_init() into a macro,
> > > which
> > > should ensure that mutex_init() behaves as expected.
> >
> > Nice catch :-) we observed lockdep deadlock false alarms too, but I
> > could
> > not spot it out and were adding lockdep_set_class(key) to avoid
> > those.
> >
> >
> > > +static inline void __drmm_mutex_release(struct drm_device *dev,
> > > void *res)
> >
> > Can this be inline if used in drmm_add_action_or_reset() ?
>
> I think so. Did I missing something here? It at least builds for me.
I think in each file that contains a drmm_mutex_init(), the code will
need a pointer to the function __drmm_mutex_release() and the compiler
will therefore need to emit a non-inlined static version of the
function in that file. Not sure if that's a problem, though. If so
could make it extern?
/Thomas
>
> >
> >
> > > +{
> > > + struct mutex *lock = res;
> > > +
> > > + mutex_destroy(lock);
> > > +}
> > > +
> > > +/**
> > > + * drmm_mutex_init - &drm_device-managed mutex_init()
> > > + * @dev: DRM device
> > > + * @lock: lock to be initialized
> > > + *
> > > + * Returns:
> > > + * 0 on success, or a negative errno code otherwise.
> > > + *
> > > + * This is a &drm_device-managed version of mutex_init(). The
> > > initialized
> > > + * lock is automatically destroyed on the final drm_dev_put().
> > > + */
> > > +#define drmm_mutex_init(dev, lock)
> > > ({ \
> > > + mutex_init(lock);
> > > \
> > > + drmm_add_action_or_reset(dev, __drmm_mutex_release,
> > > lock); \
> > > +})
> > > \
> >
> > Regards
> > Stanislaw
> >
> >
next prev parent reply other threads:[~2023-05-17 17:03 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 15:22 [Intel-xe] [PATCH v5 1/7] drm: fix drmm_mutex_init() Matthew Auld
2023-05-17 15:22 ` Matthew Auld
2023-05-17 15:22 ` [Intel-xe] [PATCH v5 2/7] Revert "drm/xe: Use atomic instead of mutex for xe_device_mem_access_ongoing" Matthew Auld
2023-05-17 15:22 ` [Intel-xe] [PATCH v5 3/7] drm/xe: don't allocate under ct->lock Matthew Auld
2023-05-17 15:50 ` Rodrigo Vivi
2023-05-17 15:22 ` [Intel-xe] [PATCH v5 4/7] drm/xe: keep pulling mem_access_get further back Matthew Auld
2023-05-17 15:53 ` Rodrigo Vivi
2023-05-17 15:22 ` [Intel-xe] [PATCH v5 5/7] drm/xe/ggtt: prime ggtt->lock against FS_RECLAIM Matthew Auld
2023-05-17 15:48 ` Rodrigo Vivi
2023-05-17 16:21 ` Matthew Auld
2023-05-17 15:22 ` [Intel-xe] [PATCH v5 6/7] drm/xe: fix xe_device_mem_access_get() races Matthew Auld
2023-05-19 20:25 ` Rodrigo Vivi
2023-05-22 9:49 ` Matthew Auld
2023-05-17 15:22 ` [Intel-xe] [PATCH v5 7/7] drm/xe: Use atomic for mem_access.ref Matthew Auld
2023-05-17 15:25 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [v5,1/7] drm: fix drmm_mutex_init() Patchwork
2023-05-17 15:27 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-17 15:31 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-17 15:49 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-05-17 16:05 ` [Intel-xe] [PATCH v5 1/7] " Stanislaw Gruszka
2023-05-17 16:05 ` Stanislaw Gruszka
2023-05-17 16:29 ` [Intel-xe] " Matthew Auld
2023-05-17 16:29 ` Matthew Auld
2023-05-17 17:03 ` Thomas Hellström [this message]
2023-05-17 17:03 ` Thomas Hellström
2023-05-17 17:47 ` [Intel-xe] " Thomas Zimmermann
2023-05-17 17:47 ` Thomas Zimmermann
2023-05-17 16:21 ` [Intel-xe] " Thomas Zimmermann
2023-05-17 16:21 ` Thomas Zimmermann
2023-05-17 17:04 ` [Intel-xe] " Matthew Auld
2023-05-17 17:04 ` Matthew Auld
2023-05-17 17:43 ` [Intel-xe] " Thomas Zimmermann
2023-05-17 17:43 ` Thomas Zimmermann
2023-05-18 9:51 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [v5,1/7] drm: fix drmm_mutex_init() (rev2) Patchwork
2023-05-18 9:52 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-18 9:56 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-18 10:16 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-05-19 15:49 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [v5,1/7] drm: fix drmm_mutex_init() (rev3) Patchwork
2023-05-19 15:50 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-19 15:54 ` [Intel-xe] ✓ CI.Build: " Patchwork
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=79df281c4b74ef7de401b6f93ea65301377a5319.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jfalempe@redhat.com \
--cc=matthew.auld@intel.com \
--cc=stanislaw.gruszka@linux.intel.com \
--cc=tzimmermann@suse.de \
/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.