- 1. [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: ekka Savola <pekkas@xxxxxxxxxx>
- Date: Fri, 12 Sep 2003 22:50:33 -0700
- In both places af_packet.c calls sk_run_filter() it does a "filter = never actually uses this variable for anything -- it always refers to the filter as sk->sk_filter instead. Clearly this wasn't int
- /archives/netdev/2003-09/msg00407.html (9,563 bytes)
- 2. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
- Date: Sat, 13 Sep 2003 09:35:59 +0200
- Mitchell Blank Jr <mitch@xxxxxxxxxx> : 1 - pointers tests against NULL are naturally supposed "unlikely" by gcc. 2 - I am not completely convinced that the "/* re-check under lock */" comment is real
- /archives/netdev/2003-09/msg00409.html (10,777 bytes)
- 3. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author:
- Date: Sat, 13 Sep 2003 01:02:52 -0700
- I thought that without the comment someone might think that the second "if()" wasn't needed (since we had just checked the same value against NULL a few lines up) -Mitch
- /archives/netdev/2003-09/msg00410.html (8,669 bytes)
- 4. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: hfuji@xxxxxxxxxxxxxx>
- Date: Sat, 13 Sep 2003 11:03:53 +0200
- Mitchell Blank Jr <mitch@xxxxxxxxxx> : Ok, I completely missed the intent. Actually packet_rcv() is run in a BH context and doesn't race with SO_{ATTACH/DETACH}_FILTER from sock_setsockopt() which do
- /archives/netdev/2003-09/msg00412.html (9,317 bytes)
- 5. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: xxxxxxxxxxx>
- Date: Sat, 13 Sep 2003 13:15:59 -0700
- I don't understand what you're saying - are you saying that the locking isn't needed? Or just the recheck isn't needed? It sounds like if we're only avoiding the race because of the bh_lock_sock() th
- /archives/netdev/2003-09/msg00415.html (9,446 bytes)
- 6. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: chuymer <bdschuym@xxxxxxxxxx>
- Date: Sun, 14 Sep 2003 12:55:49 +0200
- Mitchell Blank Jr <mitch@xxxxxxxxxx> : - the locking is needed - the recheck is needed (- it does more than the recheck) My point was related to the comment included in the patch, namely "/* re-check
- /archives/netdev/2003-09/msg00420.html (12,153 bytes)
- 7. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: <amir.noam@xxxxxxxxx>
- Date: Sun, 14 Sep 2003 04:26:28 -0700
- OK, that was what I thought was going on. I figured the short comment (along with the likely()) would explain this adequately (i.e. "we're now re-checking under lock so we get the authorative answer"
- /archives/netdev/2003-09/msg00421.html (9,335 bytes)
- 8. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: bali <ratz@xxxxxxxxxxxx>
- Date: Mon, 15 Sep 2003 15:56:52 -0700
- When you guys decide on a final patch let me know, the semantic parts of Mitchell's changes look perfectly fine to me.
- /archives/netdev/2003-09/msg00465.html (9,753 bytes)
- 9. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: ler" <davem@xxxxxxxxxx>
- Date: Mon, 15 Sep 2003 20:13:55 -0700
- How about something like the following. It expands the comment but turns that bit of code into an inline function so we onlt have to explain it once. Untested, but compiles fine. -Mitch -- linux-2.6.
- /archives/netdev/2003-09/msg00478.html (11,636 bytes)
- 10. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: minger <shemminger@xxxxxxxx>
- Date: Mon, 15 Sep 2003 22:41:19 -0700
- Looks good, applied.
- /archives/netdev/2003-09/msg00480.html (9,566 bytes)
- 11. [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
- Date: Fri, 12 Sep 2003 22:50:33 -0700
- In both places af_packet.c calls sk_run_filter() it does a "filter = never actually uses this variable for anything -- it always refers to the filter as sk->sk_filter instead. Clearly this wasn't int
- /archives/netdev/2003-09/msg01336.html (9,563 bytes)
- 12. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Francois Romieu <romieu@xxxxxxxxxxxxx>
- Date: Sat, 13 Sep 2003 09:35:59 +0200
- Mitchell Blank Jr <mitch@xxxxxxxxxx> : [...] 1 - pointers tests against NULL are naturally supposed "unlikely" by gcc. 2 - I am not completely convinced that the "/* re-check under lock */" comment i
- /archives/netdev/2003-09/msg01338.html (10,878 bytes)
- 13. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
- Date: Sat, 13 Sep 2003 01:02:52 -0700
- I thought that without the comment someone might think that the second "if()" wasn't needed (since we had just checked the same value against NULL a few lines up) -Mitch
- /archives/netdev/2003-09/msg01339.html (8,757 bytes)
- 14. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Francois Romieu <romieu@xxxxxxxxxxxxx>
- Date: Sat, 13 Sep 2003 11:03:53 +0200
- Mitchell Blank Jr <mitch@xxxxxxxxxx> : [...] Ok, I completely missed the intent. Actually packet_rcv() is run in a BH context and doesn't race with SO_{ATTACH/DETACH}_FILTER from sock_setsockopt() wh
- /archives/netdev/2003-09/msg01341.html (9,477 bytes)
- 15. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
- Date: Sat, 13 Sep 2003 13:15:59 -0700
- I don't understand what you're saying - are you saying that the locking isn't needed? Or just the recheck isn't needed? It sounds like if we're only avoiding the race because of the bh_lock_sock() th
- /archives/netdev/2003-09/msg01344.html (9,593 bytes)
- 16. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Francois Romieu <romieu@xxxxxxxxxxxxx>
- Date: Sun, 14 Sep 2003 12:55:49 +0200
- Mitchell Blank Jr <mitch@xxxxxxxxxx> : [...] - the locking is needed - the recheck is needed (- it does more than the recheck) My point was related to the comment included in the patch, namely "/* re
- /archives/netdev/2003-09/msg01349.html (12,372 bytes)
- 17. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
- Date: Sun, 14 Sep 2003 04:26:28 -0700
- OK, that was what I thought was going on. I figured the short comment (along with the likely()) would explain this adequately (i.e. "we're now re-checking under lock so we get the authorative answer"
- /archives/netdev/2003-09/msg01350.html (9,539 bytes)
- 18. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: "David S. Miller" <davem@xxxxxxxxxx>
- Date: Mon, 15 Sep 2003 15:56:52 -0700
- When you guys decide on a final patch let me know, the semantic parts of Mitchell's changes look perfectly fine to me.
- /archives/netdev/2003-09/msg01394.html (9,989 bytes)
- 19. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: Mitchell Blank Jr <mitch@xxxxxxxxxx>
- Date: Mon, 15 Sep 2003 20:13:55 -0700
- How about something like the following. It expands the comment but turns that bit of code into an inline function so we onlt have to explain it once. Untested, but compiles fine. -Mitch -- linux-2.6.
- /archives/netdev/2003-09/msg01407.html (11,916 bytes)
- 20. Re: [PATCH] tiny af_packet.c cleanup (score: 1)
- Author: "David S. Miller" <davem@xxxxxxxxxx>
- Date: Mon, 15 Sep 2003 22:41:19 -0700
- Looks good, applied.
- /archives/netdev/2003-09/msg01409.html (9,867 bytes)
This search system is powered by
Namazu