and here is the config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27.6 # Fri Nov 14 00:29:54 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" # CONFIG_GENERIC_LOCKBREAK is not ...

It also make no sense to expose write_pnet() for one(!) user and simultaneously hide read_pnet() under ib_net() as committed patches do. Something is wrong with read_pnet() as nobody suggested to mass use it or send a patch doing it. #ifdef CONFIG_NET_NS ib->ib_net = net; #endif It's _obvious_ from this code that it's a C assignment or nop. It's also obvious depending on what config option. write_pnet(&ib->ib_net, net); What is & operator ...

You obviously didnt read my patches. How do you want to implement a C function that can write to ib->ib_net ? Yes, I prefer a function over a macro, as most kernel developpers, for obvious reasons. Only sane way is : static inline void write_pnet(struct net **pnet, struct net *net) { *pnet = net; } and call write_pnet(&ip->ib_net, net); Strange, this is what I did. Take the time to read the patch, please. Thank you --

Here's my test program. Works on x86-32. Should work on x86-64, but I don't have a system to hand to test with. It tests accept4() with each of the four possible combinations of SOCK_CLOEXEC and SOCK_NONBLOCK set/clear in 'flags', and verifies that the appropriate flags are set on the file descriptor/open file description returned by accept4(). I tested Ulrich's patch in this thread by applying against 2.6.28-rc2, and it passes according to my test program. /* test_accept4.c ...

... Each of these new system calls (accept4(), dup3(), evenfd2(), signalfd4(), inotify_init1(), epoll_create1(), pipe2()) has a name that's based on the number of arguments it has. This follows a convention that was used in a few traditional Unix system calls, e.g., wait3(), wait4(), dup2(). However, it's probably a mistake since: a) The glibc interfaces can have different numbers of arguments from the system call b) In the future, we might use the new bits in the flags argument ...

Actually, any architecture that uses sys_socketcall should be OK already, by the looks, and that includes powerpc. Paul. --

On Thu, 13 Nov 2008 16:51:56 -0500 That's easy - I'll send it to Linus and let him decide ;) Realistically, this isn't likely to get much third-party testing in -rc anyway. Our best defence at this time is careful review and developer runtime testing, which you've done, thanks. If it's buggy, we can live with that - fix it later, backport the fixes. It's security holes (including DoS ones) which we need to be I replaced the existing changelog with the above (plus some ...

p_{tx,rx}_fw_statistics_pram are special: they're available only when a device is open. If the device is closed, we should just fill the data with zeroes. Fixes the following oops: root@b1:~# ifconfig eth1 down root@b1:~# ethtool -S eth1 Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc01e1dcc Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c01e1dcc] uec_get_ethtool_stats+0x98/0x124 LR [c0287cc8] ...

After implementing qdisc->ops->peek() and changing sch_netem into classless qdisc there are no more qdisc->ops->requeue() users. This patch removes this method with its wrappers (qdisc_requeue()), and also unused qdisc->requeue structure. There are a few minor fixes of warnings (htb_enqueue()) and comments btw. The idea to kill ->requeue() and a similar patch were first developed by David S. Miller. Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> --- include/net/sch_generic.h | 17 ...

IP_PKTINFO does not have a port number field which may be changed with tproxy redirections. -- Bazsi --

Does this not duplicate the IP_PKTINFO functionality? -- Rémi Denis-Courmont Maemo Software, Nokia Devices R&D --

I think you're confusing it with tcphdr's field of the same name. Petr's patch is correct as far as I can see. -Andi -- ak@linux.intel.com --

I've applied this to net-2.6 thanks Randy. I didn't get it earlier because I thought perhaps the Infiniband folks might want to have picked this one up. --

We have some reasons to kill netdev->priv: 1. netdev->priv is equal to netdev_priv(). 2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously netdev_priv() is more flexible than netdev->priv. But we cann't kill netdev->priv, because so many drivers reference to it directly. This patch is a safe convert for netdev->priv to netdev_priv(netdev). Since all of the netdev->priv is only for read. But it is too big to be sent in one mail. I split it to 4 parts and make every ...

From: Wang Chen <wangchen@cn.fujitsu.com> Applied. --

From: Wang Chen <wangchen@cn.fujitsu.com> Applied. --

From: Wang Chen <wangchen@cn.fujitsu.com> Applied. --

Mostly driver fixes, as usual: 1) NIU driver doesn't work properly on 32-bit 2) BNX2 driver passes wrong object down into interrupt handler from ->poll_controller() and also doesn't check all RX queues. Fix from Neil Horman. 3) put_cmsg_compat() uses SO_TIMESTAMP* instead of SCM_TIMESTAMP* They are the same values, but it makes the code super confusing to read. 4) EEPROM handling and multiqueue fixes to CXGB3 from Divy Le Ray. 5) HTCP congestion control module does not ...

