On Wed, May 18, 2011 at 3:45 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2011-05-17 at 16:05 -0700, Javier Cardona wrote: > >> I'm seeing this after trying your patch, probably because the >> allocations mesh_table_alloc() can block. In the past I had tried to >> allocate the table before entering the critical section. If that is >> not possible for the race condition you mention, then I guess we'll >> have to make those allocations GFP_ATOMIC? > > Err, now I'm confused, how could the code have done non-atomic > allocations while under rcu_read_lock()? I guess there was just no > verification there? I'm not sure. I can tell you that the bug message is only triggered after your patch was applied, same .config. Maybe i have an rcu configuration that does not check that. Is making the allocations atomic an acceptable solution? Javier -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
