dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/4] reservation: sprinkle some WARN_ON()s
Date: Fri, 01 Apr 2016 10:48:34 +0200	[thread overview]
Message-ID: <1459500514.5054.9.camel@pengutronix.de> (raw)
In-Reply-To: <1459456012-16248-2-git-send-email-robdclark@gmail.com>

Am Donnerstag, den 31.03.2016, 16:26 -0400 schrieb Rob Clark:
> A bit overkill since, for example, the rcu_dereference_protected() in
> reservation_object_get_list() will WARN.  But this is much less subtle
> for folks reading the code.
> 
> Signed-off-by: Rob Clark <robdclark@gmail.com>
> ---
>  drivers/dma-buf/reservation.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index c0bd572..0de3ea6 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -52,6 +52,8 @@ int reservation_object_reserve_shared(struct reservation_object *obj)
>  	struct reservation_object_list *fobj, *old;
>  	u32 max;
>  
> +	WARN_ON(!ww_mutex_is_locked(&obj->lock));
> +
I don't really like those WARN_ONs to enforce the expected locking.

IMHO lockdep_assert_held is the better way, as it's as obvious as the
WARN_ONs to someone reading the code, blows up in the same way if you
are using a lockdep enabled build (which should be default when touching
locking code) and avoids the runtime overhead for production kernels.

It also checks that it's really the expected execution strand holding
the lock and not some other thread on another CPU.

I don't know if lockdep_assert_held works with ww_mutex currently, if
not we should definitely extend it to do so.

Regards,
Lucas

>  	old = reservation_object_get_list(obj);
>  
>  	if (old && old->shared_max) {
> @@ -189,6 +191,8 @@ void reservation_object_add_shared_fence(struct reservation_object *obj,
>  {
>  	struct reservation_object_list *old, *fobj = obj->staged;
>  
> +	WARN_ON(!ww_mutex_is_locked(&obj->lock));
> +
>  	old = reservation_object_get_list(obj);
>  	obj->staged = NULL;
>  
> @@ -207,6 +211,8 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
>  	struct reservation_object_list *old;
>  	u32 i = 0;
>  
> +	WARN_ON(!ww_mutex_is_locked(&obj->lock));
> +
>  	old = reservation_object_get_list(obj);
>  	if (old)
>  		i = old->shared_count;


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-04-01  8:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-31 20:26 [PATCH 0/4] dma-buf/reservation doc updates Rob Clark
2016-03-31 20:26 ` [PATCH 1/4] reservation: sprinkle some WARN_ON()s Rob Clark
2016-04-01  8:48   ` Lucas Stach [this message]
2016-04-01 14:50     ` Rob Clark
2016-04-01 14:02   ` Christian König
2016-03-31 20:26 ` [PATCH 2/4] dma-buf: headerdoc fixes Rob Clark
2016-03-31 20:26 ` [PATCH 3/4] reservation: add headerdoc comments Rob Clark
2016-03-31 20:26 ` [PATCH 4/4] doc: update/fixup dma-buf related DocBook Rob Clark
2016-04-01 14:07 ` [PATCH 0/4] dma-buf/reservation doc updates Alex Deucher
2016-04-01 15:20   ` Sumit Semwal
2016-06-04 12:21     ` Daniel Vetter
2016-06-05 11:17       ` Sumit Semwal
2016-06-05 17:18         ` Daniel Vetter
2016-06-06  4:41           ` Sumit Semwal
     [not found] <Message-Id: <1459456012-16248-2-git-send-email-robdclark@gmail.com>
2016-04-08  0:52 ` [PATCH] reservation: sprinkle some WARN_ON()s Rob Clark
2016-06-04 12:52   ` Daniel Vetter
2016-06-04 15:47     ` Rob Clark

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=1459500514.5054.9.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robdclark@gmail.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