aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJarek Poplawski <jarkao2@gmail.com>2008-01-11 00:21:20 -0500
committerDavid S. Miller <davem@davemloft.net>2008-01-11 00:21:20 -0500
commitecd2ebdea350c40e73c00d400d74c8a09c072082 (patch)
tree03ae702dcea6929298882151b1ea0fdd4176f4e9
parent27d1cba21fcc50c37eef5042c6be9fa7135e88fc (diff)
[AX25] af_ax25: Possible circular locking.
Bernard Pidoux F6BVP reported: > When I killall kissattach I can see the following message. > > This happens on kernel 2.6.24-rc5 already patched with the 6 previously > patches I sent recently. > > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.23.9 #1 > ------------------------------------------------------- > kissattach/2906 is trying to acquire lock: > (linkfail_lock){-+..}, at: [<d8bd4603>] ax25_link_failed+0x11/0x39 [ax25] > > but task is already holding lock: > (ax25_list_lock){-+..}, at: [<d8bd7c7c>] ax25_device_event+0x38/0x84 > [ax25] > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: ... lockdep is worried about the different order here: #1 (rose_neigh_list_lock){-+..}: #3 (ax25_list_lock){-+..}: #0 (linkfail_lock){-+..}: #1 (rose_neigh_list_lock){-+..}: #3 (ax25_list_lock){-+..}: #0 (linkfail_lock){-+..}: So, ax25_list_lock could be taken before and after linkfail_lock. I don't know if this three-thread clutch is very probable (or possible at all), but it seems another bug reported by Bernard ("[...] system impossible to reboot with linux-2.6.24-rc5") could have similar source - namely ax25_list_lock held by ax25_kill_by_device() during ax25_disconnect(). It looks like the only place which calls ax25_disconnect() this way, so I guess, it isn't necessary. This patch is breaking the lock for ax25_disconnect(). Reported-and-tested-by: Bernard Pidoux <f6bvp@free.fr> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-rw-r--r--net/ax25/af_ax25.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index ecb14ee00498..b4725ff317c0 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -87,10 +87,22 @@ static void ax25_kill_by_device(struct net_device *dev)
87 return; 87 return;
88 88
89 spin_lock_bh(&ax25_list_lock); 89 spin_lock_bh(&ax25_list_lock);
90again:
90 ax25_for_each(s, node, &ax25_list) { 91 ax25_for_each(s, node, &ax25_list) {
91 if (s->ax25_dev == ax25_dev) { 92 if (s->ax25_dev == ax25_dev) {
92 s->ax25_dev = NULL; 93 s->ax25_dev = NULL;
94 spin_unlock_bh(&ax25_list_lock);
93 ax25_disconnect(s, ENETUNREACH); 95 ax25_disconnect(s, ENETUNREACH);
96 spin_lock_bh(&ax25_list_lock);
97
98 /* The entry could have been deleted from the
99 * list meanwhile and thus the next pointer is
100 * no longer valid. Play it safe and restart
101 * the scan. Forward progress is ensured
102 * because we set s->ax25_dev to NULL and we
103 * are never passed a NULL 'dev' argument.
104 */
105 goto again;
94 } 106 }
95 } 107 }
96 spin_unlock_bh(&ax25_list_lock); 108 spin_unlock_bh(&ax25_list_lock);