get_random_bytes() is sometimes called with a hard coded size assumption of an integer. This could not be true for next centuries. This patch replace it with a compile time statement. Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net> --- net/netfilter/nf_conntrack_core.c | 5 +++-- net/netfilter/nf_conntrack_expect.c | 2 +- net/netfilter/xt_hashlimit.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c ...

Table size is defined as unsigned, wheres the table maximum size is defined as a signed integer. The calculation of max is 8 or 4, multiplied the table size. Therefore the max value is aligned to unsigned. Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net> --- include/net/netfilter/nf_conntrack.h | 2 +- net/netfilter/nf_conntrack_core.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/net/netfilter/nf_conntrack.h ...

Hi all, One question about inet_lro.c (linux 2.6.28.6) In lro_proc_segment(), it does not check the number of available frags entries in lro_desc->parent against the number of new fragments to be added before calling lro_add_frags(). Is that a bug? I see that lro_proc_segment() does some type of checking at the end, but could that be too late (i.e. overflow the frags[])?? Also I think some obvious optimization in lro_get_desc() can be done by combining the two for loops ...

If it is interesting for anybody, on loaded proxy server, at beginning: [ 21.587816] netconsole: remote ethernet address 00:04:23:af:02:ca [ 21.591028] console [netcon0] enabled [ 21.591486] netconsole: network logging started [ 23.942232] sd 11:0:0:0: [sda] 1146040320 512-byte hardware sectors: (586 GB/546 GiB) [ 23.943077] sd 11:0:0:0: [sda] Write Protect is off [ 23.943138] sd 11:0:0:0: [sda] Mode Sense: 06 00 10 00 [ 23.943182] sd 11:0:0:0: [sda] Write cache: enabled, read ...

Good point, I'll fix that. Thanks. yi --

On Thu, 19 Feb 2009 12:50:23 -0700 Just do the move from fc_fcoe.h to if_ether.h in one patch. --

