Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+arp_queue\:\s+serializing\s+unlink\s+\+\s+kfree

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+arp_queue\:\s+serializing\s+unlink\s+\+\s+kfree_skb\s*$/: 54 ]

Total 54 documents matching your query.

1. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Wed, 2 Feb 2005 16:20:23 -0800; 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; /archives/netdev/2005-02/msg00070.html (11,094 bytes)
2. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 22:12:24 +1100; 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; /archives/netdev/2005-02/msg00077.html (11,426 bytes)
3. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Anton Blanchard <anton@xxxxxxxxx>; Date: Fri, 4 Feb 2005 01:27:05 +1100; 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; /archives/netdev/2005-02/msg00081.html (10,368 bytes)
4. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 10:14:20 -0800; 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; /archives/netdev/2005-02/msg00085.html (10,357 bytes)
5. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 4 Feb 2005 07:30:10 +1100; 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; /archives/netdev/2005-02/msg00097.html (10,463 bytes)
6. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 14:19:01 -0800; 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; /archives/netdev/2005-02/msg00103.html (12,076 bytes)
7. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 15:08:21 -0800; 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; /archives/netdev/2005-02/msg00106.html (21,915 bytes)
8. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 4 Feb 2005 10:50:44 +1100; 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; /archives/netdev/2005-02/msg00108.html (11,603 bytes)
9. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 16:34:58 -0800; 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; /archives/netdev/2005-02/msg00110.html (12,702 bytes)
10. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 16:49:22 -0800; 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; /archives/netdev/2005-02/msg00112.html (11,851 bytes)
11. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 4 Feb 2005 12:20:53 +1100; 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; /archives/netdev/2005-02/msg00115.html (12,584 bytes)
12. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 3 Feb 2005 17:23:57 -0800; 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; /archives/netdev/2005-02/msg00116.html (12,148 bytes)
13. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 4 Feb 2005 12:55:39 +1100; 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; /archives/netdev/2005-02/msg00117.html (12,631 bytes)
14. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Olaf Kirch <okir@xxxxxxx>; Date: Fri, 4 Feb 2005 12:16:49 +0100; 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.; /archives/netdev/2005-02/msg00123.html (11,857 bytes)
15. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Fri, 4 Feb 2005 22:33:05 +1100; 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; /archives/netdev/2005-02/msg00124.html (14,261 bytes)
16. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: xxxxxx>; Date: Fri, 4 Feb 2005 15:48:55 -0800; 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; /archives/netdev/2005-02/msg00147.html (12,332 bytes)
17. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: xxxxxx>; Date: Fri, 4 Feb 2005 22:24:28 -0800; 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; /archives/netdev/2005-02/msg00158.html (23,692 bytes)
18. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: xxxxxx>; Date: Sat, 5 Feb 2005 17:50:49 +1100; 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; /archives/netdev/2005-02/msg00161.html (11,068 bytes)
19. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: s Romieu <romieu@xxxxxxxxxxxxx>; Date: Sat, 5 Feb 2005 17:14:39 -0800; I've queued this up for 2.6.x and 2.4.x, thanks everyone.; /archives/netdev/2005-02/msg00174.html (11,719 bytes)
20. Re: [PATCH] arp_queue: serializing unlink + kfree_skb (score: 1): Author: xxxxxxxxxxx>; Date: Thu, 10 Feb 2005 01:23:04 -0300; 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,; /archives/netdev/2005-02/msg00319.html (12,819 bytes)

Current List: 1 - 20
Page: [1] [2] [3]