Pretty small pile of patches (are two patches even a pile) this time around, but they should make things a little faster. The first patch addresses a gripe Casey had about an extra allocation/copy for the NetLabel secattr and the second tries to address the Labeled IPsec stack ugliness pointed out by Jamal and Dave. I'm posting these as RFC patches for right now because I haven't had a chance to really beat on these changes, however, with 2.6.26 getting close I wanted to get these out so people co...

Smack doesn't have the need to create a private copy of the LSM "domain" when setting NetLabel security attributes like SELinux, however, the current NetLabel code requires a private copy of the LSM "domain". This patches fixes that by letting the LSM determine how it wants to pass the domain value. * NETLBL_SECATTR_DOMAIN_CPY The current behavior, NetLabel assumes that the domain value is a copy and frees it when done * NETLBL_SECATTR_DOMAIN New, Smack-friendly behavior, NetLabel as...

Thanks Eric, I didn't expect someone to identify and fix this bug so quickly!. I have tested your patch and my problems have gone away. thanks Andrew --

The kernel-doc comment for skb_segment is clearly wrong. This states what it actually does. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 0d0fd28..6087013 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -2131,8 +2131,8 @@ EXPORT_SYMBOL_GPL(skb_pull_rcsum); * @features: features for the output path (see dev->features) * * This function performs segmentation on the given skb. It returns - * the segment ...

Pavel Emelyanov wrote, On 04/07/2008 06:31 PM: IMHO this second "+ NETDEV_ALIGN_CONST" is needed here because of "~NETDEV_ALIGN_CONST". Regards, Jarek P. --

On 32 bits platform and CONFIG_X86_L1_CACHE_SHIFT=7 I presume :) Could you check if x86_64 machines with X86_L1_CACHE_SHIFT = 7 or 8 dont suffer from this patch ? At first glance I would say it seems OK, but this net_device is really --

Info _before_ Pavel's patch, not that big holes. [acme@doppio linux-2.6]$ getconf LEVEL1_DCACHE_LINESIZE 64 model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz [acme@doppio linux-2.6]$ grep X86_L1_CACHE_SHIFT /boot/config-`uname -r` CONFIG_X86_L1_CACHE_SHIFT=6 [acme@doppio linux-2.6]$ pahole -C net_device ../build/linux-2.6/doppio/net/core/dev.o struct net_device { char name[16]; /* 0 16 */ struct hlist_node name_hlist; ...

There was a bug #8747, http://bugzilla.kernel.org/show_bug.cgi?id=8747, "MSG_ERRQUEUE messages do not pass to connected raw sockets", which still is not fixed, due to absence of proper tests. I've made an additional patch (attached), against the 2.6.24.4 tree. The patch fixes the issue completely for me. Tested. Sorry that I have not checked up the previous attempt in real tests. I assumed that the "typo" which I had found at that time (saddr/daddr swapped) is just "a typo", and things "ob...

On Mon, 7 Apr 2008, Ilpo J

Fixes a long-standing bug which makes NewReno recovery crippled. With GSO the whole head skb was marked as LOST which is in violation of NewReno procedure that only wants to mark one packet and ended up breaking our TCP code by causing counter overflow because our code was built on top of assumption about valid NewReno procedure. This manifested as triggering a WARN_ON for the overflow in a number of places. It seems relatively safe alternative to just do nothing if tcp_fragment fails due to oom b...

MTU probe can cause some remedies for FRTO because the normal packet ordering may be violated allowing FRTO to make a wrong decision (it might not be that serious threat for anything though). Thus it's safer to not run FRTO while MTU probe is underway. It seems that the basic FRTO variant should also look for an skb at probe_seq.start to check if that's retransmitted one but I didn't implement it now (plain seqno in window check isn't robust against wraparounds). Signed-off-by: Ilpo Järvinen &...

Fixes a long-standing bug which makes NewReno recovery crippled. With GSO the whole head skb was marked as LOST which is in violation of NewReno procedure that only wants to mark one packet and ended up breaking our TCP code by causing counter overflow because our code was built on top of assumption about valid NewReno procedure. This manifested as triggering a WARN_ON for the overflow in a number of places. It seems relatively safe alternative to just do nothing if tcp_fragment fails due to oom b...

