On Mon, Mar 21, 2016 at 12:22:46PM -0400, fred veldini via Devel wrote:
> Hello Group,
Thanks for the report!
> This crash only occurs on the 4.5 release and newer.
> This is what loops forever on the console screen.
> [ 48.018132] [<f96b7221>] mesh_path_tbl_expire.isra.24+0x19/0x82
> [mac80211]
> [ 48.018132] [<f96b808b>] mesh_path_expire+0x11/0x1f [mac80211]
> [ 48.018132] [<f96b6bb7>] ieee80211_mesh_work+0x73/0x1a9 [mac80211]
> [ 48.018132] [<f96947d1>] ieee80211_iface_work+0x2ff/0x311 [mac80211]
> [ 48.018132] [<c0235fa3>] process_one_work+0x14b/0x24e
> [ 48.018132] [<c0236313>] worker_thread+0x249/0x343
> [ 48.018132] [<c02360ca>] ? process_scheduled_works+0x24/0x24
> [ 48.018132] [<c0239359>] kthread+0x9e/0xa3
> [ 48.018132] [<c0578e50>] ret_from_kernel_thread+0x20/0x40
> [ 48.018132] [<c02392bb>] ? kthread_parkme+0x18/0x18
mesh_path_tbl expired is called from mesh housekeeping. I'm not seeing
immediately where there might be a bad pointer unless there is a race with
initialization and sdata->u.mesh.mesh_paths is still null.
But this does look wrong: sdata lock should be held here but we do a
GFP_KERNEL allocation.
How about with the following patch?
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 7455397..450e062 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -875,7 +875,7 @@ void mesh_path_tbl_expire(struct ieee80211_sub_if_data
*sdata,
struct rhashtable_iter iter;
int ret;
- ret = rhashtable_walk_init(&tbl->rhead, &iter, GFP_KERNEL);
+ ret = rhashtable_walk_init(&tbl->rhead, &iter, GFP_ATOMIC);
if (ret)
return;
--
Bob Copeland %% http://bobcopeland.com/
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/mailman/listinfo/devel
