1 From 8c71f4771d4741642ee2aab0681d0d277823f0d4 Mon Sep 17 00:00:00 2001
2 From: Andrew Lunn <andrew@lunn.ch>
3 Date: Sat, 23 Feb 2019 17:43:56 +0100
4 Subject: net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat
6 [ Upstream commit f6d9758b12660484b6639364cc406da92a918c96 ]
8 The following false positive lockdep splat has been observed.
10 ======================================================
11 WARNING: possible circular locking dependency detected
12 4.20.0+ #302 Not tainted
13 ------------------------------------------------------
14 systemd-udevd/160 is trying to acquire lock:
15 edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
17 but task is already holding lock:
18 edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
20 which lock already depends on the new lock.
22 the existing dependency chain (in reverse order) is:
24 -> #1 (&desc->request_mutex){+.+.}:
25 mutex_lock_nested+0x1c/0x24
26 __setup_irq+0xa0/0x704
27 request_threaded_irq+0xd0/0x150
28 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
30 really_probe+0x200/0x2c4
31 driver_probe_device+0x5c/0x174
32 __driver_attach+0xd8/0xdc
33 bus_for_each_dev+0x58/0x7c
34 bus_add_driver+0xe4/0x1f0
35 driver_register+0x7c/0x110
36 mdio_driver_register+0x24/0x58
37 do_one_initcall+0x74/0x2e8
38 do_init_module+0x60/0x1d0
39 load_module+0x1968/0x1ff4
40 sys_finit_module+0x8c/0x98
41 ret_fast_syscall+0x0/0x28
44 -> #0 (&chip->reg_lock){+.+.}:
45 __mutex_lock+0x50/0x8b8
46 mutex_lock_nested+0x1c/0x24
47 __setup_irq+0x640/0x704
48 request_threaded_irq+0xd0/0x150
49 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
50 mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
52 really_probe+0x200/0x2c4
53 driver_probe_device+0x5c/0x174
54 __driver_attach+0xd8/0xdc
55 bus_for_each_dev+0x58/0x7c
56 bus_add_driver+0xe4/0x1f0
57 driver_register+0x7c/0x110
58 mdio_driver_register+0x24/0x58
59 do_one_initcall+0x74/0x2e8
60 do_init_module+0x60/0x1d0
61 load_module+0x1968/0x1ff4
62 sys_finit_module+0x8c/0x98
63 ret_fast_syscall+0x0/0x28
66 other info that might help us debug this:
68 Possible unsafe locking scenario:
72 lock(&desc->request_mutex);
73 lock(&chip->reg_lock);
74 lock(&desc->request_mutex);
75 lock(&chip->reg_lock);
77 &desc->request_mutex refer to two different mutex. #1 is the GPIO for
78 the chip interrupt. #2 is the chained interrupt between global 1 and
81 Add lockdep classes to the GPIO interrupt to avoid this.
83 Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
84 Signed-off-by: Andrew Lunn <andrew@lunn.ch>
85 Signed-off-by: David S. Miller <davem@davemloft.net>
87 Signed-off-by: Sasha Levin <sashal@kernel.org>
89 drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++
90 1 file changed, 8 insertions(+)
92 diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
93 index c078c791f481..dabe89968a78 100644
94 --- a/drivers/net/dsa/mv88e6xxx/chip.c
95 +++ b/drivers/net/dsa/mv88e6xxx/chip.c
96 @@ -442,12 +442,20 @@ out_mapping:
98 static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
100 + static struct lock_class_key lock_key;
101 + static struct lock_class_key request_key;
104 err = mv88e6xxx_g1_irq_setup_common(chip);
108 + /* These lock classes tells lockdep that global 1 irqs are in
109 + * a different category than their parent GPIO, so it won't
110 + * report false recursion.
112 + irq_set_lockdep_class(chip->irq, &lock_key, &request_key);
114 err = request_threaded_irq(chip->irq, NULL,
115 mv88e6xxx_g1_irq_thread_fn,