This fixes Bugzilla #10384 tcp_simple_retransmit does L increment without any checking whatsoever for overflowing S+L when Reno is in use. The simplest scenario I can currently think of is rather complex in practice (there might be some more straightforward cases though). Ie., if mss is reduced during mtu probing, it may end up marking everything lost and if some duplicate ACKs arrived prior to that sacked_out will be non-zero as well, leading to S+L > packets_out, tcp_clean_rtx_queue on the ...

Hello. I apologize, but it will have to wait a few days, as the fan on the graphics card just broke, and it overheats almost instantly. I will post as soon as possible, sorry for the inconvenience. --

Actually, yes. But I wanted to get it out there before I start the treck across to the virtualization summit. A few points: 'The page alignment for the used array is important - that array might be mapped separately into kernel space.' Well, the used array is written by one side only, so it's possible to split the ring here and make each part r/o to the other side. More importantly, a page boundary is almost certainly a cacheline boundary, and we already have a userspace interface for ...

Erk... I'll put in the latter for now. A page-level solution is not really an option: if userspace hands us mmaped pages for example. Thanks, Rusty. --

Hello, I understand your frustration with the existing LSM hooks/API and your reasoning for abandoning LSM in favor of a new set of hooks, however, I think this sets a dangerous precedence which could result in an abundance of security related hooks scattered throughout the kernel. I would much rather see the LSM API extended/tweaked to support the needs of SAKURA and TOMOYO than ignored and duplicated; I suspect several others will say the same. You have made good progress with TOMOYO ...

Filesystem part to fsdevel, socket operation part to netdev. That's OK. But I wonder where to post the rest part. Since the patches for passing "struct vfsmount" to LSM has been rejected, TOMOYO has been unable to use LSM. Thus, I proposed this patch set as a non-LSM version, but it bothers me I see. Thank you. --

https://plone3.fnal.gov/P0/WAN/Members/wenji/tcp_dump_files_sack/ Two tcpdump files: one with SACK on, the other with SACK off. The test configures described in my previous emails. Best, wenji --

Hello, I had compilation errors when trying to build pim6sd soleley , and it seems to me that the code should be changed for it to compile. I found another PIM-sm open source project, which **does** build cleanly on my Linux box: It is mrd6: http://fivebits.net/proj/mrd6/ Perhaps you have any ideas: Should it work with multicast routing with this kernel patch ? are there specific requirements which mcast-tools fulfiils (and maybe mrd6 does not) ? Regards, AJ On Thu, Apr 3, 2008 at 10:31 AM, YOSHI...

Hum... I prefer my patch Stephen, as your version enlarges every tnode with an embedded "struct work_struct" which can be larger than a "struct rcu_head" And as your 2nd patch doesnt use vmalloc() at all, we only can gain one order for the max bits in root node (19 instead of 18) : We will hit the 'bug' again in a couple of months, or if router memory is somehow fragmented. --

Stephen Hemminger writes: > Eric wisely pointed out that for larger sizes of nodes, the > current allocation in fib_trie wastes lots of memory. For a sample > of routes extracted from the bugzilla bug the largest node grows > to 2M bytes on 64 bit system. This leads to 2044K of wasted memory. > > There are two possible solutions (see attached). One uses vmalloc() > rather than alloc_pages, but has to add complexity on freeing. > The other adds a layer of indirecti...

Andi Kleen writes: > > Do we get slower with vmalloc due to TLB-lookups etc? Guess this > > should be investigated. > > In some cases it might even go faster because a lot of x86 CPUs > have far more 4K TLBs than 2M TLBs. vmalloc is just quite expensive > in setup/free time, but that shouldn't be a big issue here. I've did some rDoS testing and the lookup performance is the same or slightly better. So it should be fine. Cheers --ro ...

Yes, but with vmalloc(), NUMA machines have some chance to distribute this big area on several nodes (only if the process currently expanding the fib_trie root node has an appropriate numa_policy.... ah well :) :) ) --

Check length of setsockopt's optval, which provided by user, before copy it from user space. For POSIX compliant, return -EINVAL for setsockopt of short lengths. Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com> --- net/ipv6/ipv6_sockglue.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c index bf2a686..a5ac121 100644 --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -557,6 +557,9 @@ d...