net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat

The following false positive lockdep splat has been observed.

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
> 
>

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

> 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

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.