[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Guenter Roeck]

spin_is_locked() always returns false in uniprocessor configurations
and can therefore not be used with BUG_ON. Replace it with
assert_spin_locked(), which exists for that very purpose.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
 drivers/gpu/drm/msm/mdp/mdp_kms.c          | 2 +-
 drivers/gpu/drm/nouveau/core/core/event.c  | 4 ++--
 drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
 drivers/gpu/drm/omapdrm/omap_irq.c         | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c b/drivers/gpu/drm/msm/mdp/mdp_kms.c
index 03455b6..92a1531 100644
--- a/drivers/gpu/drm/msm/mdp/mdp_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c
@@ -34,7 +34,7 @@ static void update_irq(struct mdp_kms *mdp_kms)
 	struct mdp_irq *irq;
 	uint32_t irqmask = mdp_kms->vblank_mask;
 
-	BUG_ON(!spin_is_locked(&list_lock));
+	assert_spin_locked(&list_lock);
 
 	list_for_each_entry(irq, &mdp_kms->irq_list, node)
 		irqmask |= irq->irqmask;
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c b/drivers/gpu/drm/nouveau/core/core/event.c
index 0540a48..9327117 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
 void
 nvkm_event_put(struct nvkm_event *event, u32 types, int index)
 {
-	BUG_ON(!spin_is_locked(&event->refs_lock));
+	assert_spin_locked(&event->refs_lock);
 	while (types) {
 		int type = __ffs(types); types &= ~(1 << type);
 		if (--event->refs[index * event->types_nr + type] == 0) {
@@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int index)
 void
 nvkm_event_get(struct nvkm_event *event, u32 types, int index)
 {
-	BUG_ON(!spin_is_locked(&event->refs_lock));
+	assert_spin_locked(&event->refs_lock);
 	while (types) {
 		int type = __ffs(types); types &= ~(1 << type);
 		if (++event->refs[index * event->types_nr + type] == 1) {
diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c b/drivers/gpu/drm/nouveau/core/core/notify.c
index 76adb81..f70dbc4 100644
--- a/drivers/gpu/drm/nouveau/core/core/notify.c
+++ b/drivers/gpu/drm/nouveau/core/core/notify.c
@@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data, u32 size)
 	struct nvkm_event *event = notify->event;
 	unsigned long flags;
 
-	BUG_ON(!spin_is_locked(&event->list_lock));
+	assert_spin_locked(&event->list_lock);
 	BUG_ON(size != notify->size);
 
 	spin_lock_irqsave(&event->refs_lock, flags);
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c b/drivers/gpu/drm/omapdrm/omap_irq.c
index f035d2b..3eb097e 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev)
 	struct omap_drm_irq *irq;
 	uint32_t irqmask = priv->vblank_mask;
 
-	BUG_ON(!spin_is_locked(&list_lock));
+	assert_spin_locked(&list_lock);
 
 	list_for_each_entry(irq, &priv->irq_list, node)
 		irqmask |= irq->irqmask;
-- 
1.9.1

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

[-- Attachment #1.1: Type: text/plain, Size: 3732 bytes --]

Hello Roeck,

This should be replaced everywhere in driver.what do you say ?

Regards
Sanjeev Sharma


On Mon, Aug 11, 2014 at 10:01 AM, Guenter Roeck <linux@roeck-us.net> wrote:

> spin_is_locked() always returns false in uniprocessor configurations
> and can therefore not be used with BUG_ON. Replace it with
> assert_spin_locked(), which exists for that very purpose.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
>  drivers/gpu/drm/msm/mdp/mdp_kms.c          | 2 +-
>  drivers/gpu/drm/nouveau/core/core/event.c  | 4 ++--
>  drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c         | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp_kms.c
> index 03455b6..92a1531 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c
> @@ -34,7 +34,7 @@ static void update_irq(struct mdp_kms *mdp_kms)
>         struct mdp_irq *irq;
>         uint32_t irqmask = mdp_kms->vblank_mask;
>
> -       BUG_ON(!spin_is_locked(&list_lock));
> +       assert_spin_locked(&list_lock);
>
>         list_for_each_entry(irq, &mdp_kms->irq_list, node)
>                 irqmask |= irq->irqmask;
> diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
> b/drivers/gpu/drm/nouveau/core/core/event.c
> index 0540a48..9327117 100644
> --- a/drivers/gpu/drm/nouveau/core/core/event.c
> +++ b/drivers/gpu/drm/nouveau/core/core/event.c
> @@ -26,7 +26,7 @@
>  void
>  nvkm_event_put(struct nvkm_event *event, u32 types, int index)
>  {
> -       BUG_ON(!spin_is_locked(&event->refs_lock));
> +       assert_spin_locked(&event->refs_lock);
>         while (types) {
>                 int type = __ffs(types); types &= ~(1 << type);
>                 if (--event->refs[index * event->types_nr + type] == 0) {
> @@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int
> index)
>  void
>  nvkm_event_get(struct nvkm_event *event, u32 types, int index)
>  {
> -       BUG_ON(!spin_is_locked(&event->refs_lock));
> +       assert_spin_locked(&event->refs_lock);
>         while (types) {
>                 int type = __ffs(types); types &= ~(1 << type);
>                 if (++event->refs[index * event->types_nr + type] == 1) {
> diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c
> b/drivers/gpu/drm/nouveau/core/core/notify.c
> index 76adb81..f70dbc4 100644
> --- a/drivers/gpu/drm/nouveau/core/core/notify.c
> +++ b/drivers/gpu/drm/nouveau/core/core/notify.c
> @@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data,
> u32 size)
>         struct nvkm_event *event = notify->event;
>         unsigned long flags;
>
> -       BUG_ON(!spin_is_locked(&event->list_lock));
> +       assert_spin_locked(&event->list_lock);
>         BUG_ON(size != notify->size);
>
>         spin_lock_irqsave(&event->refs_lock, flags);
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
> b/drivers/gpu/drm/omapdrm/omap_irq.c
> index f035d2b..3eb097e 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev)
>         struct omap_drm_irq *irq;
>         uint32_t irqmask = priv->vblank_mask;
>
> -       BUG_ON(!spin_is_locked(&list_lock));
> +       assert_spin_locked(&list_lock);
>
>         list_for_each_entry(irq, &priv->irq_list, node)
>                 irqmask |= irq->irqmask;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

[-- Attachment #1.2: Type: text/html, Size: 4875 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Sun, 10 Aug 2014, Guenter Roeck wrote:

> spin_is_locked() always returns false in uniprocessor configurations
> and can therefore not be used with BUG_ON. Replace it with
> assert_spin_locked(), which exists for that very purpose.
> 

It may be helpful to assess whether any of these sites should be converted 
to lockdep_assert_held() so they have no cost when lockdep isn't enabled 
but still reveal problems when debugging.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Sun, 10 Aug 2014, Guenter Roeck wrote:

> spin_is_locked() always returns false in uniprocessor configurations
> and can therefore not be used with BUG_ON. Replace it with
> assert_spin_locked(), which exists for that very purpose.
> 

It may be helpful to assess whether any of these sites should be converted 
to lockdep_assert_held() so they have no cost when lockdep isn't enabled 
but still reveal problems when debugging.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

[-- Attachment #1.1: Type: text/plain, Size: 898 bytes --]

Hello David,

Do you see any problem in replacing with assert_spin_locked() and here is
old discusion  around the



On Mon, Aug 11, 2014 at 5:15 PM, David Rientjes <rientjes@google.com> wrote:

> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>
> > spin_is_locked() always returns false in uniprocessor configurations
> > and can therefore not be used with BUG_ON. Replace it with
> > assert_spin_locked(), which exists for that very purpose.
> >
>
> It may be helpful to assess whether any of these sites should be converted
> to lockdep_assert_held() so they have no cost when lockdep isn't enabled
> but still reveal problems when debugging.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

[-- Attachment #1.2: Type: text/html, Size: 1631 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

[-- Attachment #1.1: Type: text/plain, Size: 1220 bytes --]

Hello David,

Here is the old discussion carried out on this.

http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802

Regards
Sanjeev Sharma


On Mon, Aug 11, 2014 at 5:31 PM, sanjeev sharma <sanjeevsharmaengg@gmail.com
> wrote:

> Hello David,
>
> Do you see any problem in replacing with assert_spin_locked() and here is
> old discusion  around the
>
>
>
> On Mon, Aug 11, 2014 at 5:15 PM, David Rientjes <rientjes@google.com>
> wrote:
>
>> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>>
>> > spin_is_locked() always returns false in uniprocessor configurations
>> > and can therefore not be used with BUG_ON. Replace it with
>> > assert_spin_locked(), which exists for that very purpose.
>> >
>>
>> It may be helpful to assess whether any of these sites should be converted
>> to lockdep_assert_held() so they have no cost when lockdep isn't enabled
>> but still reveal problems when debugging.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2420 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Guenter Roeck]

On 08/11/2014 04:45 AM, David Rientjes wrote:
> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>
>> spin_is_locked() always returns false in uniprocessor configurations
>> and can therefore not be used with BUG_ON. Replace it with
>> assert_spin_locked(), which exists for that very purpose.
>>
>
> It may be helpful to assess whether any of these sites should be converted
> to lockdep_assert_held() so they have no cost when lockdep isn't enabled
> but still reveal problems when debugging.
>
>

Possibly, but that would need to be done by someone with better knowledge
about locking and the code than me.

Guenter

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Mon, 11 Aug 2014, sanjeev sharma wrote:

> Hello David,
> 
> Here is the old discussion carried out on this.
> 
> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
> 

I'm suggesting that if you don't want to incur the cost of the conditional 
everytime you call a certain function with assert_spin_locked() that you 
could covert these to lockdep_assert_held() so the check is only done when 
lockdep is enabled for debugging.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Mon, 11 Aug 2014, sanjeev sharma wrote:

> Hello David,
> 
> Here is the old discussion carried out on this.
> 
> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
> 

I'm suggesting that if you don't want to incur the cost of the conditional 
everytime you call a certain function with assert_spin_locked() that you 
could covert these to lockdep_assert_held() so the check is only done when 
lockdep is enabled for debugging.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Rob Clark]

On Mon, Aug 11, 2014 at 4:53 PM, David Rientjes <rientjes@google.com> wrote:
> On Mon, 11 Aug 2014, sanjeev sharma wrote:
>
>> Hello David,
>>
>> Here is the old discussion carried out on this.
>>
>> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
>>
>
> I'm suggesting that if you don't want to incur the cost of the conditional
> everytime you call a certain function with assert_spin_locked() that you
> could covert these to lockdep_assert_held() so the check is only done when
> lockdep is enabled for debugging.

not sure about the nouveau parts, but for the omap and msm hunks, this
code getting called at potentially vblank rate (so maybe once or twice
per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
so I don't always have it enabled.  So it sounds like for those two at
least assert_spin_locked() is a better option.

BR,
-R

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Rob Clark]

On Mon, Aug 11, 2014 at 4:53 PM, David Rientjes <rientjes@google.com> wrote:
> On Mon, 11 Aug 2014, sanjeev sharma wrote:
>
>> Hello David,
>>
>> Here is the old discussion carried out on this.
>>
>> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
>>
>
> I'm suggesting that if you don't want to incur the cost of the conditional
> everytime you call a certain function with assert_spin_locked() that you
> could covert these to lockdep_assert_held() so the check is only done when
> lockdep is enabled for debugging.

not sure about the nouveau parts, but for the omap and msm hunks, this
code getting called at potentially vblank rate (so maybe once or twice
per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
so I don't always have it enabled.  So it sounds like for those two at
least assert_spin_locked() is a better option.

BR,
-R

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Mon, 11 Aug 2014, Rob Clark wrote:

> > I'm suggesting that if you don't want to incur the cost of the conditional
> > everytime you call a certain function with assert_spin_locked() that you
> > could covert these to lockdep_assert_held() so the check is only done when
> > lockdep is enabled for debugging.
> 
> not sure about the nouveau parts, but for the omap and msm hunks, this
> code getting called at potentially vblank rate (so maybe once or twice
> per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> so I don't always have it enabled.  So it sounds like for those two at
> least assert_spin_locked() is a better option.
> 

Unless there's a bug, assert_spin_locked() is just going to incur an 
unnecessary cost every time it is called at runtime.  My suggestion was to 
limit that check only to debugging kernels that include enabling lockdep 
when tracking down problems rather than needlessly evaluating the 
conditional every time when there are no bugs.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Mon, 11 Aug 2014, Rob Clark wrote:

> > I'm suggesting that if you don't want to incur the cost of the conditional
> > everytime you call a certain function with assert_spin_locked() that you
> > could covert these to lockdep_assert_held() so the check is only done when
> > lockdep is enabled for debugging.
> 
> not sure about the nouveau parts, but for the omap and msm hunks, this
> code getting called at potentially vblank rate (so maybe once or twice
> per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> so I don't always have it enabled.  So it sounds like for those two at
> least assert_spin_locked() is a better option.
> 

Unless there's a bug, assert_spin_locked() is just going to incur an 
unnecessary cost every time it is called at runtime.  My suggestion was to 
limit that check only to debugging kernels that include enabling lockdep 
when tracking down problems rather than needlessly evaluating the 
conditional every time when there are no bugs.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

[-- Attachment #1.1: Type: text/plain, Size: 1216 bytes --]

Thanks all and I replaced with lockdep_assert_held() which seems less
overhead.

Regards
Sanjeev Sharma


On Tue, Aug 12, 2014 at 5:08 AM, David Rientjes <rientjes@google.com> wrote:

> On Mon, 11 Aug 2014, Rob Clark wrote:
>
> > > I'm suggesting that if you don't want to incur the cost of the
> conditional
> > > everytime you call a certain function with assert_spin_locked() that
> you
> > > could covert these to lockdep_assert_held() so the check is only done
> when
> > > lockdep is enabled for debugging.
> >
> > not sure about the nouveau parts, but for the omap and msm hunks, this
> > code getting called at potentially vblank rate (so maybe once or twice
> > per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> > so I don't always have it enabled.  So it sounds like for those two at
> > least assert_spin_locked() is a better option.
> >
>
> Unless there's a bug, assert_spin_locked() is just going to incur an
> unnecessary cost every time it is called at runtime.  My suggestion was to
> limit that check only to debugging kernels that include enabling lockdep
> when tracking down problems rather than needlessly evaluating the
> conditional every time when there are no bugs.
>

[-- Attachment #1.2: Type: text/html, Size: 1674 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Daniel Vetter]

On Mon, Aug 11, 2014 at 04:38:50PM -0700, David Rientjes wrote:
> On Mon, 11 Aug 2014, Rob Clark wrote:
> 
> > > I'm suggesting that if you don't want to incur the cost of the conditional
> > > everytime you call a certain function with assert_spin_locked() that you
> > > could covert these to lockdep_assert_held() so the check is only done when
> > > lockdep is enabled for debugging.
> > 
> > not sure about the nouveau parts, but for the omap and msm hunks, this
> > code getting called at potentially vblank rate (so maybe once or twice
> > per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> > so I don't always have it enabled.  So it sounds like for those two at
> > least assert_spin_locked() is a better option.
> > 
> 
> Unless there's a bug, assert_spin_locked() is just going to incur an 
> unnecessary cost every time it is called at runtime.  My suggestion was to 
> limit that check only to debugging kernels that include enabling lockdep 
> when tracking down problems rather than needlessly evaluating the 
> conditional every time when there are no bugs.

My experience with gpu drivers (i915) has been that hw and the software
running it is varied enough that almost always it's better to
unconditionally enable this stuff. I much prefer assert_spin_locked and
friends over the lockdep versions since enabling full lockdep is not
something you usually do. Especially not normal users, and we rely upon
them for testing the old stuff. Furthermore for the modeset code the
overhead is totally irrelevant since we're doing metric piles of register
reads and writes in there anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Daniel Vetter]

On Mon, Aug 11, 2014 at 04:38:50PM -0700, David Rientjes wrote:
> On Mon, 11 Aug 2014, Rob Clark wrote:
> 
> > > I'm suggesting that if you don't want to incur the cost of the conditional
> > > everytime you call a certain function with assert_spin_locked() that you
> > > could covert these to lockdep_assert_held() so the check is only done when
> > > lockdep is enabled for debugging.
> > 
> > not sure about the nouveau parts, but for the omap and msm hunks, this
> > code getting called at potentially vblank rate (so maybe once or twice
> > per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> > so I don't always have it enabled.  So it sounds like for those two at
> > least assert_spin_locked() is a better option.
> > 
> 
> Unless there's a bug, assert_spin_locked() is just going to incur an 
> unnecessary cost every time it is called at runtime.  My suggestion was to 
> limit that check only to debugging kernels that include enabling lockdep 
> when tracking down problems rather than needlessly evaluating the 
> conditional every time when there are no bugs.

My experience with gpu drivers (i915) has been that hw and the software
running it is varied enough that almost always it's better to
unconditionally enable this stuff. I much prefer assert_spin_locked and
friends over the lockdep versions since enabling full lockdep is not
something you usually do. Especially not normal users, and we rely upon
them for testing the old stuff. Furthermore for the modeset code the
overhead is totally irrelevant since we're doing metric piles of register
reads and writes in there anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

[-- Attachment #1.1: Type: text/plain, Size: 2051 bytes --]

yes you are absolutely correct and the change I have done in other area i.e
drivers/usb/storage/uas.c.In gpu drivers assert_spin_locked() make
more sense.

Regards
Sanjeev Sharma


On Tue, Aug 12, 2014 at 12:25 PM, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Mon, Aug 11, 2014 at 04:38:50PM -0700, David Rientjes wrote:
> > On Mon, 11 Aug 2014, Rob Clark wrote:
> >
> > > > I'm suggesting that if you don't want to incur the cost of the
> conditional
> > > > everytime you call a certain function with assert_spin_locked() that
> you
> > > > could covert these to lockdep_assert_held() so the check is only
> done when
> > > > lockdep is enabled for debugging.
> > >
> > > not sure about the nouveau parts, but for the omap and msm hunks, this
> > > code getting called at potentially vblank rate (so maybe once or twice
> > > per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> > > so I don't always have it enabled.  So it sounds like for those two at
> > > least assert_spin_locked() is a better option.
> > >
> >
> > Unless there's a bug, assert_spin_locked() is just going to incur an
> > unnecessary cost every time it is called at runtime.  My suggestion was
> to
> > limit that check only to debugging kernels that include enabling lockdep
> > when tracking down problems rather than needlessly evaluating the
> > conditional every time when there are no bugs.
>
> My experience with gpu drivers (i915) has been that hw and the software
> running it is varied enough that almost always it's better to
> unconditionally enable this stuff. I much prefer assert_spin_locked and
> friends over the lockdep versions since enabling full lockdep is not
> something you usually do. Especially not normal users, and we rely upon
> them for testing the old stuff. Furthermore for the modeset code the
> overhead is totally irrelevant since we're doing metric piles of register
> reads and writes in there anyway.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>

[-- Attachment #1.2: Type: text/html, Size: 2951 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Dave Airlie]

>ssert_spin_locked() is a better option.
>> > >
>> >
>> > Unless there's a bug, assert_spin_locked() is just going to incur an
>> > unnecessary cost every time it is called at runtime.  My suggestion was
>> > to
>> > limit that check only to debugging kernels that include enabling lockdep
>> > when tracking down problems rather than needlessly evaluating the
>> > conditional every time when there are no bugs.
>>
>> My experience with gpu drivers (i915) has been that hw and the software
>> running it is varied enough that almost always it's better to
>> unconditionally enable this stuff. I much prefer assert_spin_locked and
>> friends over the lockdep versions since enabling full lockdep is not
>> something you usually do. Especially not normal users, and we rely upon
>> them for testing the old stuff. Furthermore for the modeset code the
>> overhead is totally irrelevant since we're doing metric piles of register
>> reads and writes in there anyway.


Did anything translate into an R-b here?

Dave.

Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Dave Airlie]

>ssert_spin_locked() is a better option.
>> > >
>> >
>> > Unless there's a bug, assert_spin_locked() is just going to incur an
>> > unnecessary cost every time it is called at runtime.  My suggestion was
>> > to
>> > limit that check only to debugging kernels that include enabling lockdep
>> > when tracking down problems rather than needlessly evaluating the
>> > conditional every time when there are no bugs.
>>
>> My experience with gpu drivers (i915) has been that hw and the software
>> running it is varied enough that almost always it's better to
>> unconditionally enable this stuff. I much prefer assert_spin_locked and
>> friends over the lockdep versions since enabling full lockdep is not
>> something you usually do. Especially not normal users, and we rely upon
>> them for testing the old stuff. Furthermore for the modeset code the
>> overhead is totally irrelevant since we're doing metric piles of register
>> reads and writes in there anyway.


Did anything translate into an R-b here?

Dave.