On Wed, 18 May 2011 18:40:33 -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?
It looks like it's the only solution :-)
Anyway they should've been atomic even before already, not sure why RCU
didn't complain but it was definitely not right to do GFP_KERNEL
allocations under RCU lock, but now that I think about it ISTR that
whether it warns or not might depend on the RCU implementation you
selected in the config.
johannes
--
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
