Skip to contentSkip to conversation

ipv6: addrconf: Fix recursive spin lock call

PATCH In review [email protected] 4 participants 4 messages Feb 2, 2016 – Feb 6, 2016

Subsystems (3)
Networking Network drivers IPv4/IPv6
lore
Share & tools
lore

[email protected]

author
#0 lore raw

PATCH v2 1/1 ipv6: addrconf: Fix recursive spin lock call

A rcu stall with the following backtrace was seen on a system with forwarding, optimistic_dad and use_optimistic set. To reproduce, set these flags and allow ipv6 autoconf.

This occurs because the device write_lock is acquired while already holding the read_lock. Back trace below -

INFO: rcu_preempt self-detected stall on CPU { 1}  (t=2100 jiffies
 g=3992 c=3991 q=4471)

<6> Task dump for CPU 1:
<2> kworker/1:0 R running task 12168 15 2 0x00000002
<2> Workqueue: ipv6_addrconf addrconf_dad_work <6> Call trace:
<2> [<ffffffc000084da8>] el1_irq+0x68/0xdc
<2> [<ffffffc000cc4e0c>] _raw_write_lock_bh+0x20/0x30 <2> [<ffffffc000bc5dd8>] __ipv6_dev_ac_inc+0x64/0x1b4 <2> [<ffffffc000bcbd2c>] addrconf_join_anycast+0x9c/0xc4 <2> [<ffffffc000bcf9f0>] __ipv6_ifa_notify+0x160/0x29c <2> [<ffffffc000bcfb7c>] ipv6_ifa_notify+0x50/0x70 <2> [<ffffffc000bd035c>] addrconf_dad_work+0x314/0x334 <2> [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc <2> [<ffffffc0000b7324>] worker_thread+0x2f8/0x418 <2> [<ffffffc0000bb40c>] kthread+0xe0/0xec

v2: do addrconf_dad_kick inside read lock and then acquire write lock for ipv6_ifa_notify as suggested by Eric

Fixes 7fd2561e4ebdd ("net: ipv6: Add a sysctl to make optimistic

addresses useful candidates")

Cc Eric Dumazet <[email protected]>
Cc Erik Kline <[email protected]>
Cc Hannes Frederic Sowa <[email protected]>
Signed-off-by Subash Abhinov Kasiviswanathan <[email protected]>
---
 net/ipv6/addrconf.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
net/ipv6/addrconf.c +4 -1
index 38eedde..9efd9ff 100644
@@ -3538,6 +3538,7 @@ static void addrconf_dad_begin(struct inet6_ifaddr *ifp)
 {
 	struct inet6_dev *idev = ifp->idev;
 	struct net_device *dev = idev->dev;
+	bool notify = false;
 
 	addrconf_join_solict(dev, &ifp->addr);
 

@@ -3583,7 +3584,7 @@ static void addrconf_dad_begin(struct inet6_ifaddr *ifp)
 			/* Because optimistic nodes can use this address,
 			 * notify listeners. If DAD fails, RTM_DELADDR is sent.
 			 */
-			ipv6_ifa_notify(RTM_NEWADDR, ifp);
+			notify = true;
 		}
 	}
 

@@ -3591,6 +3592,8 @@ static void addrconf_dad_begin(struct inet6_ifaddr *ifp)
 out:
 	spin_unlock(&ifp->lock);
 	read_unlock_bh(&idev->lock);
+	if (notify)
+		ipv6_ifa_notify(RTM_NEWADDR, ifp);
 }
 
 static void addrconf_dad_start(struct inet6_ifaddr *ifp)
Acked-by on v2 1/1
#1 lore raw
Quoted 27 lines · On 02.02.2016 03:11, [email protected] wrote:

A rcu stall with the following backtrace was seen on a system with forwarding, optimistic_dad and use_optimistic set. To reproduce, set these flags and allow ipv6 autoconf.

This occurs because the device write_lock is acquired while already holding the read_lock. Back trace below -

INFO: rcu_preempt self-detected stall on CPU { 1}  (t=2100 jiffies
  g=3992 c=3991 q=4471)

<6> Task dump for CPU 1:
<2> kworker/1:0 R running task 12168 15 2 0x00000002
<2> Workqueue: ipv6_addrconf addrconf_dad_work <6> Call trace:
<2> [<ffffffc000084da8>] el1_irq+0x68/0xdc
<2> [<ffffffc000cc4e0c>] _raw_write_lock_bh+0x20/0x30 <2> [<ffffffc000bc5dd8>] __ipv6_dev_ac_inc+0x64/0x1b4 <2> [<ffffffc000bcbd2c>] addrconf_join_anycast+0x9c/0xc4 <2> [<ffffffc000bcf9f0>] __ipv6_ifa_notify+0x160/0x29c <2> [<ffffffc000bcfb7c>] ipv6_ifa_notify+0x50/0x70 <2> [<ffffffc000bd035c>] addrconf_dad_work+0x314/0x334 <2> [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc <2> [<ffffffc0000b7324>] worker_thread+0x2f8/0x418 <2> [<ffffffc0000bb40c>] kthread+0xe0/0xec

v2: do addrconf_dad_kick inside read lock and then acquire write lock for ipv6_ifa_notify as suggested by Eric

Quoted 7 lines
Fixes 7fd2561e4ebdd ("net: ipv6: Add a sysctl to make optimistic

addresses useful candidates")

Cc Eric Dumazet <[email protected]>
Cc Erik Kline <[email protected]>
Cc Hannes Frederic Sowa <[email protected]>
Signed-off-by Subash Abhinov Kasiviswanathan <[email protected]>
Acked-by Hannes Frederic Sowa <[email protected]>

Definitely a stable candidate, thanks!

maintainer
#3 lore raw
In reply to [email protected]

From: [email protected]
Date: Tue, 2 Feb 2016 02:11:10 -0000

Quoted 6 lines

A rcu stall with the following backtrace was seen on a system with forwarding, optimistic_dad and use_optimistic set. To reproduce, set these flags and allow ipv6 autoconf.

This occurs because the device write_lock is acquired while already holding the read_lock. Back trace below -

...

Quoted 10 lines

v2: do addrconf_dad_kick inside read lock and then acquire write lock for ipv6_ifa_notify as suggested by Eric

Fixes 7fd2561e4ebdd ("net: ipv6: Add a sysctl to make optimistic

addresses useful candidates")

Cc Eric Dumazet <[email protected]>
Cc Erik Kline <[email protected]>
Cc Hannes Frederic Sowa <[email protected]>
Signed-off-by Subash Abhinov Kasiviswanathan <[email protected]>

Applied and queued up for -stable, thanks.