[PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()

[PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()

[Johannes Berg]

From: Wei Yongjun <weiyongjun1@huawei.com>

spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
is used for unlocking. Fix it by using spin_unlock_bh() instead
of rcu_read_unlock() in the error handling case.

Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Dave, can you take this directly? I see little value in sending a
pull request for this one patch (but if you prefer can do so.)
---
 net/mac80211/mesh_pathtbl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index c3a7396fb955..88a6d5e18ccc 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -627,7 +627,7 @@ static int table_path_del(struct mesh_table *tbl,
 	spin_lock_bh(&tbl->walk_lock);
 	mpath = rhashtable_lookup_fast(&tbl->rhead, addr, mesh_rht_params);
 	if (!mpath) {
-		rcu_read_unlock();
+		spin_unlock_bh(&tbl->walk_lock);
 		return -ENXIO;
 	}
 
-- 
2.17.2

Re: [PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()

[David Miller]

From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 18 Feb 2019 11:29:29 +0100

> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
> is used for unlocking. Fix it by using spin_unlock_bh() instead
> of rcu_read_unlock() in the error handling case.
> 
> Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> Dave, can you take this directly? I see little value in sending a
> pull request for this one patch (but if you prefer can do so.)

Applied, thanks Johannes.