This adds implementation of ddp_setup()/ddp_done() in fcoe_sw for its fcoe_sw_libfc_fcn_templ. Signed-off-by: Yi Zou <yi.zou@intel.com> --- drivers/scsi/fcoe/fcoe_sw.c | 37 +++++++++++++++++++++++++++++++++++++ 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/fcoe/fcoe_sw.c b/drivers/scsi/fcoe/fcoe_sw.c index 7632d7e..57f7a51 100644 --- a/drivers/scsi/fcoe/fcoe_sw.c +++ b/drivers/scsi/fcoe/fcoe_sw.c @@ -373,8 +373,45 @@ static int fcoe_sw_destroy(struct ...

This adds eth type ETH_P_FCOE for Fibre Channel over Ethernet (FCoE) Signed-off-by: Yi Zou <yi.zou@intel.com> --- include/linux/if_ether.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h index 7f3c735..59d197c 100644 --- a/include/linux/if_ether.h +++ b/include/linux/if_ether.h @@ -78,6 +78,7 @@ #define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */ #define ETH_P_AOE 0x88A2 /* ATA over ...

The comments in struct net_device_ops says for management hooks, if that's an ok place for net_fcoe_ops, then, I am all for it. Thanks. yi --

Hi, I am working on to support offload for Fiber Channel over Ethernet (FCoE) for the Open-FCoE project maintained at http://www.open-fcoe.org. I would like to propose adding FCoE offload support through the net_device struct as shown in the series of patches followed here. The general idea is to add "struct net_fcoe_ops *fcoe_ops" to net_device, so any network adapter driver that wants to provides FCoE offload can use fcoe_ops through net_device. The following patches touch both netdev and ...

On Thu, 19 Feb 2009 14:19:10 -0600 Well written drivers never return TX_BUSY. They manage the queue such that it is stopped when there is no space and only woken up when there is space. --

the PF_CAN protocol family for the Controller Area Network is available in the kernel since version 2.6.25 but drivers for real CAN devices are still missing. This patch series adds a generic CAN network device driver interface and, as a start, a few drivers. It is the result of the ongoing discussion and development of the Socket-CAN project hosted at the BerliOS web-server (http://developer.berlios.de/projects/socketcan). The patch series consists of the following patches: [PATCH 1/8] can: ...

This patch documents the CAN netowrk device drivers interface, removes obsolete documentation and adds some useful links to CAN resources. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> --- Documentation/networking/can.txt | 214 ++++++++++++++++++++++++++++++------- 1 files changed, 173 insertions(+), 41 deletions(-) diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 2035bc4..d2cc3de ...

This patch adds the generic Socket-CAN driver for the Philips SJA1000 full CAN controller. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> --- drivers/net/can/Kconfig | 11 + drivers/net/can/Makefile | 2 + drivers/net/can/sja1000/Makefile | 7 + drivers/net/can/sja1000/sja1000.c | 681 +++++++++++++++++++++++++++++++++++++ drivers/net/can/sja1000/sja1000.h | 177 ++++++++++ 5 files changed, ...

The patch adds support for the PCI cards: PCIcan and PCIcanx (1, 2 or 4 channel) from Kvaser (http://www.kvaser.com). Signed-off-by: Per Dalen <per.dalen@cnw.se> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> --- drivers/net/can/Kconfig | 7 + drivers/net/can/sja1000/Makefile | 1 + drivers/net/can/sja1000/kvaser_pci.c | 415 ++++++++++++++++++++++++++++++++++ 3 files changed, 423 insertions(+), 0 deletions(-) create mode 100644 ...

This driver adds support for the SJA1000 chips connected to the "platform bus", which can be found on various embedded systems. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> --- drivers/net/can/Kconfig | 10 ++ drivers/net/can/sja1000/Makefile | 1 + ...

On Thu, 19 Feb 2009 12:06:33 +0530 it is possible to see all with ip -6 tunnel show mode all --

Shouldn't you organize the patch series per subsystem, not per old macro? And then Cc the respective maintainers? As it stands, the patches cannot be routed through the normal channels; yet there is no fundamental reason to handle these patches differently from normal patches. -- Stefan Richter -=====-==--= --=- =--== http://arcgraph.de/sr/ --

Traditionally such trivially correct convert-it-all patches lived in -mm and were merged upstream in one go, near the end of the merge window. Sprinkling it into dozens of subsystem channels (some of which are very unreliable) is neither good nor an economic use of our resources. Patches that can potentially cause trouble should go via the usual channels. Ingo --

Replace all DMA_35BIT_MASK micro with DMA_BIT_MASK(35) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- drivers/net/netxen/netxen_nic_main.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c index 8bea4cb..2d4e41b 100644 --- a/drivers/net/netxen/netxen_nic_main.c +++ b/drivers/net/netxen/netxen_nic_main.c @@ -183,8 +183,8 @@ static int nx_set_dma_mask(struct netxen_adapter ...

Will fix,Thank you!~ -- Regards Yang Hongyang --

That's a good idea,Seems it's nessary to keep these old defines. I will resend the patch with s/micro/macro typo fix and keep these old defines,Thanks Ingo!~ -- Regards Yang Hongyang --

Remove defines of DMA_XXBIT_MASK micro Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- include/linux/dma-mapping.h | 20 +------------------- 1 files changed, 1 insertions(+), 19 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index f238c7e..70f9c63 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -13,27 +13,9 @@ enum dma_data_direction { DMA_NONE = 3, }; +/*use DMA_BIT_MASK(n) within your driver instead ...

Replace all DMA_40BIT_MASK micro with DMA_BIT_MASK(40) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- arch/ia64/kernel/pci-dma.c | 2 +- arch/x86/kernel/pci-dma.c | 2 +- drivers/net/bnx2.c | 2 +- drivers/net/enic/enic_main.c | 4 ++-- drivers/net/ipg.c | 2 +- drivers/net/tg3.c | 6 +++--- drivers/scsi/sym53c8xx_2/sym_hipd.h | 2 +- 7 files changed, 10 insertions(+), 10 ...

Replace all DMA_32BIT_MASK micro with DMA_BIT_MASK(32) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- arch/arm/mach-davinci/board-evm.c | 4 +- arch/arm/mach-davinci/usb.c | 4 +- arch/arm/mach-kirkwood/common.c | 2 +- arch/arm/mach-orion5x/common.c | 2 +- arch/arm/plat-iop/adma.c | 2 +- arch/avr32/boards/hammerhead/flash.c | 4 +- arch/avr32/mach-at32ap/at32ap700x.c ...

Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- arch/arm/mach-iop13xx/setup.c | 8 ++++---- arch/arm/mach-iop13xx/tpmi.c | 10 +++++----- arch/arm/mach-kirkwood/common.c | 8 ++++---- arch/arm/mach-orion5x/common.c | 4 ++-- arch/arm/plat-iop/adma.c | 6 +++--- arch/ia64/sn/pci/pci_dma.c | 2 +- ...

Replace all DMA_64BIT_MASK micro with DMA_BIT_MASK(64) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- arch/arm/mach-iop13xx/setup.c | 8 ++++---- arch/arm/mach-iop13xx/tpmi.c | 10 +++++----- arch/arm/mach-kirkwood/common.c | 8 ++++---- arch/arm/mach-orion5x/common.c | 4 ++-- arch/arm/plat-iop/adma.c | 6 +++--- arch/ia64/sn/pci/pci_dma.c | 2 +- ...

Update the old macro DMA_nBIT_MASK related documentations Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- Documentation/DMA-mapping.txt | 18 +++++++++--------- .../sound/alsa/DocBook/writing-an-alsa-driver.tmpl | 8 ++++---- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index b2a4d6d..01f24e9 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt @@ ...

s/micro/macro/ -- "Against stupidity, the gods themselves, contend in vain." --

Replace all DMA_39BIT_MASK micro with DMA_BIT_MASK(39) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- drivers/net/forcedeth.c | 4 ++-- drivers/net/netxen/netxen_nic_main.c | 8 ++++---- drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c index 5b910cf..069d87d 100644 --- a/drivers/net/forcedeth.c +++ b/drivers/net/forcedeth.c @@ -5534,12 ...

Replace all DMA_48BIT_MASK macro with DMA_BIT_MASK(48) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- drivers/net/dl2k.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c index c749e9f..4a1b554 100644 --- a/drivers/net/dl2k.c +++ b/drivers/net/dl2k.c @@ -714,7 +714,7 @@ rio_interrupt (int irq, void *dev_instance) static inline dma_addr_t desc_to_dma(struct netdev_desc *desc) { - return ...

Looks good beyond the s/micro/macro typo fix, but i'd suggest to keep these old defines for one more kernel cycle, then do a final removal of all remaining uses, in a single patch. That way we'll save ourselves from quite a bit of unnecessary build breakages (as your patchset shows there's still a lot of users of the old macros), as these definitions get moved around, reintroduced, etc. Conflict resolution becomes easier as well - if such a patch conflicts with some ongoing work ...

Replace all DMA_39BIT_MASK macro with DMA_BIT_MASK(39) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- drivers/net/forcedeth.c | 4 ++-- drivers/net/netxen/netxen_nic_main.c | 8 ++++---- drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c index 5b910cf..069d87d 100644 --- a/drivers/net/forcedeth.c +++ b/drivers/net/forcedeth.c @@ -5534,12 ...

Replace all DMA_40BIT_MASK macro with DMA_BIT_MASK(40) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> --- arch/ia64/kernel/pci-dma.c | 2 +- arch/x86/kernel/pci-dma.c | 2 +- drivers/net/bnx2.c | 2 +- drivers/net/enic/enic_main.c | 4 ++-- drivers/net/ipg.c | 2 +- drivers/net/tg3.c | 6 +++--- drivers/scsi/sym53c8xx_2/sym_hipd.h | 2 +- 7 files changed, 10 insertions(+), 10 ...

From: Constantin Baranov <baranov@mercdev.com> 10g copper cards pretty much don't exist, which is probably why nobody has hit this problem :-) Patch applied, thanks. --

On Thu, 19 Feb 2009 02:03:40 +0500 There are patches in Vyatta version of Quagga to what you want. They have been submitted to quagga-developers but the community process on quagga is much slower than the kernel. --

The target is to get GRO into 2.6.30, and have all LRO drivers I'd like to see more performance data on the forwarding side. The act of aggregation isn't exactly free so it very much depends on what you're forwarding. The driver for all this work is bridging used for virtualisation If packet length changes due to NAT then we're no loner bound by the end-to-end restriction so we can do whatever we want. For GRO we treat it in exactly the same way as a GSO packet that undergoes NAT. ...

> - ep->mpa_attr.crc_enabled = (mpa->flags & MPA_CRC) | crc_enabled ? 1 : 0; > + ep->mpa_attr.crc_enabled = (mpa->flags & MPA_CRC) || crc_enabled ? 1 : 0; > - ep->mpa_attr.crc_enabled = (mpa->flags & MPA_CRC) | crc_enabled ? 1 : 0; > + ep->mpa_attr.crc_enabled = (mpa->flags & MPA_CRC) || crc_enabled ? 1 : 0; So as I said before, I guess this change is fine, except: add/remove: 0/0 grow/shrink: 1/0 up/down: 18/0 (18) function old new ...

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Applied, thanks. --

From: Krishna Kumar <krikku@gmail.com> Applied to net-next-2.6, thank you! --

Do you folks need/want further testing against the 32-core setup? --

TCP connection tracking suffers of huge contention on a global rwlock, used to protect tcp conntracking state. As each tcp conntrack state have no relations between each others, we can switch to fine grained lock, using a spinlock per "struct ip_ct_tcp" tcp_print_conntrack() dont need to lock anything to read ct->proto.tcp.state, so speedup /proc/net/ip_conntrack as well. In this version the lock is placed in a 4 byte whole in the nf_conntrack structure. This means no size change, and same ...

so we can deal with 85xx as well. We just need to isolate the 83xx specific bits (message usage) - k --

You should be able to build a kernel with support for both host and guest operation, and then use the device tree to switch which driver you get. The host driver won't be used without a PCI bus, and the guest I looked at the cardnet driver before I implemented my PCINet driver. I hunch it would be rejected for the same reasons, but maybe not. Also, it makes no use of DMA, which is critical for good transfer speed. Using memcpy() in PCINet gives performance around 10 mbit/sec, which ...

I suppose we need to build the kernel twice. one for vop_host (on host with pci enabled) and the other is for vop_fsl ( on agent with pci disabled). Is it possible to build one image for both host and agent. We do not scan the pci bus if the controller is configured to agent. Also, is it possible to include mpc85xx architecture? They should be same. There is some code for 85xx in Fresscale ...

Yes, module load error, but not a build error. The build with CONFIG_IPV6 is fine, and bonding loads fine as long as ipv6 is loaded. The issue arises when the ipv6 module is prevented from loading; in that case, bonding cannot load because it now requires functionality from ipv6. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com --

Is that what people really want to block? Or do they want to prevent the use of IPv6 in environments where IPv6 is not supported? If it's this case, then simply not configuring any IPv6 addresses on the system interfaces will make it seem as if IPv6 is not there. Without IPv6 addresses, AF_INET6 sockets are the same as AF_INET. I really see no reason to block them. Any legacy apps that people might worry about don't use this type socket any way. One doesn't even need to worry about ...

Yes, this is run-time error. If IPV6 is disabled during kernel build,=20 everything works; but the error was seen on distribution kernel which=20 includes IPV6.

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Applied, thanks everyone. --

From: Wei Yongjun <yjwei@cn.fujitsu.com> Roel Kluin already posted a fix for this, thank you. --

Acked-by: Lennert Buytenhek <buytenh@marvell.com> --

I guess you need to use ebtables dnat for this yet. Cheers, Jarek P. --

Hi Dave, Applying it against net-2.6 is all good. Cheers, Divy --

From: Lennert Buytenhek <buytenh@wantstofly.org> Applied. --

From: Hannes Eder <hannes@hanneseder.net> Applied, thanks. --

Hi David, Sorry for being slow with responding to this. I tried a routing test on an ARM board that uses mv643xx_eth on an almost vanilla (some arch/arm changes) 2.6.29-rc3 for each of these three cases: 1. LRO disabled in Kconfig 2. LRO enabled in Kconfig, !NETIF_F_LRO 3. LRO enabled in Kconfig, NETIF_F_LRO I'm injecting 300kpps on one interface (lan1), and routing the packets to another interface (lan2). lan[1234] are virtual (DSA) netdevs that are tagged over eth0. I'm reading sw ...

On 18-02-2009 22:05, Jarek Poplawski wrote: ...And the first step could be trying skb_copy() in the driver's ->hard_start_xmit() callback (of course, if you prefer data safety over perfomance). Jarek P. --

From: "Matt Carlson" <mcarlson@broadcom.com> Applied. --

On Mon, 9 Feb 2009 17:02:48 -0800 Similar fix just applied --

Applied, thanks. --

ip6_tables netfilter module can use an ifname_compare() helper so that two loops are unfolded. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> --- net/ipv6/netfilter/ip6_tables.c | 33 +++++++++++++++++++----------- 1 files changed, 21 insertions(+), 12 deletions(-) diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c index a33485d..d64594b 100644 --- a/net/ipv6/netfilter/ip6_tables.c +++ b/net/ipv6/netfilter/ip6_tables.c @@ -89,6 +89,25 @@ ip6t_ext_hdr(u8 ...