I agree. This looks good. Olaf can you possibly ask the reproducer if this patch makes the ARP problem go away? Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> diff -Nru a/include/linux/skbuff.h
Not so hasty Dave :) That was only meant to be an example of what we might do to insert a write barrier in kfree_skb(). It doesn't solve Olaf's problem because a write barrier is usually not sufficie
Architectures should guarantee that any of the atomics and bitops that return values order in both directions. So you dont need the smp_mb__before_atomic_dec here. It is, however, required on the at
Sparc64 happens to order the atomic we use in the bitops and atomic_t ops, so sparc64 gets this right by accident. I had no idea about this requirement before reading your email. If IBM is seeing rac
I wasn't aware of this requirement before. However, if this is so, why don't we get rid of the smp_mb__* macros? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <he
They are for cases where you want strict ordering even for the non-return-value-giving atomic_t ops. Actually.... Herbert has a point. By Anton's specification, several uses in 2.6.x I see of these s
Ok, here goes nothing. Can someone run with this? It should be rather complete, and require only minor editorial work. -- atomic_ops.txt -- This document is intended to serve as a guide to Linux port
I see. I got atomic_dec and atomic_dec_and_test mixed up. So the problem isn't as big as I thought which is good. sk_buff is only in trouble because of the atomic_read optimisation which really needs
Ok. I'm commenting now considering Anton's atomic_t rules. Anton, please read down below, I think there is a hole in the PPC memory barriers used for atomic ops on SMP. I don't see what changes are n
See my other email, the atomic_read() should function just fine. If we see the count dropped to "1", whoever set it to "1" made sure that all outstanding memory operations (including things like __sk
This is true if CPU 0 reads the count before reading skb->list. Without a memory barrier, atomic_read and reading skb->list can be reordered. Put it another way, reading skb->list could return a cach
You're absolutely right. Ok, so we do need to change kfree_skb(). I believe even with the memory barrier, the atomic_read() optimization is still worth it. atomic ops on sparc64 take a minimum of 40
OK, here is the patch to do that. Let's get rid of kfree_skb_fast while we're at it since it's no longer used. Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Thanks, -- Visit Openswan at htt
Thanks, I'll give that to the PPC folks and ask the to run with it. Regards, Olaf -- Olaf Kirch | -- o -- Nous sommes du soleil we love when we play okir@xxxxxxx | / | \ sol.dhoop.naytheet.ah kin.ir.
Thanks. It's a very nice piece of work. I think you should probably note that some sort of locking or RCU scheme is required to make this safe. As it is the atomic_inc and the list_add can be reorder
Yeah, this example is totally bogus. I'll make it match the neighbour cache case which started this discussion. Which is something like: static void obj_list_add(struct obj *obj) { obj->active = 1; l
Ok, as promised, here is the updated doc. Who should I author this as? Perhaps "Anton's evil twin" :-) -- atomic_ops.txt -- This document is intended to serve as a guide to Linux port maintainers on
Looks good David. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana
Finally, some light is shed into one of the most arcane areas of the kernel ;-) Thanks ! Hmm, given that this description will not only be read by implementers of atomic functions, but also by users,