* [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
@ 2019-02-17 18:11 Andrew Lunn
2019-02-17 19:55 ` Russell King - ARM Linux admin
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2019-02-17 18:11 UTC (permalink / raw)
To: Russell King; +Cc: netdev, Vivien Didelot, Andrew Lunn
The following false positive lockdep splat has been observed.
======================================================
WARNING: possible circular locking dependency detected
4.20.0+ #302 Not tainted
------------------------------------------------------
systemd-udevd/160 is trying to acquire lock:
edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
but task is already holding lock:
edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&desc->request_mutex){+.+.}:
mutex_lock_nested+0x1c/0x24
__setup_irq+0xa0/0x704
request_threaded_irq+0xd0/0x150
mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
mdio_probe+0x2c/0x54
really_probe+0x200/0x2c4
driver_probe_device+0x5c/0x174
__driver_attach+0xd8/0xdc
bus_for_each_dev+0x58/0x7c
bus_add_driver+0xe4/0x1f0
driver_register+0x7c/0x110
mdio_driver_register+0x24/0x58
do_one_initcall+0x74/0x2e8
do_init_module+0x60/0x1d0
load_module+0x1968/0x1ff4
sys_finit_module+0x8c/0x98
ret_fast_syscall+0x0/0x28
0xbedf2ae8
-> #0 (&chip->reg_lock){+.+.}:
__mutex_lock+0x50/0x8b8
mutex_lock_nested+0x1c/0x24
__setup_irq+0x640/0x704
request_threaded_irq+0xd0/0x150
mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
mdio_probe+0x2c/0x54
really_probe+0x200/0x2c4
driver_probe_device+0x5c/0x174
__driver_attach+0xd8/0xdc
bus_for_each_dev+0x58/0x7c
bus_add_driver+0xe4/0x1f0
driver_register+0x7c/0x110
mdio_driver_register+0x24/0x58
do_one_initcall+0x74/0x2e8
do_init_module+0x60/0x1d0
load_module+0x1968/0x1ff4
sys_finit_module+0x8c/0x98
ret_fast_syscall+0x0/0x28
0xbedf2ae8
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&desc->request_mutex);
lock(&chip->reg_lock);
lock(&desc->request_mutex);
lock(&chip->reg_lock);
&desc->request_mutex refer to two different mutex. #1 is the GPIO for
the chip interrupt. #2 is the chained interrupt between global 1 and
global 2.
Add lockdep classes to the GPIO interrupt to avoid this.
Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Hi Russell
Does this fix it for you on Clearfog?
drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 32e7af5caa69..936d53a92144 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -442,12 +442,20 @@ static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
{
+ static struct lock_class_key lock_key;
+ static struct lock_class_key request_key;
int err;
err = mv88e6xxx_g1_irq_setup_common(chip);
if (err)
return err;
+ /* These lock classes tells lockdep that global 1 irqs are in
+ * a different category than their parent GPIO, so it won't
+ * report false recursion.
+ */
+ irq_set_lockdep_class(chip->irq, &lock_key, &request_key);
+
err = request_threaded_irq(chip->irq, NULL,
mv88e6xxx_g1_irq_thread_fn,
IRQF_ONESHOT | IRQF_SHARED,
--
2.20.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
2019-02-17 18:11 [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat Andrew Lunn
@ 2019-02-17 19:55 ` Russell King - ARM Linux admin
2019-02-22 17:48 ` Russell King - ARM Linux admin
0 siblings, 1 reply; 5+ messages in thread
From: Russell King - ARM Linux admin @ 2019-02-17 19:55 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Vivien Didelot
On Sun, Feb 17, 2019 at 07:11:43PM +0100, Andrew Lunn wrote:
> The following false positive lockdep splat has been observed.
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.20.0+ #302 Not tainted
> ------------------------------------------------------
> systemd-udevd/160 is trying to acquire lock:
> edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
>
> but task is already holding lock:
> edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&desc->request_mutex){+.+.}:
> mutex_lock_nested+0x1c/0x24
> __setup_irq+0xa0/0x704
> request_threaded_irq+0xd0/0x150
> mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
> mdio_probe+0x2c/0x54
> really_probe+0x200/0x2c4
> driver_probe_device+0x5c/0x174
> __driver_attach+0xd8/0xdc
> bus_for_each_dev+0x58/0x7c
> bus_add_driver+0xe4/0x1f0
> driver_register+0x7c/0x110
> mdio_driver_register+0x24/0x58
> do_one_initcall+0x74/0x2e8
> do_init_module+0x60/0x1d0
> load_module+0x1968/0x1ff4
> sys_finit_module+0x8c/0x98
> ret_fast_syscall+0x0/0x28
> 0xbedf2ae8
>
> -> #0 (&chip->reg_lock){+.+.}:
> __mutex_lock+0x50/0x8b8
> mutex_lock_nested+0x1c/0x24
> __setup_irq+0x640/0x704
> request_threaded_irq+0xd0/0x150
> mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
> mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
> mdio_probe+0x2c/0x54
> really_probe+0x200/0x2c4
> driver_probe_device+0x5c/0x174
> __driver_attach+0xd8/0xdc
> bus_for_each_dev+0x58/0x7c
> bus_add_driver+0xe4/0x1f0
> driver_register+0x7c/0x110
> mdio_driver_register+0x24/0x58
> do_one_initcall+0x74/0x2e8
> do_init_module+0x60/0x1d0
> load_module+0x1968/0x1ff4
> sys_finit_module+0x8c/0x98
> ret_fast_syscall+0x0/0x28
> 0xbedf2ae8
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&desc->request_mutex);
> lock(&chip->reg_lock);
> lock(&desc->request_mutex);
> lock(&chip->reg_lock);
>
> &desc->request_mutex refer to two different mutex. #1 is the GPIO for
> the chip interrupt. #2 is the chained interrupt between global 1 and
> global 2.
>
> Add lockdep classes to the GPIO interrupt to avoid this.
>
> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>
> Hi Russell
>
> Does this fix it for you on Clearfog?
Yes, that also fixes the problem, but I do think this is just papering
over mv88e6xxx needlessly holding locks when it doesn't need to do so.
>
> drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 32e7af5caa69..936d53a92144 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -442,12 +442,20 @@ static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
>
> static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
> {
> + static struct lock_class_key lock_key;
> + static struct lock_class_key request_key;
> int err;
>
> err = mv88e6xxx_g1_irq_setup_common(chip);
> if (err)
> return err;
>
> + /* These lock classes tells lockdep that global 1 irqs are in
> + * a different category than their parent GPIO, so it won't
> + * report false recursion.
> + */
> + irq_set_lockdep_class(chip->irq, &lock_key, &request_key);
> +
> err = request_threaded_irq(chip->irq, NULL,
> mv88e6xxx_g1_irq_thread_fn,
> IRQF_ONESHOT | IRQF_SHARED,
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
2019-02-17 19:55 ` Russell King - ARM Linux admin
@ 2019-02-22 17:48 ` Russell King - ARM Linux admin
2019-02-22 17:59 ` Andrew Lunn
0 siblings, 1 reply; 5+ messages in thread
From: Russell King - ARM Linux admin @ 2019-02-22 17:48 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Vivien Didelot
On Sun, Feb 17, 2019 at 07:55:24PM +0000, Russell King - ARM Linux admin wrote:
> On Sun, Feb 17, 2019 at 07:11:43PM +0100, Andrew Lunn wrote:
> > The following false positive lockdep splat has been observed.
> >
> > ======================================================
> > WARNING: possible circular locking dependency detected
> > 4.20.0+ #302 Not tainted
> > ------------------------------------------------------
> > systemd-udevd/160 is trying to acquire lock:
> > edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
> >
> > but task is already holding lock:
> > edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
> >
> > which lock already depends on the new lock.
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #1 (&desc->request_mutex){+.+.}:
> > mutex_lock_nested+0x1c/0x24
> > __setup_irq+0xa0/0x704
> > request_threaded_irq+0xd0/0x150
> > mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
> > mdio_probe+0x2c/0x54
> > really_probe+0x200/0x2c4
> > driver_probe_device+0x5c/0x174
> > __driver_attach+0xd8/0xdc
> > bus_for_each_dev+0x58/0x7c
> > bus_add_driver+0xe4/0x1f0
> > driver_register+0x7c/0x110
> > mdio_driver_register+0x24/0x58
> > do_one_initcall+0x74/0x2e8
> > do_init_module+0x60/0x1d0
> > load_module+0x1968/0x1ff4
> > sys_finit_module+0x8c/0x98
> > ret_fast_syscall+0x0/0x28
> > 0xbedf2ae8
> >
> > -> #0 (&chip->reg_lock){+.+.}:
> > __mutex_lock+0x50/0x8b8
> > mutex_lock_nested+0x1c/0x24
> > __setup_irq+0x640/0x704
> > request_threaded_irq+0xd0/0x150
> > mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
> > mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
> > mdio_probe+0x2c/0x54
> > really_probe+0x200/0x2c4
> > driver_probe_device+0x5c/0x174
> > __driver_attach+0xd8/0xdc
> > bus_for_each_dev+0x58/0x7c
> > bus_add_driver+0xe4/0x1f0
> > driver_register+0x7c/0x110
> > mdio_driver_register+0x24/0x58
> > do_one_initcall+0x74/0x2e8
> > do_init_module+0x60/0x1d0
> > load_module+0x1968/0x1ff4
> > sys_finit_module+0x8c/0x98
> > ret_fast_syscall+0x0/0x28
> > 0xbedf2ae8
> >
> > other info that might help us debug this:
> >
> > Possible unsafe locking scenario:
> >
> > CPU0 CPU1
> > ---- ----
> > lock(&desc->request_mutex);
> > lock(&chip->reg_lock);
> > lock(&desc->request_mutex);
> > lock(&chip->reg_lock);
> >
> > &desc->request_mutex refer to two different mutex. #1 is the GPIO for
> > the chip interrupt. #2 is the chained interrupt between global 1 and
> > global 2.
> >
> > Add lockdep classes to the GPIO interrupt to avoid this.
> >
> > Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> >
> > Hi Russell
> >
> > Does this fix it for you on Clearfog?
>
> Yes, that also fixes the problem, but I do think this is just papering
> over mv88e6xxx needlessly holding locks when it doesn't need to do so.
Hi Andrew,
Do we have a way forward for this issue?
Thanks.
>
> >
> > drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> > index 32e7af5caa69..936d53a92144 100644
> > --- a/drivers/net/dsa/mv88e6xxx/chip.c
> > +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> > @@ -442,12 +442,20 @@ static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
> >
> > static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
> > {
> > + static struct lock_class_key lock_key;
> > + static struct lock_class_key request_key;
> > int err;
> >
> > err = mv88e6xxx_g1_irq_setup_common(chip);
> > if (err)
> > return err;
> >
> > + /* These lock classes tells lockdep that global 1 irqs are in
> > + * a different category than their parent GPIO, so it won't
> > + * report false recursion.
> > + */
> > + irq_set_lockdep_class(chip->irq, &lock_key, &request_key);
> > +
> > err = request_threaded_irq(chip->irq, NULL,
> > mv88e6xxx_g1_irq_thread_fn,
> > IRQF_ONESHOT | IRQF_SHARED,
> > --
> > 2.20.1
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
2019-02-22 17:48 ` Russell King - ARM Linux admin
@ 2019-02-22 17:59 ` Andrew Lunn
2019-02-22 21:02 ` David Miller
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2019-02-22 17:59 UTC (permalink / raw)
To: Russell King - ARM Linux admin; +Cc: netdev, Vivien Didelot
> Hi Andrew,
>
> Do we have a way forward for this issue?
Hi Russell
Yes. I tested releasing the mutex around the request for the
interrupt. That works. So i will submit a patchset adding both the
lockdep class, and the unlock/lock pair.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
2019-02-22 17:59 ` Andrew Lunn
@ 2019-02-22 21:02 ` David Miller
0 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2019-02-22 21:02 UTC (permalink / raw)
To: andrew; +Cc: linux, netdev, vivien.didelot
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 22 Feb 2019 18:59:16 +0100
>> Hi Andrew,
>>
>> Do we have a way forward for this issue?
>
> Hi Russell
>
> Yes. I tested releasing the mutex around the request for the
> interrupt. That works. So i will submit a patchset adding both the
> lockdep class, and the unlock/lock pair.
So I'll drop this patch from patchwork.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-02-22 21:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-17 18:11 [PATCH] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat Andrew Lunn
2019-02-17 19:55 ` Russell King - ARM Linux admin
2019-02-22 17:48 ` Russell King - ARM Linux admin
2019-02-22 17:59 ` Andrew Lunn
2019-02-22 21:02 ` David Miller
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.