It appears as though the following net-next-2.6 commit (pulled Oct 1 2008) exposes a null pointer dereference in dev.c:dev_gso_skb_destructor(). commit 242f8bfefe4bed626df4e4727ac8f315d80b567a Author: David S. Miller <davem@davemloft.net> Date: Mon Sep 22 22:15:30 2008 -0700 pkt_sched: Make qdisc->gso_skb a list. The idea is that we can use this to get rid of ->requeue(). Signed-off-by: David S. Miller <davem@davemloft.net> From what I can tell, ...

Seems my silly mistake, i used wrong option in skbedit (first which i seen in example). Thanks to Intel guys, now it is possible also by this way: tc qdisc del dev eth2.10 root tc qdisc add dev eth2.10 root handle 1: prio /sbin/tc filter add dev eth2.10 parent 1:0 protocol all u32 match u32 0 0 action skbedit priority 3 So it is possible now to do 802.1p marking on router(not bridge), by u32 filter or whatever. tc qdisc del dev eth2.10 root tc qdisc add dev eth2.10 root handle 1: ...

Bridging traffic to a VLAN device should work, you can then define the priority for the device. I'm not aware of an easier method, but I believe act_pedit should also be able to do this. --

From: Herbert Xu <herbert@gondor.apana.org.au> Applied, thanks Herbert. --

are you still getting WARN_ON *with* all the mutex based fixes already applied? with the mutex patches in place (without protection patch) we are still reproducing the issue, until we apply the set_memory_ro patch. I had no luck on friday setting a hardware breakpoint on memory access with kgdb to catch the writer with a breakpoint. --

The WARN_ON triggers with current mainline. Is there any fixlet in That does not make sense to me. If the memory_ro patch is providing _real_ protection then you _must_ run into an access violation. If not, then the patch just papers over the real problem in some mysterious way. The patch does: + set_memory_rw((unsigned long)hw->flash_address, + hw->flash_len >> PAGE_SHIFT); writew(val, hw->flash_address + reg); + set_memory_ro((unsigned long)hw->flash_address, + ...

not if the bad code is doing copy_to_user .... (or similar) --

You mean: copy_from_user :) This would require that the e1000e nvram region is writable via copy_from_user by an e1000e user space interface. A quick grep does not reviel such a horrible interface. Thanks, tglx --

Hi. Just for the reference, this one regresses from the 2.6.23. Particular 2.6.26-27 part can be partially fixed by disabling TSO/GSO, since tbench workload issues quite small packets, and system has no time to incorporate them into particulary big TSO/GSO frame to get advantage of this technology. The most noticeble perfromance drop was between 23 and This one is different, but any other benchmark related to network over loopback (and in some case over other media) performance ...

I meant it continuously regresses from .23 including 26-27 timeframe. There were at least two changes in 26-27 which caused tbench regression in this particular time interval. One of them enabled TSO over loopback by default, so one can turn it off via ethtools or this patch: http://marc.info/?l=linux-netdev&m=122263663631600&w=2 another (hopefully) one I'm trying to find out, which is a bit complex and slow, since e1000 driver changes in the middle of the 26-27 timeframe does not allow my ...

From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com> All applied to net-next-2.6, thanks! --

n Sun, 5 Oct 2008, D

On Sun, 5 Oct 2008 20:09:22 +0200 (CEST) Ok, here they are (I hope one of them is correct): http://www.abusar.org/ftrace/ These ones I get after I saw the kernel message "Tracer stopped". http://www.abusar.org/ftrace/trace.txt.bz2 http://www.abusar.org/ftrace/trace2.txt.bz2 http://www.abusar.org/ftrace/trace3.txt.bz2 http://www.abusar.org/ftrace/trace4.txt.bz2 http://www.abusar.org/ftrace/trace5.txt.bz2 These ones were during a stall and after a ...

