On Tue, 2015-04-21 at 09:54 +0300, Eliad Peller wrote: > > Hey, somebody is reviewing my patches :-) > > > i didn't delve into them too much, but generally they look good :) :) > > To fix that, I think I can hold the lock longer, so that the lifetime of > > the key and the fast_tx pointer are more closely correlated. If I > > acquire the spinlock before checking for the key, then the CPU that > > invalidates the key pointer cannot race in this way with another caller, > > since the key pointer would (for this purpose) be protected by the lock. > > Then either the CPU that deleted the key will have to wait (while the > > key is still pretty much valid) and then will overwrite the fast_tx w/o > > the key, or the other CPU will have to wait and will find the key > > pointer changed/NULL already. > > > > Right? what do you think? > > sounds correct. > i guess taking rcu_lock is a valid option as well (for about the same > reasons). so either one of them should be good. I don't think that would be correct - that just prevents the key from being freed while we hold it, whereas here we actually need to prevent the key from being accessed. Anyway - I've done a bit more testing on this and will likely merge it (the fixed version of course) in the next couple of days. 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