From: "Michael Chan" <mchan@broadcom.com> Applied. --

From: "Michael Chan" <mchan@broadcom.com> Also applied, thanks Michael. --

Hi all # grep bnx2 /proc/vmallocinfo 0xf8218000-0xf821a000 8192 bnx2_alloc_rx_mem+0x33/0x310 pages=1 vmalloc 0xf821b000-0xf821d000 8192 bnx2_alloc_rx_mem+0x33/0x310 pages=1 vmalloc 0xf8220000-0xf8234000 81920 bnx2_init_board+0x104/0xae0 phys=f6000000 ioremap 0xf8240000-0xf8254000 81920 bnx2_init_board+0x104/0xae0 phys=fa000000 ioremap Any chance bnx2_alloc_rx_mem doesnt use vmalloc() to allocate less than a page of memory ? Thank you [PATCH] bnx2: bnx2_alloc_rx_mem() should ...

Well, here's my other mail on the subject on the tproxy list, it basically details that we do have an implementation of accept() for UDP which we use in production. But I'm not sure that could be integrated to mainline. -<- quote ->- Well, for supporting UDP with tproxy4 we use a different approach: udp_accept(), you can find it in the BalaBit kernel patch tree at http://www.balabit.com/downloads/files/kernel-patches/ The way udp_accept() works is as follows: * the userspace proxy ...

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

From: Alexey Dobriyan <adobriyan@gmail.com> Applied, thanks Alexey. --

From: Brian Haley <brian.haley@hp.com> Looks good, applied, thanks Brian. --

What later options? MTU is 1472. Oh, I had old ethtool.. These with v 6: # ethtool -k eth0 Offload parameters for eth0: rx-checksumming: off tx-checksumming: off scatter-gather: off tcp segmentation offload: off udp fragmentation offload: off generic segmentation offload: on Wow. I turned gso off and now it works just like before. No packets over size of mtu anymore, either. State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB ...

Since a driver and a hardware are later in the queue I doubt you can do this with tcpdump easily without some loop or something... Maybe Packets could be coalesced e.g. by TCP if TSO/GSO is on, but an actual packet sent to the wire should be not more than mtu (15000 if "jumbo" frames etc. are supported). Since you have warnings about this it looks like some of your configs could be different between kernel versions. Your stats from the first message show some differences: class htb ...

For reasons that have been mentioned already here (some hardware can time stamp every packet, new use cases) I think it would be important to have the hwtstamp information right in the skb. I can change the patch series so that it uses one additional ktime_t hwtstamp field; give I'm not a friend of a config option because it was suggested that hardware tstamps should off on *standard* kernels. That's of little use for users of unmodified distributions who want to run PTP. If the feature is ...