I've got another patch that takes a different approach... Instead of disabling the secret_interval timer or trying to heuristically guess when we're under attack, we continue to invalidate the cache; we just invalidate it with kid-gloves instead of a sledge hammer. Like we do today, we continue to update the genid every time the secret_interval timer expires. Instead of simply creating a new value (and thus invalidating the entire cache), we keep a short history of genid values (I'm thinking ...

This is completely bogus. We never allow any chain to grow beyond the elasticity. So in the worst case we just bypass the route cache. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

From: "Andrew Dickinson" <whydna@whydna.net> This is a very interesting patch and idea, but... Eric showed clearly that on a completely normal well loaded system, the chain lengths exceed the elasticity all the time and it's not like these are entries we can get rid of because their refcounts are all > 1 --

Just reading this code (plus the comment). Why would anybody bother with something so complex like this if something like your idea is rather straightforward? But, needed or not, my point is it would be nice to comment that this patch changes this behavior btw. Jarek P. --

Where did you get that idea? This was there because people did (and still do) stuff like: unregister_netdev(dev); free_netdev(dev); Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

I'm sorry but I don't have time to consider such hypotheticals. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

The original DSA tagging format can work with any NIC, as long as you hook up that NIC directly to a DSA switch chip instead of to a PHY. In embedded designs you mostly see platform bus drivers like mv643xx_eth and gianfar and such, but there's no reason you can't do it with any other MAC that exposes a (R)(G)MII interface. The only reason that eth_type_trans() needs a hack is that the original DSA tagging format has information starting right after the ethernet source address, so there's ...

David, please read below: ------------------------> Great! So, I think we could agree with this: 1. Reverting this patch fixes the oops which started this thread: commit 30902dc3cb0ea1cfc7ac2b17bcf478ff98420d74 Author: David S. Miller <davem@davemloft.net> Date: Tue Jun 17 21:26:37 2008 -0700 ax25: Fix std timer socket destroy handling. 2. Alternative (original) fix proposed by Tihomir Hidelberg: http://marc.info/?l=linux-netdev&m=121370472223572&w=2 doesn't seem to ...

Here are a few interesting data captured via netconsole from kernel-2.6.27-rc7 without af_netrom patch #4. AX25_DBG: c4002338, 00000000, 1, 1, 0 AX25_DBG: c4002008, 00000000, 1, 0, 0 AX25_DBG: c4002668, 00000000, 1, 1, 0 AX25_DBG: c4002008, 00000000, 1, 0, 0 AX25_DBG: c4002668, 00000000, 1, 1, 0 AX25_DBG: c4002008, 00000000, 1, 0, 0 AX25_DBG: c4002008, 00000000, 1, 2, 0 AX25_DBG: c4002008, 00000000, 1, 2, 0 AX25_DBG: c4002998, 00000000, 1, 0, 0 AX25_DBG: c4002008, 00000000, 1, 1, ...

netrom: Fix sock_orphan() use in nr_release While debugging another bug it was found that NetRom socks are sometimes seen unorphaned in sk_free(). This patch moves sock_orphan() in nr_release() to the beginning (like in ax25, or rose). Reported-and-tested-by: Bernard Pidoux f6bvp <f6bvp@free.fr> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> --- net/netrom/af_netrom.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netrom/af_netrom.c ...

I've looked at this a bit and here are some conclusions: I think this David's patch should be reverted: it's probably colliding currently with ax25_disconnect(), and there could be double destroying or something. Since I don't know this code enough, I'm not going to look now for the cleanest possible solution. I'd only like to mention that this "/* Magic here: If we listen()..." is still left in a few other places (ax25, rose, netrom, x25), so removing this one isn't too consistent. Anyway ...

From: Gerrit Renker <gerrit@erg.abdn.ac.uk> After patch 1: CC [M] net/dccp/feat.o net/dccp/feat.c:28: warning: ‘dccp_feat_clone_sp_val’ defined but not used After patch 2: CC [M] net/dccp/feat.o net/dccp/feat.c:118: warning: ‘dccp_feat_clone_entry’ defined but not used net/dccp/feat.c:139: warning: ‘dccp_feat_entry_destructor’ defined but not used After patch 3: CC [M] net/dccp/feat.o net/dccp/feat.c:118: warning: ‘dccp_feat_clone_entry’ defined but not ...