This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code. This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will...

This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code. This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will...

This version of the patch hopefully integrates all of the requested changes: - the sock_map_fd interface is changed and all in-tree users changed. No additional function anymore - there is a helper function to convert the new socket flags into file flags. Shared by all three functions - the new accept interface is now paccept() which adds the flag parameter as well as a signal mask. - not changed from the last version: the paccet() function takes a flags parameter with the same val...

Also, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000014 printing eip: c030659e *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: xt_tcpudp iptable_mangle xt_MARK xt_multiport ip_tables x_tables ip_vs_wrr ip_vs_wlc ip_vs_sh ip_vs_sed ip_vs_rr ip_vs_nq ip_vs_lc ip_vs_lblcr ip_vs_lblc ip_vs_ftp ip_vs_dh pcnet32 crc32 e1000 e100 mii Pid: 3960, comm: ipvs_syncbackup Not tainted (2.6.24.4 #3) EIP: 0060:[<c030659e>] EFLAGS: 00010246 CPU: 0 EIP is at sy...

Hi. Any chance to run gdb ./vmlinux $ l *(sync_thread+0x919) for that kernel, and if it was not compiled with debug info try to do I'm not ipvs guru, but that will give us at least some hint... -- Evgeniy Polyakov --

Is the proxy server accepting connections after the issue has occurred? Or do you need to re-boot? Or do you have to wait for a number of seconds or what? Cheers, --

Well, there are too many possibilities for failures... the Linux distribution (RHEL 3 workstation) was built for 2.4.21 (around year 2003) and you try 2.6.x Maybe you should stick to one of the later 2.4.x kernels or even better upgrade the Linux distribution. Cheers, --

What about removing the assignment "err =" in that case. It's confusing otherwise and maybe the variable err is even obsolete. Wolfgang. --

I can definitely follow Daves remarks regarding the ability to review local bugfixes. In this case two commits should be used. Btw. the cleanup an removal of the err variable usage in the pointed cases is a good suggestion. So even when the two latest changes in Sam's patch are not that obvious to be able to be reviewed locally i would like to ack this patch. It should apply fine on Linus' tree and the current net-2.6. Thanks to all of you & have a nice weekend. Oliver -- ...

Both copy_to_ and _from_user return the number of bytes, that failed to reach their destination, not the 0/-EXXX values. Based on patch from Pavel Emelyanov <xemul@openvz.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Cc: Pavel Emelyanov <xemul@openvz.org> Cc: Wolfgang Grandegger <wg@grandegger.com> --- OK - here is a proper patch. Actual patch is the same - I just added a proper changelog. Sam ...

Sorry! Workaround for a newly introduced kbuild bug and I did not review my patch properly. I hand edited it out in first mail but should have done so in my queued patch to prevent this. Sam --

OK, I see, if you have to review a lot of patches, it does matter, indeed. Wolfgang. --

Well, really, if (func(x)) return -EFAULT; instead of err = func(x); if (err) return -EFAULT; is more straight forward and less confusing and I do not understand, why it should be harder to review. Wolfgang. --

Hi. Ok, I can not reproduce it, so lets try hard way. Can you test attached patch, its idea is described above and I checked multiple times, that it is forbidden to free skb and return non-zero value from tcp_rcv_established(). This behaviour was introduced with TCP defer accept changes in 2.6.25 with ec3c0982a2dd1e671bad8e9d26c28dcba0039d87 commit. Please test. This bug affects both ipv6 and ipv4 code actually. diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index ac9b848..0298f80...

Sorry, you cannot do this. Build with allmodconfig. --yoshfuji --

Please define __compat_sockaddr_storage{} with attribute((aligned(4))). net/compat.c is not the right place. Please put this in net/ipv4/compat.c or so. __copy_in_user(). Maybe we can use __copy_in_user for u32? --yoshfuji --

YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote on 04/25/2008 I just tried it and the compiler seems to do that for this case, but the gcc documentation says explicitly that you need both packed and aligned if you want it to be a specific value. aligned(4) is a minimum only and the compiler would be free to add pad still as long as the padded value was also 4-byte aligned. In this case, we want no pad, so packed is the relevant part. If had a char followed by...

Isn't that appropriate in the general case? If the architecture actually required 8-byte alignment to access the type and we only have 4-byte alignment because the app was compiled with different (32 bit) alignment rules, then we'd fault if we forced the alignment and accessed it directly. That's why we don't access it directly. In these, we're using the (byte) copy functions to get the (totally inappropriately aligned because it wasn't compiled in 64-bit mode) data to the well behaved and ...

__compat_sockaddr_storage{} is intended for defining **self-containing** sockaddr_stroage{} aligned like 32bit archs - aligned(4). Even your code - sockaddr_storage{} might be aligned on 64bit even on 32bit archs. If the alignment rules of 32bit were different between 32bit and 64bit, most (if not all) compat layers must have been changed. See? The attribute((packed)) is overkill and evil. Please remove that. Per-member attribute is ugly and the definition is not self-contained. So, please d...

From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> I see no reason not to put this in net/compat.c, it's acting like fs/compat_ioctl.c which even has networking compat ioctls implemented there, among other things ;-) --

From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> Actually, it is a problem. I take back what I said. There is no easy way to call into the ipv6 code from this built-in code if IPV6 is built modular. So it really does have to go into ipv4 and ipv6 subdirectories, respectively. David, please make this adjustment. Thanks! --

From: David Stevens <dlstevens@us.ibm.com> If you're going to use callbacks, and I'd be also asking you to guard this code with CONFIG_IPV6 as appropriate, why not simply put it into the ipv6 socket option handling code? I really see no value putting this in some generic location if we have to deal with those issues, by adding callbacks and ifdef'ery. --

From: David Stevens <dlstevens@us.ibm.com> Fair enough, code this up so I can see what it looks like. Thanks for all of this work David! --

Hrm ... yeah allright I missed my initial typo and I missed Bill joke :-) looks like another case of replying while still half asleep ... Ben. --

Are there any comments on this driver? We've been using it for a while now in Debian and it would be great see it in the mainline kernel. -- Martin Michlmayr http://www.cyrius.com/ --