On Mon, 2011-06-20 at 09:49 -0700, Yogesh Powar wrote: > >No, they're not, the mutex trickery seems completely pointless, and the > >conditional (on _is_locked no less) locking is horrible. > Ok. > > Will spend some more time on exploring solutions using rcu primitives only > (synchronize_net or something similar). > > If nothing of only-RCU is feasible then, I think, we need to resize the skb if it has > already skipped the tailroom instead of WARN_ON. This will come in to picuture > only during the race cases. But this wont get rid of race. Ahrg, seriously, just analyse the situation for once. Do I really need to do that? There are two race cases, during transitions: 1) need to resize -> no need to (key moved to HW) 2) no need to resize -> need to (new key, ...) The first is uninteresting, it's fine if the race happens and the skb is still resized even if it didn't need to. The second one is what's causing issues. But the race happens like this: - counter is 0 - skb goes through tx start, no tailroom allocated - key added, counter > 0 - key lookup while TX processing is successful So ... how can you solve it? Clearly, the locking attempts you made were pretty useless. But now that we understand the race, can we fix it? I think we can, by doing something like this: counter++; /* flush packets being processed */ synchronize_net(); /* do whatever causes the key to be found by sw crypto */ That should be it. The only overhead is a little bit in control paths for key settings which are delayed a bit by synchronize_net(), but who cares, we don't change keys every packet. Of course you need to encapsulate that code into a small function and write comments about why it's necessary and how it works. Was that so hard? :-) 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
