Hi! I noticed the following warnings when running on 2.6.27-rc2 with lockdep checker enabled: [ 2912.004106] Initializing XFRM netlink socket [ 2922.009629] [ 2922.009632] ============================================= [ 2922.009640] [ INFO: possible recursive locking detected ] [ 2922.009643] 2.6.27-rc2-mst-suspend #32 [ 2922.009645] --------------------------------------------- [ 2922.009648] Xorg/5958 is trying to acquire lock: [ 2922.009650] (slock-AF_INET/1){-+..}, at: [<c02f105a>] __...

Use return value from inner qdisc requeue when value returned isn't NET_XMIT_SUCCESS, instead of always returning NET_XMIT_DROP. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> --- net/sched/sch_prio.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c index eac1976..7cdc3e6 100644 --- a/net/sched/sch_prio.c +++ b/net/sched/sch_prio.c @@ -117,7 +117,7 @@ prio_requeue(struct sk_buff *skb, struct Qdisc* sch) ...

From: Stephen Hemminger <stephen.hemminger@vyatta.com> I'll see why this happens, it wasn't an intentional change. Before the link comes up, we don't activate the qdisc. We just remember it in ->qdisc_sleeping. I bet if you bring the link up the configuration will become visible, or that is the area where the unintentional error is occuring. --

0xffffffff80424dd3 is in rt6_fill_node (net/ipv6/route.c:2191). 2186 } else 2187 #endif 2188 NLA_PUT_U32(skb, RTA_IIF, iif); 2189 } else if (dst) { 2190 struct in6_addr saddr_buf; 2191 ====> if (ipv6_dev_get_saddr(ip6_dst_idev(&rt->u.dst)->dev, ^^^^^^^^^^^^^^^^^^^^^^^^ NULL 2192 dst, 0, &saddr_buf) == 0) 2193 ...

On Linux, SO_REUSEADDR provide most of what SO_REUSEPORT provides on BSD. In any case, there is absolutely no point in creating multiple TCP listeners. Multiple threads can accept() on the same listener - at the same time. -- Rémi Denis-Courmont http://www.remlab.net/ --

How would the presence of multiple TCP LISTEN endpoints change that? You'd then be at the mercy of whatever "scheduling" there was inside the stack. If you want to balance the threads, perhaps a dispatch thread, or a virtual one - each thread knows how many connections it is servicing, let them know how many the other threads are servicing, and if a thread has N more connections than the other threads have it not go into accept() that time around. Might need some tweaking to handle patho...

