NOTE: dropped dmfe change, would cause regression noted by Meelis Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: drivers/net/forcedeth.c | 5 ++--- drivers/net/phy/marvell.c | 2 -- drivers/net/tokenring/olympic.c | 6 +++--- 3 files changed, 5 insertions(+), 8 deletions(-) Adrian Bunk (1): net/tokenring/olympic.c section fixes Al Viro (1): ...

All, From kernel 2.6.26 onward all *PCI Express* device IDs previously supported by e1000 will be moving to the e1000e driver. This includes ich8 and ich9 onboard LAN, server 5000 platform onboard LAN (es2) and 82571/2/3 chipset based adapters and variants. If you have not already enabled CONFIG_E1000E make sure that you do so. You can already do this with 2.6.25. From 2.6.26 on this change will be required if you have such a device. It is also worthwhile to note you will have to update yo...

That's not pretty for embedded folks who don't want an extra driver to come along for the ride ;-) It's also been suggested, as an alternative, to add 'select E1000E' to E1000's Kconfig entry. Rather than doing that, I am hoping that education -- Auke's announcements -- plus "ripping the band-aid off quickly", will be the best approach. Most kernel distributions will have enabled both Kconfig options anyway, so that leaves individual kernel hackers who missed the announcements as the ...

This patch eliminates the "port" pointer in the TIPC socket object by storing this info in the (previously unused) sk_user_data field of the standard sock structure. Signed-off-by: Allan Stephens <allan.stephens@windriver.com> --- net/tipc/socket.c | 129 ++++++++++++++++++++++++++++++---------------------- 1 files changed, 74 insertions(+), 55 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index 1b5fb61..4ad1807 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c ...

This patch eliminates re-initialization of the standard socket wait queue used for sleeping in TIPC's socket creation code. Signed-off-by: Allan Stephens <allan.stephens@windriver.com> --- net/tipc/socket.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index 4ad1807..64be71a 100644 --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -170,7 +170,6 @@ static int tipc_create(struct net *net, struct socket *sock, int protocol) ...

Hi, I noticed these warning on my randconfig logs of some builds : .. drivers/usb/core/hcd.c: In function 'usb_hcd_poll_rh_status': include/asm/string_32.h:65: warning: array subscript is above array bounds net/netfilter/nf_conntrack_proto_sctp.c: In function 'sctp_packet': net/netfilter/nf_conntrack_proto_sctp...

I cannot do that right now but I'll build SVN 4.3 tomorrow and report back. Gabriel --

Yes, that looks like a problem in the core netlink code. git-net contains several largeish changes to it.. --

First call to ctrl_dumpfamily() is coming directly from the message processing context where genl_lock is already held. Subsequence calls come from netlink_recvmsg() so we have to take the lock separately. However, I just noticed the condition should really be chains_to_skip != 0 || fams_to_skip != 0 --

The void calls are even simpler. Plus ~18 more patches and all the ops will be moved on the net_device_ops and it will be possible to start converting device drivers... So, what is your opinion about all this? Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- net/core/dev.c | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index a01c078..3428534 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3644,8 +...

And fill it with copied from net_device. Also make newly created devices be assigned to the (currently empty) nd_default_ops. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- include/linux/netdevice.h | 39 +++++++++++++++++++++++++++++++++++++++ net/core/dev.c | 9 +++++++++ 2 files changed, 48 insertions(+), 0 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 8b17ed4..33f00ff 100644 --- a/include/linux/netdevice.h +++ b/in...

It might make sense to keep hard_start_xmit and hard_header in struct net_device since VLAN and Bonding overload them. --

This file contains modifications against kernel source code needed to use TOMOYO Linux 1.6. Although LSM hooks are provided for performing access control, TOMOYO Linux 1.6 doesn't use LSM because of the following reasons. Reason 1: CONFIG_SECURITY=y adds security fields to various structures and introduces hooks for allocating/freeing these security fields. But TOMOYO Linux can hardly utilize them. TOMOYO Linux requires modification against only "struct task_struct", and adding two variable...

These functions checks whether TOMOYO can do permission checks or not. TOMOYO won't do permission checks if the process is a kernel thread or the process is not permitted to sleep. Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp> Cc: linux-netdev <netdev@vger.kernel.org> --- include/linux/tomoyo_socket.h | 419 ++++++++++++++++++++++++++++++++++...

Thanks Patrick, Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> --

Well spotted, yes, those can now be safely removed, since we don't touch the initial inet6?_skb_parm area it will remain as zeros (alloc_skb did that for us) and we don't have to zero it anymore before passing it to IP. --

Hi, This patch moves IPVS from net/ipv4/ipvs to net/netfilter/ipvs, as discussed earlier with Horms and Patrick McHardy. This is done as a preparation for later adding IPv6 functionality to IPVS. The patch is 600kb, so I uploaded it here: http://www-user.tu-chemnitz.de/~volz/move_ipvs_to_netfilter.patch -------------------------- Description: Move IPVS from net/ipv4/ipvs to net/netfilter/ipvs as a preparation for adding IPv6 support to IPVS later on. Signed-off-by: Julius R. Volz <juliu...

I was thinking about that. I got as far as writing a simple patch to printk so that it would not start to trigger until it gets a 2nd event within 'n' jiffies of the first. But actually developers do sometimes want see the event even if it is relatively infrequent... --

These entries are allocated in vlan_dev_set_egress_priority, but are never released and leaks on vlan device removal. Drop these in vlan's ->uninit callback - after the device is brought down and everyone is notified about it is going to be unregistered. Found during testing vlan netnsization patchset. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c index 480ea90..41a76a0 100644 --- a/net/8021q/vlan_dev.c +++ b/ne...

From: Patrick McHardy <kaber@trash.net> Applied, thanks a lot. --

Maybe this tulip_core.c code needs to be applied to dmfe.c? if (tulip_uli_dm_quirk(pdev)) { csr0 &= ~0x01f100ff; #if defined(CONFIG_SPARC) csr0 = (csr0 & ~0xff00) | 0xe000; #endif } A zeroed MAC address leads me to believe that dmfe's SROM parsing isn't quite as capable as tulip's, though that's just a guess. Just checked dmfe with sparse and it reports clean, though looking at the code it could use some cleanups. Jeff ...

I didn't see that, no... thanks for poking me. Jeff --

I will have another batch to send in the next day or so, including a notable forcedeth fix. Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: drivers/net/forcedeth.c | 5 ++--- drivers/net/phy/marvell.c | 2 -- drivers/net/tokenring/olympic.c | 6 +++--- drivers/net/tulip/tulip_core.c | 1 - 4 files changed, 5 insertions(+), 9 deletions(-) Adrian Bunk (1...

I was looking at some dfme vs tulip google search. How the id removal accord to this debian bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400837 Looking at dmfe history on git, it is not clearly stated this problem has been fixed. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=history;f=driver... Gilles --

Unless you're sending very fast, where the computational overhead of processing SACK blocks is slowing you down, this is not expected behavior. Do you have more detail? What is the window size, and how much reordering? Full binary tcpdumps are very useful in diagnosing this type of problem. -John --