Patrick, one question about a new crazy idea: If we would tend to add new space in the skb, won't 4 bytes enough then? A 32 bit value gives a nsec resolution of 4.294967296 seconds or +/- 2.147483648 seconds. If we make a 'full qualified' 64 bit sys-timestamp available anyway, the new 32 bit value could be used as an offest (or it could be given to the userspace directly) to calculate the hw timestamp within the sys-timestamp context, right? Regards, Oliver --

Thank you Dave! Neil --

From: Jesper Dangaard Brouer <jdb@comx.dk> Thanks a lot for making this test Jesper, even though the bug Same signature, counters advancing yet no mark bits are set. Now if we can fix that MSIX BUG() and start analyzing your pps performance with oprofile, we'll be in good shape :) --

------------[ cut here ]------------ WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0x21e/0x230() NETDEV WATCHDOG: eth2 (niu): transmit timed out Modules linked in: niu ipmi_si hpwdt serio_raw bnx2 zlib_inflate rng_core ipmi_msghandler hpilo ehci_hcd uhci_hcd sr_mod cdrom Pid: 0, comm: swapper Not tainted 2.6.28-rc4-davem #17 Call Trace: [<c0125823>] warn_slowpath+0x63/0x80 [<c011f03e>] ? __enqueue_entity+0x8e/0xb0 [<c010888c>] ? native_sched_clock+0x1c/0x80 [<c01453c4>] ? ...

From: Jesper Dangaard Brouer <jdb@comx.dk> Weird. When the module is unloaded, unregister_netdev() will do a dev_close() which will invoke dev->stop() which is niu_close(). And niu_close() will call free_irq() on every MSI interrupt registered in niu_open(). So I can't see how this can happen but obviously it is happening. I suspect that something might be changing np->num_ldg, but anyways the following debugging patch should provide some clues. Please reproduce this and send the logs ...

[PATCH 4/3] rcu: documents rculist_nulls Adds Documentation/RCU/rculist_nulls.txt file to describe how 'nulls' end-of-list can help in some RCU algos. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> --- Documentation/RCU/rculist_nulls.txt | 167 ++++++++++++++++++++++++++ 1 files changed, 167 insertions(+)

Hi all Here is a serie of three patches (based on net-next-2.6), to continue work with RCU on UDP/TCP/DCCP stacks Many thanks for all usefull reviews and comments, especially from Paul and Corey. 1) Introduce hlist_nulls variant of hlist hlist uses NULL value to finish a chain. hlist_nulls variant use the low order bit set to 1 to signal an end marker. This allows to store many different end markers, so that some RCU lockless algos (used in TCP/UDP stack for example) can save ...

It is used for the anonymous vmas. That is the purpose that Hugh introduced it for since he saw regression if he would use straight rcu freeing. See mm/rmap.c. SLAB_DESTROY_BY_RCU a pretty strange way of using RCU and slab so it should always be documented in detail. --

This is a straightforward patch, using hlist_nulls infrastructure. RCUification already done on UDP two weeks ago. Using hlist_nulls permits us to avoid some memory barriers, both at lookup time and delete time. Patch is large because it adds new macros to include/net/sock.h. These macros will be used by TCP & DCCP in next patch. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> --- include/linux/rculist.h | 17 ----------- include/net/sock.h | 57 ...

We have one user, anon_vma, and one thing that is very nearly identical the lockless pagecache. See page_cache_get_speculative() and find_get_page(). The pagecache gets away with this due to the simple fact that the page frames are never freed. Hmm, I once wrote a comment to go with SLAB_DESTROY_BY_RCU, which seems to have gotten lost... /me goes dig. Found it: http://lkml.org/lkml/2008/4/2/143 I guess I'd better re-submit that.. --

So by not using some memory barriers (would be nice to have it illustrated which ones), we can race and end up on the wrong chain, in case that happens we detect this by using this per-chain terminator and try again. It would be really good to have it explained in the rculist_nulls.h comments what memory barriers are missing, what races they open, and how the this special terminator trick closes that race. I'm sure most of us understand it now, but will we still in a few months? - how ...