On Thu, Aug 7, 2008 at 12:03 PM, Stephen Hemminger I'm not sure that's applicable for us since the server application and networking will max out all the CPUs on host anyway; one way or another we need to dispatch the work of incoming connections to threads on different CPUs. If we do this in user space and do all accepts in one thread, the CPU of that thread becomes the bottleneck (we're accepting about 40,000 connections per second). If we have multiple accept threads running on different CPUs...

Yep that's what I really want, except for the fact that I can only use a single port for the server-- all flows could be nicely distributed by the NIC multiqueue, but I still have the problem of how to ensure that the accepting thread for a connection is run on the same CPU as NICs are already doing steering based on tuple hash (RSS), and I think some will allow specifying the CPU for interrupt based on RX flow. Maybe this would address the issues of Inbound Packet Scheduling? Thanks for the p...

After some cleanups in arch/mips area, now MACH_TX49XX is selected for both TOSHIBA_RBTX4927 and TOSHIBA_RBTX4938. Fold these two conditions to one. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> --- drivers/net/Kconfig | 2 +- drivers/net/ne.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 8a03875..b6c1717 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1171,7 +1171,7 @@ config ETH1...

Hi, I am having difficulties with the MCS7830 driver in recent Linux versions (last version I tried was 2.6.26.1, didn't try 2.6.26.2 yet). It looks like the MCS7830 has an issue which prevents VLAN tagged ethernet frames from being transmitted and/or received when the frame size is near the ethernet MTU. This behavior was known around the millennium for a lot of ethernet drivers (including tulip) drivers. The host OS does not know that the frame is destined to go out via a VLAN tagged interface...

[Empty message]

This is the third iteration of the IPVS Netlink interface, this time with only a small fix for a typo found by Thomas Graf. If there are no further major issues, can this be applied? The two patches add a Generic Netlink interface to IPVS while keeping the old get/setsockopt interface for userspace backwards compatibility. The motivation for this is to have a more extensible interface for future changes, such as the planned IPv6 support. An ipvsadm that already uses the new interface is available...

Add IPVS Generic Netlink interface definitions to include/linux/ip_vs.h. Signed-off-by: Julius Volz <juliusv@google.com> 1 files changed, 160 insertions(+), 0 deletions(-) diff --git a/include/linux/ip_vs.h b/include/linux/ip_vs.h index ec6eb49..0f434a2 100644 --- a/include/linux/ip_vs.h +++ b/include/linux/ip_vs.h @@ -242,4 +242,164 @@ struct ip_vs_daemon_user { int syncid; }; +/* + * + * IPVS Generic Netlink interface definitions + * + */ + +/* Generic Netlink family i...

Acked-by: Jamal Hadi Salim <hadi@cyberus.ca> cheers, jamal --

iproute2 doesnt like it, so i was getting irritated by this on my laptop. cheers, jamal

Noticed while exercising Denys' iproute changes. cheers, jamal

Jeff, it seems you missed this patch: From: Mikael Pettersson <mikpe@it.uu.se> The arm ixp4xx_eth driver doesn't compile in 2.6.27-rc1: CC [M] drivers/net/arm/ixp4xx_eth.o drivers/net/arm/ixp4xx_eth.c: In function 'eth_poll': drivers/net/arm/ixp4xx_eth.c:554: warning: passing argument 1 of 'dma_mapping_error' makes pointer from integer without a cast drivers/net/arm/ixp4xx_eth.c:554: error: too few arguments to function 'dma_mapping_error' drivers/net/arm/ixp4xx_eth.c: In function 'eth...

Hello, all! I'm working on IPv6 support for Ininiband stack and some module need to perform network discovery. Is there a way to do it without exporting symbol ndisc_send_ns? --

If the following packet flow happen, kernel will panic. MathineA MathineB SYN ----------------------> SYN+ACK <---------------------- ACK(bad seq) ----------------------> When a bad seq ACK is received, tcp_v4_md5_do_lookup(skb->sk, ip_hdr(skb)->daddr)) is finally called by tcp_v4_reqsk_send_ack(), but the first parameter(skb->sk) is NULL at that moment, so kernel panic happens. This patch fixes this bug. Below is the OOPS output: [ 302.812793] IP: ...

From: David Miller <davem@davemloft.net> Actually I'm reverting, this was not properly build tested: net/dccp/ipv4.c:555: warning: initialization from incompatible pointer type net/dccp/ipv6.c:358: warning: initialization from incompatible pointer type --

From: Gui Jianfeng <guijianfeng@cn.fujitsu.com> Applied, let's see if this one build properly :-) --

include/linux/rculist.h : hlist_for_each_entry_rcu and friends. Does it contain needded calls? -- Evgeniy Polyakov --

From: Stephen Hemminger <stephen.hemminger@vyatta.com> Don't bother bisecting, it will take longer than the obvious set of debug printk's you could add to net/sched/sch_api.c:tc_dump_qdisc(). Please use a "mindful" approach to debugging this instead of a "mindless" one like bisect :-) --

From: Stephen Hemminger <stephen.hemminger@vyatta.com> What ever happened to debugging things by reading the code and thinking? By all means, when I'm dealing with a user who doesn't know the kernel or networking in particular very well, going the bisect route is often the way. But for someone as skilled and knowledgable as you? Give me a break :-) --

From: Stephen Hemminger <stephen.hemminger@vyatta.com> Thanks. --