* [PATCH] [POWERPC] iSeries: fix section mismatch in iseries_veth
From: Stephen Rothwell @ 2008-02-05 3:19 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Jeff Garzik, netdev
WARNING: vmlinux.o(.text+0x25dca0): Section mismatch in reference from the function .veth_probe() to the function .init.text:.veth_probe_one()
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/iseries_veth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jeff, can this go in through the powerpc tree?
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index 419861c..58d3bb6 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -1020,7 +1020,7 @@ static const struct ethtool_ops ops = {
.get_link = veth_get_link,
};
-static struct net_device * __init veth_probe_one(int vlan,
+static struct net_device *veth_probe_one(int vlan,
struct vio_dev *vio_dev)
{
struct net_device *dev;
--
1.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] sky2: fix for Yukon FE (regression in 2.6.25)
From: Stephen Hemminger @ 2008-02-05 3:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Petr Vandrovec, netdev
In-Reply-To: <47A51168.5040301@vandrovec.name>
The Yukon FE chip has a ram buffer therefore it needs the alignment
restriction and hang check workarounds.
Therefore:
* Autodetect the prescence/absence of ram buffer
* Rename the flag value to reflect this
* Use it consistently (ie don't reread register)
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2008-02-03 10:20:43.000000000 -0800
+++ b/drivers/net/sky2.c 2008-02-03 10:32:25.000000000 -0800
@@ -855,7 +855,7 @@ static void sky2_mac_init(struct sky2_hw
sky2_write16(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_OPER_ON);
/* On chips without ram buffer, pause is controled by MAC level */
- if (sky2_read8(hw, B2_E_0) == 0) {
+ if (!(hw->flags & SKY2_HW_RAM_BUFFER)) {
sky2_write8(hw, SK_REG(port, RX_GMF_LP_THR), 768/8);
sky2_write8(hw, SK_REG(port, RX_GMF_UP_THR), 1024/8);
@@ -1192,7 +1192,7 @@ static struct sk_buff *sky2_rx_alloc(str
struct sk_buff *skb;
int i;
- if (sky2->hw->flags & SKY2_HW_FIFO_HANG_CHECK) {
+ if (sky2->hw->flags & SKY2_HW_RAM_BUFFER) {
unsigned char *start;
/*
* Workaround for a bug in FIFO that cause hang
@@ -1385,6 +1385,7 @@ static int sky2_up(struct net_device *de
if (ramsize > 0) {
u32 rxspace;
+ hw->flags |= SKY2_HW_RAM_BUFFER;
pr_debug(PFX "%s: ram buffer %dK\n", dev->name, ramsize);
if (ramsize < 16)
rxspace = ramsize / 2;
@@ -2023,7 +2024,7 @@ static int sky2_change_mtu(struct net_de
synchronize_irq(hw->pdev->irq);
- if (sky2_read8(hw, B2_E_0) == 0)
+ if (!(hw->flags & SKY2_HW_RAM_BUFFER))
sky2_set_tx_stfwd(hw, port);
ctl = gma_read16(hw, port, GM_GP_CTRL);
@@ -2559,7 +2560,7 @@ static void sky2_watchdog(unsigned long
++active;
/* For chips with Rx FIFO, check if stuck */
- if ((hw->flags & SKY2_HW_FIFO_HANG_CHECK) &&
+ if ((hw->flags & SKY2_HW_RAM_BUFFER) &&
sky2_rx_hung(dev)) {
pr_info(PFX "%s: receiver hang detected\n",
dev->name);
@@ -2715,11 +2716,7 @@ static int __devinit sky2_init(struct sk
switch(hw->chip_id) {
case CHIP_ID_YUKON_XL:
- hw->flags = SKY2_HW_GIGABIT
- | SKY2_HW_NEWER_PHY;
- if (hw->chip_rev < 3)
- hw->flags |= SKY2_HW_FIFO_HANG_CHECK;
-
+ hw->flags = SKY2_HW_GIGABIT | SKY2_HW_NEWER_PHY;
break;
case CHIP_ID_YUKON_EC_U:
@@ -2745,7 +2742,7 @@ static int __devinit sky2_init(struct sk
dev_err(&hw->pdev->dev, "unsupported revision Yukon-EC rev A1\n");
return -EOPNOTSUPP;
}
- hw->flags = SKY2_HW_GIGABIT | SKY2_HW_FIFO_HANG_CHECK;
+ hw->flags = SKY2_HW_GIGABIT;
break;
case CHIP_ID_YUKON_FE:
--- a/drivers/net/sky2.h 2008-02-03 10:20:43.000000000 -0800
+++ b/drivers/net/sky2.h 2008-02-03 10:26:45.000000000 -0800
@@ -2045,7 +2045,7 @@ struct sky2_hw {
#define SKY2_HW_FIBRE_PHY 0x00000002
#define SKY2_HW_GIGABIT 0x00000004
#define SKY2_HW_NEWER_PHY 0x00000008
-#define SKY2_HW_FIFO_HANG_CHECK 0x00000010
+#define SKY2_HW_RAM_BUFFER 0x00000010
#define SKY2_HW_NEW_LE 0x00000020 /* new LSOv2 format */
#define SKY2_HW_AUTO_TX_SUM 0x00000040 /* new IP decode for Tx */
#define SKY2_HW_ADV_POWER_CTL 0x00000080 /* additional PHY power regs */
^ permalink raw reply
* Re: [PATCH] 2.6.24-mm1 section type conflict cleanup
From: Kamalesh Babulal @ 2008-02-05 4:49 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Andrew Morton, linux-kernel, netdev, apw, balbir
In-Reply-To: <20080204180454.GA16050@uranus.ravnborg.org>
Sam Ravnborg wrote:
> On Mon, Feb 04, 2008 at 09:52:23PM +0530, Kamalesh Babulal wrote:
>> Hi Andrew,
>>
>> The 2.6.24-mm1 kernel build fails at many places with section type
>> conflict build error.
>
> What arch?
> We have troubles with powerpc as pointed out by Al in another thread.
>
> Sam
Hi Sam,
This clean up is done for the powerpc, sorry forgot to mention it.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: 2.6.24-mm1 - Build failure at net/sched/cls_flow.c:598
From: Rami Rosen @ 2008-02-05 7:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tilman Schmidt, linux-kernel, Patrick McHardy, netdev
In-Reply-To: <20080204152505.62b2b8b5.akpm@linux-foundation.org>
Hello,
I had sent a patch recently (which is currently pending) which
solves this problem.
see:
http://www.spinics.net/lists/netdev/msg54455.html
Regards,
Rami Rosen
On Feb 5, 2008 1:25 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 04 Feb 2008 23:32:49 +0100
> Tilman Schmidt <tilman@imap.cc> wrote:
>
> > My attempt to build this failed with:
> >
> > CC [M] net/sched/cls_flow.o
> > net/sched/cls_flow.c: In function ___flow_dump___:
> > net/sched/cls_flow.c:598: error: ___struct tcf_ematch_tree___ has no member named ___hdr___
> >
> > Config attached.
>
> Thanks. hm.
>
> #else /* CONFIG_NET_EMATCH */
>
> struct tcf_ematch_tree
> {
> };
>
> methinks Patrick has a CONFIG_NET_EMATCH=n problem?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [patch 2/2] tun: impossible to deassert IFF_ONE_QUEUE or IFF_NO_PI
From: akpm @ 2008-02-05 7:45 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, nwfilardo, jeff, maxk
From: "Nathaniel Filardo" <nwfilardo@gmail.com>
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=9806
The TUN/TAP driver only permits one-way transitions of IFF_NO_PI or
IFF_ONE_QUEUE during the lifetime of a tap/tun interface. Note that
tun_set_iff contains
541 if (ifr->ifr_flags & IFF_NO_PI)
542 tun->flags |= TUN_NO_PI;
543
544 if (ifr->ifr_flags & IFF_ONE_QUEUE)
545 tun->flags |= TUN_ONE_QUEUE;
This is easily fixed by adding else branches which clear these bits.
Steps to reproduce:
This is easily reproduced by setting an interface persistant using tunctl then
attempting to open it as IFF_TAP or IFF_TUN, without asserting the IFF_NO_PI
flag. The ioctl() will succeed and the ifr.flags word is not modified, but the
interface remains in IFF_NO_PI mode (as it was set by tunctl).
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jeff@garzik.org>
Acked-by: Maxim Krasnyansky <maxk@qualcomm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/tun.c | 4 ++++
1 file changed, 4 insertions(+)
diff -puN drivers/net/tun.c~tun-dev-impossible-to-deassert-iff_one_queue-or-iff_no_pi drivers/net/tun.c
--- a/drivers/net/tun.c~tun-dev-impossible-to-deassert-iff_one_queue-or-iff_no_pi
+++ a/drivers/net/tun.c
@@ -529,9 +529,13 @@ static int tun_set_iff(struct file *file
if (ifr->ifr_flags & IFF_NO_PI)
tun->flags |= TUN_NO_PI;
+ else
+ tun->flags &= ~TUN_NO_PI;
if (ifr->ifr_flags & IFF_ONE_QUEUE)
tun->flags |= TUN_ONE_QUEUE;
+ else
+ tun->flags &= ~TUN_ONE_QUEUE;
file->private_data = tun;
tun->attached = 1;
_
^ permalink raw reply
* [patch 1/2] hamradio: fix dmascc section mismatch
From: akpm @ 2008-02-05 7:45 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, randy.dunlap, klaus.kudielka, sam
From: Randy Dunlap <randy.dunlap@oracle.com>
hw[] is used in both init and exit functions so it cannot be initdata (section
mismatch is when CONFIG_MODULES=n and CONFIG_DMASCC=y).
WARNING: vmlinux.o(.exit.text+0xba7): Section mismatch: reference to .init.data: (between 'dmascc_exit' and 'sixpack_exit_driver')
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Klaus Kudielka <klaus.kudielka@gmx.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/hamradio/dmascc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/net/hamradio/dmascc.c~hamradio-fix-dmascc-section-mismatch drivers/net/hamradio/dmascc.c
--- a/drivers/net/hamradio/dmascc.c~hamradio-fix-dmascc-section-mismatch
+++ a/drivers/net/hamradio/dmascc.c
@@ -262,8 +262,8 @@ static void tm_isr(struct scc_priv *priv
static int io[MAX_NUM_DEVS] __initdata = { 0, };
-/* Beware! hw[] is also used in cleanup_module(). */
-static struct scc_hardware hw[NUM_TYPES] __initdata_or_module = HARDWARE;
+/* Beware! hw[] is also used in dmascc_exit(). */
+static struct scc_hardware hw[NUM_TYPES] = HARDWARE;
/* Global variables */
_
^ permalink raw reply
* [patch 1/4] forcedeth: power down phy when interface is down
From: akpm @ 2008-02-05 7:47 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, eswierk, aabdulla
From: "Ed Swierk" <eswierk@arastra.com>
Bring the physical link down when the interface is down by placing the PHY
in power-down state, unless WOL is enabled. This mirrors the behavior of
other drivers including e1000 and tg3.
Without the patch, ifconfig down leaves the physical link up, which confuses
datacenter users who expect the link lights both on the NIC and the switch to
go out when they bring an interface down.
Furthermore, even though the phy is powered on, autonegotiation stops working,
so a normally gigabit link might suddenly become 100 Mbit half-duplex when the
interface goes down, and become gigabit when it comes up again.
Ayaz said:
I would not include this patch until further testing is performed. NVIDIA
MCP chips use 3rd party PHY vendors. By powering down the phy, it could
have adverse affects on certain phys.
Signed-off-by: Ed Swierk <eswierk@arastra.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/forcedeth.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff -puN drivers/net/forcedeth.c~forcedeth-power-down-phy-when-interface-is-down drivers/net/forcedeth.c
--- a/drivers/net/forcedeth.c~forcedeth-power-down-phy-when-interface-is-down
+++ a/drivers/net/forcedeth.c
@@ -1324,9 +1324,9 @@ static int phy_init(struct net_device *d
/* some phys clear out pause advertisment on reset, set it back */
mii_rw(dev, np->phyaddr, MII_ADVERTISE, reg);
- /* restart auto negotiation */
+ /* restart auto negotiation, power down phy */
mii_control = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ);
- mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE);
+ mii_control |= (BMCR_ANRESTART | BMCR_ANENABLE | BMCR_PDOWN);
if (mii_rw(dev, np->phyaddr, MII_BMCR, mii_control)) {
return PHY_ERROR;
}
@@ -4803,6 +4803,10 @@ static int nv_open(struct net_device *de
dprintk(KERN_DEBUG "nv_open: begin\n");
+ /* power up phy */
+ mii_rw(dev, np->phyaddr, MII_BMCR,
+ mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ) & ~BMCR_PDOWN);
+
/* erase previous misconfiguration */
if (np->driver_data & DEV_HAS_POWER_CNTRL)
nv_mac_reset(dev);
@@ -4985,6 +4989,10 @@ static int nv_close(struct net_device *d
if (np->wolenabled) {
writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags);
nv_start_rx(dev);
+ } else {
+ /* power down phy */
+ mii_rw(dev, np->phyaddr, MII_BMCR,
+ mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ)|BMCR_PDOWN);
}
/* FIXME: power down nic */
_
^ permalink raw reply
* [patch 4/4] drivers/net/tlan.c: compilation warning fix
From: akpm @ 2008-02-05 7:47 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, lpotenza
From: Leonardo Potenza <lpotenza@inwind.it>
Add a check for the pci_register_driver() return value. Removed unused
variable pad_allocated.
The aim of this patch is to remove the following warning messages:
drivers/net/tlan.c: In function 'tlan_probe':
drivers/net/tlan.c:486: warning: ignoring return value of 'pci_register_driver', declared with attribute warn_unused_result
Signed-off-by: Leonardo Potenza <lpotenza@inwind.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/tlan.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff -puN drivers/net/tlan.c~drivers-net-tlanc-compilation-warning-fix drivers/net/tlan.c
--- a/drivers/net/tlan.c~drivers-net-tlanc-compilation-warning-fix
+++ a/drivers/net/tlan.c
@@ -465,7 +465,7 @@ static struct pci_driver tlan_driver = {
static int __init tlan_probe(void)
{
- static int pad_allocated;
+ int rc = -ENODEV;
printk(KERN_INFO "%s", tlan_banner);
@@ -473,17 +473,22 @@ static int __init tlan_probe(void)
if (TLanPadBuffer == NULL) {
printk(KERN_ERR "TLAN: Could not allocate memory for pad buffer.\n");
- return -ENOMEM;
+ rc = -ENOMEM;
+ goto err_out;
}
memset(TLanPadBuffer, 0, TLAN_MIN_FRAME_SIZE);
- pad_allocated = 1;
TLAN_DBG(TLAN_DEBUG_PROBE, "Starting PCI Probe....\n");
/* Use new style PCI probing. Now the kernel will
do most of this for us */
- pci_register_driver(&tlan_driver);
+ rc = pci_register_driver(&tlan_driver);
+
+ if (rc != 0) {
+ printk(KERN_ERR "TLAN: Could not register pci driver.\n");
+ goto err_out_pci_free;
+ }
TLAN_DBG(TLAN_DEBUG_PROBE, "Starting EISA Probe....\n");
TLan_EisaProbe();
@@ -493,11 +498,17 @@ static int __init tlan_probe(void)
tlan_have_pci, tlan_have_eisa);
if (TLanDevicesInstalled == 0) {
- pci_unregister_driver(&tlan_driver);
- pci_free_consistent(NULL, TLAN_MIN_FRAME_SIZE, TLanPadBuffer, TLanPadBufferDMA);
- return -ENODEV;
+ rc = -ENODEV;
+ goto err_out_pci_unreg;
}
return 0;
+
+err_out_pci_unreg:
+ pci_unregister_driver(&tlan_driver);
+err_out_pci_free:
+ pci_free_consistent(NULL, TLAN_MIN_FRAME_SIZE, TLanPadBuffer, TLanPadBufferDMA);
+err_out:
+ return rc;
}
_
^ permalink raw reply
* [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: akpm @ 2008-02-05 7:47 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, michael.pyne, AAbdulla, aabdulla, stable
From: Michael Pyne <michael.pyne@kdemail.net>
Partially revert a change to mac address detection introduced to the forcedeth
driver. The change was intended to correct mac address detection for newer
nVidia chipsets where the mac address was stored in reverse order. One of
those chipsets appears to still have the mac address in reverse order (or at
least, it does on my system).
The change that broke mac address detection for my card was commit
ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
My network card is an nVidia built-in Ethernet card, output from lspci as
follows (with text and numeric ids):
$ lspci | grep Ethernet
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
$ lspci -n | grep 07.0
00:07.0 0680: 10de:03ef (rev a2)
The vendor id is, of course, nVidia. The device id corresponds to the
NVIDIA_NVENET_19 entry.
The included patch fixes the MAC address detection on my system.
Interestingly, the MAC address appears to be in the range reserved for my
motherboard manufacturer (Gigabyte) and not nVidia.
Signed-off-by: Michael J. Pyne <michael.pyne@kdemail.net>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: <stable@kernel.org>
On Wed, 21 Nov 2007 15:34:52 -0800
"Ayaz Abdulla" <AAbdulla@nvidia.com> wrote:
> The solution is to get the OEM to update their BIOS (instead of
> integrating this patch) since the MCP61 specs indicate that the MAC
> Address should be in correct order from BIOS.
>
> By changing the feature DEV_HAS_CORRECT_MACADDR to all MCP61 boards, it
> could cause it to break on other OEM systems who have implemented it
> correctly.
>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/forcedeth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/forcedeth.c~forcedeth-fix-mac-address-detection-on-network-card-regression-in-2623 drivers/net/forcedeth.c
--- a/drivers/net/forcedeth.c~forcedeth-fix-mac-address-detection-on-network-card-regression-in-2623
+++ a/drivers/net/forcedeth.c
@@ -5554,7 +5554,7 @@ static struct pci_device_id pci_tbl[] =
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_19),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_20),
_
^ permalink raw reply
* [patch 3/4] mv643xx_eth: fix byte order when checksum offload is enabled
From: akpm @ 2008-02-05 7:47 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, byron.bbradley, dale, mlachwani, viro
From: Byron Bradley <byron.bbradley@gmail.com>
The Marvell Orion system on chips have an integrated mv643xx MAC. On these
little endian ARM devices mv643xx will oops when checksum offload is
enabled. Swapping the byte order of the protocol and checksum solves this
problem.
Signed-off-by: Byron Bradley <byron.bbradley@gmail.com>
Cc: Dale Farnsworth <dale@farnsworth.org>
Cc: Manish Lachwani <mlachwani@mvista.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/mv643xx_eth.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff -puN drivers/net/mv643xx_eth.c~mv643xx_eth-fix-byte-order-when-checksum-offload-is-enabled drivers/net/mv643xx_eth.c
--- a/drivers/net/mv643xx_eth.c~mv643xx_eth-fix-byte-order-when-checksum-offload-is-enabled
+++ a/drivers/net/mv643xx_eth.c
@@ -1652,6 +1652,11 @@ static void eth_tx_fill_frag_descs(struc
}
}
+static inline __be16 sum16_as_be(__sum16 sum)
+{
+ return (__force __be16)sum;
+}
+
/**
* eth_tx_submit_descs_for_skb - submit data from an skb to the tx hw
*
@@ -1689,7 +1694,7 @@ static void eth_tx_submit_descs_for_skb(
desc->buf_ptr = dma_map_single(NULL, skb->data, length, DMA_TO_DEVICE);
if (skb->ip_summed == CHECKSUM_PARTIAL) {
- BUG_ON(skb->protocol != ETH_P_IP);
+ BUG_ON(skb->protocol != htons(ETH_P_IP));
cmd_sts |= ETH_GEN_TCP_UDP_CHECKSUM |
ETH_GEN_IP_V_4_CHECKSUM |
@@ -1698,10 +1703,10 @@ static void eth_tx_submit_descs_for_skb(
switch (ip_hdr(skb)->protocol) {
case IPPROTO_UDP:
cmd_sts |= ETH_UDP_FRAME;
- desc->l4i_chk = udp_hdr(skb)->check;
+ desc->l4i_chk = ntohs(sum16_as_be(udp_hdr(skb)->check));
break;
case IPPROTO_TCP:
- desc->l4i_chk = tcp_hdr(skb)->check;
+ desc->l4i_chk = ntohs(sum16_as_be(tcp_hdr(skb)->check));
break;
default:
BUG();
_
^ permalink raw reply
* [patch 2/7] bluetooth: uninlining
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm
From: Andrew Morton <akpm@linux-foundation.org>
Remove all those inlines which were either a) unneeded or b) increased code
size.
text data bss dec hex filename
before: 6997 74 8 7079 1ba7 net/bluetooth/hidp/core.o
after: 6492 74 8 6574 19ae net/bluetooth/hidp/core.o
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/hidp/core.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff -puN net/bluetooth/hidp/core.c~bluetooth-uninlining net/bluetooth/hidp/core.c
--- a/net/bluetooth/hidp/core.c~bluetooth-uninlining
+++ a/net/bluetooth/hidp/core.c
@@ -135,8 +135,8 @@ static void __hidp_copy_session(struct h
}
}
-static inline int hidp_queue_event(struct hidp_session *session, struct input_dev *dev,
- unsigned int type, unsigned int code, int value)
+static int hidp_queue_event(struct hidp_session *session, struct input_dev *dev,
+ unsigned int type, unsigned int code, int value)
{
unsigned char newleds;
struct sk_buff *skb;
@@ -243,7 +243,8 @@ static void hidp_input_report(struct hid
input_sync(dev);
}
-static inline int hidp_queue_report(struct hidp_session *session, unsigned char *data, int size)
+static int hidp_queue_report(struct hidp_session *session,
+ unsigned char *data, int size)
{
struct sk_buff *skb;
@@ -287,7 +288,7 @@ static void hidp_idle_timeout(unsigned l
hidp_schedule(session);
}
-static inline void hidp_set_timer(struct hidp_session *session)
+static void hidp_set_timer(struct hidp_session *session)
{
if (session->idle_to > 0)
mod_timer(&session->timer, jiffies + HZ * session->idle_to);
@@ -332,7 +333,8 @@ static inline int hidp_send_ctrl_message
return err;
}
-static inline void hidp_process_handshake(struct hidp_session *session, unsigned char param)
+static void hidp_process_handshake(struct hidp_session *session,
+ unsigned char param)
{
BT_DBG("session %p param 0x%02x", session, param);
@@ -365,7 +367,8 @@ static inline void hidp_process_handshak
}
}
-static inline void hidp_process_hid_control(struct hidp_session *session, unsigned char param)
+static void hidp_process_hid_control(struct hidp_session *session,
+ unsigned char param)
{
BT_DBG("session %p param 0x%02x", session, param);
@@ -379,7 +382,8 @@ static inline void hidp_process_hid_cont
}
}
-static inline void hidp_process_data(struct hidp_session *session, struct sk_buff *skb, unsigned char param)
+static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
+ unsigned char param)
{
BT_DBG("session %p skb %p len %d param 0x%02x", session, skb, skb->len, param);
@@ -406,7 +410,8 @@ static inline void hidp_process_data(str
}
}
-static inline void hidp_recv_ctrl_frame(struct hidp_session *session, struct sk_buff *skb)
+static void hidp_recv_ctrl_frame(struct hidp_session *session,
+ struct sk_buff *skb)
{
unsigned char hdr, type, param;
@@ -440,7 +445,8 @@ static inline void hidp_recv_ctrl_frame(
kfree_skb(skb);
}
-static inline void hidp_recv_intr_frame(struct hidp_session *session, struct sk_buff *skb)
+static void hidp_recv_intr_frame(struct hidp_session *session,
+ struct sk_buff *skb)
{
unsigned char hdr;
@@ -608,7 +614,8 @@ static struct device *hidp_get_device(st
return conn ? &conn->dev : NULL;
}
-static inline int hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
+static int hidp_setup_input(struct hidp_session *session,
+ struct hidp_connadd_req *req)
{
struct input_dev *input = session->input;
int i;
@@ -685,7 +692,8 @@ static void hidp_setup_quirks(struct hid
hid->quirks = hidp_blacklist[n].quirks;
}
-static inline void hidp_setup_hid(struct hidp_session *session, struct hidp_connadd_req *req)
+static void hidp_setup_hid(struct hidp_session *session,
+ struct hidp_connadd_req *req)
{
struct hid_device *hid = session->hid;
struct hid_report *report;
_
^ permalink raw reply
* [patch 1/7] bluetooth: hidp_process_hid_control remove unnecessary parameter dealing
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, hidave.darkstar
From: Dave Young <hidave.darkstar@gmail.com>
According to the bluetooth HID spec v1.0 chapter 7.4.2
"This code requests a major state change in a BT-HID device. A HID_CONTROL
request does not generate a HANDSHAKE response."
"A HID_CONTROL packet with a parameter of VIRTUAL_CABLE_UNPLUG is the only
HID_CONTROL packet a device can send to a host. A host will ignore all other
packets."
So in the hidp_precess_hid_control function, we just need to deal with the
UNLUG packet.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/hidp/core.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff -puN net/bluetooth/hidp/core.c~bluetooth-hidp_process_hid_control-remove-unnecessary-parameter-dealing net/bluetooth/hidp/core.c
--- a/net/bluetooth/hidp/core.c~bluetooth-hidp_process_hid_control-remove-unnecessary-parameter-dealing
+++ a/net/bluetooth/hidp/core.c
@@ -369,30 +369,13 @@ static inline void hidp_process_hid_cont
{
BT_DBG("session %p param 0x%02x", session, param);
- switch (param) {
- case HIDP_CTRL_NOP:
- break;
-
- case HIDP_CTRL_VIRTUAL_CABLE_UNPLUG:
+ if (param == HIDP_CTRL_VIRTUAL_CABLE_UNPLUG) {
/* Flush the transmit queues */
skb_queue_purge(&session->ctrl_transmit);
skb_queue_purge(&session->intr_transmit);
/* Kill session thread */
atomic_inc(&session->terminate);
- break;
-
- case HIDP_CTRL_HARD_RESET:
- case HIDP_CTRL_SOFT_RESET:
- case HIDP_CTRL_SUSPEND:
- case HIDP_CTRL_EXIT_SUSPEND:
- /* FIXME: We have to parse these and return no error */
- break;
-
- default:
- __hidp_send_ctrl_message(session,
- HIDP_TRANS_HANDSHAKE | HIDP_HSHK_ERR_INVALID_PARAMETER, NULL, 0);
- break;
}
}
_
^ permalink raw reply
* [patch 7/7] rfcomm tty: destroy before tty_close()
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, hidave.darkstar
From: Dave Young <hidave.darkstar@gmail.com>
rfcomm dev could be deleted in tty_hangup, so we must not call
rfcomm_dev_del again to prevent from destroying rfcomm dev before tty
close.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/rfcomm/tty.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN net/bluetooth/rfcomm/tty.c~rfcomm-tty-destroy-before-tty_close net/bluetooth/rfcomm/tty.c
--- a/net/bluetooth/rfcomm/tty.c~rfcomm-tty-destroy-before-tty_close
+++ a/net/bluetooth/rfcomm/tty.c
@@ -429,7 +429,8 @@ static int rfcomm_release_dev(void __use
if (dev->tty)
tty_vhangup(dev->tty);
- rfcomm_dev_del(dev);
+ if (!test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags))
+ rfcomm_dev_del(dev);
rfcomm_dev_put(dev);
return 0;
}
_
^ permalink raw reply
* [patch 3/7] drivers/bluetooth/bpa10x.c: fix memleak
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, bunk
From: Adrian Bunk <bunk@kernel.org>
This patch fixea a memleak spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/bpa10x.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/bluetooth/bpa10x.c~drivers-bluetooth-bpa10xc-fix-memleak drivers/bluetooth/bpa10x.c
--- a/drivers/bluetooth/bpa10x.c~drivers-bluetooth-bpa10xc-fix-memleak
+++ a/drivers/bluetooth/bpa10x.c
@@ -423,6 +423,7 @@ static int bpa10x_send_frame(struct sk_b
break;
default:
+ usb_free_urb(urb);
return -EILSEQ;
}
_
^ permalink raw reply
* [patch 5/7] bluetooth: blacklist another Broadcom BCM2035 device
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, andy
From: Andy Shevchenko <andy@smile.org.ua>
This device is recognized as bluetooth, but still not works.
Signed-off-by: Andy Shevchenko <andy@smile.org.ua>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/hci_usb.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/bluetooth/hci_usb.c~bluetooth-blacklist-another-broadcom-bcm2035-device drivers/bluetooth/hci_usb.c
--- a/drivers/bluetooth/hci_usb.c~bluetooth-blacklist-another-broadcom-bcm2035-device
+++ a/drivers/bluetooth/hci_usb.c
@@ -111,6 +111,7 @@ static struct usb_device_id blacklist_id
{ USB_DEVICE(0x0a5c, 0x2033), .driver_info = HCI_IGNORE },
/* Broadcom BCM2035 */
+ { USB_DEVICE(0x0a5c, 0x2035), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = HCI_RESET | HCI_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = HCI_BCM92035 },
_
^ permalink raw reply
* [patch 6/7] hci_ldisc: fix null pointer deref
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, david, alan, arjan
From: David Newall <david@davidnewall.com>
Arjan:
With the help of kerneloops.org I've spotted a nice little interaction
between the TTY layer and the bluetooth code, however the tty layer is not
something I'm all too familiar with so I rather ask than brute-force fix the
code incorrectly.
The raw details are at:
http://www.kerneloops.org/search.php?search=uart_flush_buffer
What happens is that, on closing the bluetooth tty, the tty layer goes
into the release_dev() function, which first does a bunch of stuff, then
sets the file->private_data to NULL, does some more stuff and then calls the
ldisc close function. Which in this case, is hci_uart_tty_close().
Now, hci_uart_tty_close() calls hci_uart_close() which clears some
internal bit, and then calls hci_uart_flush()... which calls back to the
tty layers' uart_flush_buffer() function. (in drivers/bluetooth/hci_tty.c
around line 194) Which then WARN_ON()'s because that's not allowed/supposed
to be called this late in the shutdown of the port....
Should the bluetooth driver even call this flush function at all??
David:
This seems to be what happens: Hci_uart_close() flushes using
hci_uart_flush(). Subsequently, in hci_dev_do_close(), (one step in
hci_unregister_dev()), hci_uart_flush() is called again. The comment in
uart_flush_buffer(), relating to the WARN_ON(), indicates you can't flush
after the port is closed; which sounds reasonable. I think hci_uart_close()
should set hdev->flush to NULL before returning. Hci_dev_do_close() does
check for this. The code path is rather involved and I'm not entirely clear
of all steps, but I think that's what should be done.
akpm:
No idea. trollmerge.
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/hci_ldisc.c | 1 +
1 file changed, 1 insertion(+)
diff -puN drivers/bluetooth/hci_ldisc.c~hci_ldisc-fix-null-pointer-deref drivers/bluetooth/hci_ldisc.c
--- a/drivers/bluetooth/hci_ldisc.c~hci_ldisc-fix-null-pointer-deref
+++ a/drivers/bluetooth/hci_ldisc.c
@@ -208,6 +208,7 @@ static int hci_uart_close(struct hci_dev
return 0;
hci_uart_flush(hdev);
+ hdev->flush = NULL;
return 0;
}
_
^ permalink raw reply
* [patch 4/7] drivers/bluetooth/btsdio.c: fix double-free
From: akpm @ 2008-02-05 7:48 UTC (permalink / raw)
To: marcel; +Cc: netdev, akpm, bunk
From: Adrian Bunk <bunk@kernel.org>
This patch fixes a double-free spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/bluetooth/btsdio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN drivers/bluetooth/btsdio.c~drivers-bluetooth-btsdioc-fix-double-free drivers/bluetooth/btsdio.c
--- a/drivers/bluetooth/btsdio.c~drivers-bluetooth-btsdioc-fix-double-free
+++ a/drivers/bluetooth/btsdio.c
@@ -162,10 +162,8 @@ static int btsdio_rx_packet(struct btsdi
bt_cb(skb)->pkt_type = hdr[3];
err = hci_recv_frame(skb);
- if (err < 0) {
- kfree(skb);
+ if (err < 0)
return err;
- }
sdio_writeb(data->func, 0x00, REG_PC_RRT, NULL);
_
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received AUTH chunk while enabled auth
From: Wei Yongjun @ 2008-02-05 8:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Vlad Yasevich, lksctp-developers
In-Reply-To: <479A112D.5020201@hp.com>
If STCP is started while /proc/sys/net/sctp/auth_enable is set 0 and
association is established between endpoints. Then if
/proc/sys/net/sctp/auth_enable is set 1, a received AUTH chunk will
cause kernel panic.
Test as following:
step 1: echo 0> /proc/sys/net/sctp/auth_enable
step 2:
SCTP client SCTP server
INIT --------->
<--------- INIT-ACK
COOKIE-ECHO --------->
<--------- COOKIE-ACK
step 3:
echo 1> /proc/sys/net/sctp/auth_enable
step 4:
SCTP client SCTP server
AUTH -----------> Kernel Panic
This patch fix this probleam to treat AUTH chunk as unknow chunk if peer
has initialized with no auth capable.
> Sorry for the delay. Was on vacation without net access.
>
> Wei Yongjun wrote:
>>
>>
>> This patch fix this probleam to treat AUTH chunk as unknow chunk if
>> peer has initialized with no auth capable.
>>
>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
>
>>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
--- a/net/sctp/sm_statefuns.c 2008-01-21 00:03:25.000000000 -0500
+++ b/net/sctp/sm_statefuns.c 2008-01-21 05:14:08.000000000 -0500
@@ -3785,6 +3785,10 @@ sctp_disposition_t sctp_sf_eat_auth(cons
struct sctp_chunk *err_chunk;
sctp_ierror_t error;
+ /* Make sure that the peer has AUTH capable */
+ if (!asoc->peer.auth_capable)
+ return sctp_sf_unk_chunk(ep, asoc, type, arg, commands);
+
if (!sctp_vtag_verify(chunk, asoc)) {
sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_BAD_TAG,
SCTP_NULL());
^ permalink raw reply
* Re: [PATCH] SCTP: Fix kernel panic while received AUTH chunk with BAD shared key identifier
From: Wei Yongjun @ 2008-02-05 8:26 UTC (permalink / raw)
To: David Miller; +Cc: Vlad Yasevich, Neil Horman, netdev, lksctp-developers
In-Reply-To: <479A126F.4010505@hp.com>
If SCTP-AUTH is enabled, received AUTH chunk with BAD shared key
identifier will cause kernel panic.
Test as following:
step1: enabled /proc/sys/net/sctp/auth_enable
step 2: connect to SCTP server with auth capable. Association is
established between endpoints. Then send a AUTH chunk with a bad
shareid, SCTP server will kernel panic after received that AUTH chunk.
SCTP client SCTP server
INIT ---------->
(with auth capable)
<---------- INIT-ACK
(with auth capable)
COOKIE-ECHO ---------->
<---------- COOKIE-ACK
AUTH ---------->
AUTH chunk is like this:
AUTH chunk
Chunk type: AUTH (15)
Chunk flags: 0x00
Chunk length: 28
Shared key identifier: 10
HMAC identifier: SHA-1 (1)
HMAC: 0000000000000000000000000000000000000000
The assignment of NULL to key can safely be removed, since key_for_each
(which is just list_for_each_entry under the covers does an initial
assignment to key anyway).
If the endpoint_shared_keys list is empty, or if the key_id being
requested does not exist, the function as it currently stands returns
the actuall list_head (in this case endpoint_shared_keys. Since that
list_head isn't surrounded by an actuall data structure, the last
iteration through list_for_each_entry will do a container_of on key, and
we wind up returning a bogus pointer, instead of NULL, as we should.
> Neil Horman wrote:
>> On Tue, Jan 22, 2008 at 05:29:20PM +0900, Wei Yongjun wrote:
>>
>> FWIW, Ack from me. The assignment of NULL to key can safely be
>> removed, since
>> key_for_each (which is just list_for_each_entry under the covers does
>> an initial
>> assignment to key anyway).
>> If the endpoint_shared_keys list is empty, or if the key_id being
>> requested does
>> not exist, the function as it currently stands returns the actuall
>> list_head (in
>> this case endpoint_shared_keys. Since that list_head isn't
>> surrounded by an
>> actuall data structure, the last iteration through
>> list_for_each_entry will do a
>> container_of on key, and we wind up returning a bogus pointer,
>> instead of NULL,
>> as we should. Wei's patch corrects that.
>>
>> Regards
>> Neil
>>
>> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>>
>
> Yep, the patch is correct.
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
>
> -vlad
>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
--- a/net/sctp/auth.c 2008-01-21 00:03:25.000000000 -0500
+++ b/net/sctp/auth.c 2008-01-21 21:31:47.000000000 -0500
@@ -420,15 +420,15 @@ struct sctp_shared_key *sctp_auth_get_sh
const struct sctp_association *asoc,
__u16 key_id)
{
- struct sctp_shared_key *key = NULL;
+ struct sctp_shared_key *key;
/* First search associations set of endpoint pair shared keys */
key_for_each(key, &asoc->endpoint_shared_keys) {
if (key->key_id == key_id)
- break;
+ return key;
}
- return key;
+ return NULL;
}
/*
^ permalink raw reply
* Re: [Wireless, ath5k] 2.6.24-git13 9135f1901ee6449dfe338adf6e40e9c2025b8150
From: Jiri Slaby @ 2008-02-05 8:54 UTC (permalink / raw)
To: Oliver Pinter
Cc: netdev, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, John W. Linville,
Linux Kernel, Bruno Randolf, Andrew Morton
In-Reply-To: <6101e8c40802041340g749b1e03k70fda7fdb21452d7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 02/04/2008 10:40 PM, Oliver Pinter wrote:
> On 2/4/08, Oliver Pinter <oliver.pntr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 2/4/08, Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 02/04/2008 03:00 PM, Oliver Pinter (Pintér Olivér) wrote:
>>>> [ 413.118874] wpa_supplicant[4388]: segfault at 30 ip 080697ca sp
>>>> bfc9cab0 error 4 in wpa_supplicant[8048000+4c000]
>>> Seems like wpa_supplicant is broken. Is this a regression?
>> yes, but with madwifi is all ok
And this... madwifi goes through ported bsd net80211. So which latest git you
tried worked for you when this is a regression, please?
^ permalink raw reply
* RE: LRO ip_summed
From: Kostya B @ 2008-02-05 8:56 UTC (permalink / raw)
To: Jan-Bernd Themann; +Cc: netdev
In-Reply-To: <200802041014.23989.ossthema@de.ibm.com>
1. Let's assume a driver which has a HW csum capability, however it has a privilege to assign any value for ip_summed.
For example the driver assigns "unnecessary" for most of the packets, however it fails to verify the packets less than 96 bytes ("checksum_none").
Now, the LRO will aggregate all of them and assign the value "used for all aggregated packets" - that is wrong,
Of course, it is possible to avoid that situation in driver, however [proposal] from the point of view of the *generic* LRO it could be better to check each newly aggregated skb whether it has the same ip_summed as the first one (preserve coherency). Thus, there is no need to keep ip_summed field in the struct net_lro_mgr.
2. Now, when a skb could not be aggregated (modes: aggregating SKBs) I think where's no need to override its original ip_summed (see "out" label of __lro_proc_skb()) The comment says "Original SKB has to be posted to stack". I would be wrong, but I don't get the reason to possible change of ip_summed.
Regards,
- Kostya
----------------------------------------
> From: ossthema@de.ibm.com
> To: bkostya@hotmail.com
> Subject: Re: LRO ip_summed
> Date: Mon, 4 Feb 2008 10:14:23 +0100
> CC: netdev@vger.kernel.org
>
> On Sunday 03 February 2008 10:48, Kostya B wrote:
>>
>> Hi,
>>
>> The mail is related to the way LRO manipulates the ip_summed value. Could anybody (author) explain why to overwrite the original value of skb->ip_summed, when it's processing by __lro_proc_skb ?
>> E.g. in out: label
>>
>> Why not to preserve the coherency of csum status of each incoming to LRO packet, the same way the IP defragmentation does? That means - all skb in descriptor have the same value of ip_summed.
>>
>
> Hi,
>
> I'm not sure if I understand your proposal correctly.
> Currently the driver decides via the struct net_lro_mgr
> a) which ip_summed value will be used for all aggregated packets
> b) which one to use for those packets that can not be aggregated
>
> to a) this one should always be the same. The driver knows whether its HW is
> capable of performing ip checksum checking for this kind of traffic (TCP)
>
> There are two modes: aggregating SKBs or aggregating fragments.
> When fragments are aggregated, there is no SKB with a filled ip_summed available.
>
> Please outline which parts of which mode you suggest to change.
>
> Regards,
> Jan-Bernd
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* [IPV6] fix sysctl compilation error
From: Daniel Lezcano @ 2008-02-05 9:10 UTC (permalink / raw)
To: David Miller
Cc: YOSHIFUJI Hideaki / 吉藤英明,
Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: fix-sysctl-compilation-error.patch --]
[-- Type: text/x-patch, Size: 1547 bytes --]
Subject: fix sysctl compilation error
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Move ipv6_icmp_sysctl_init and ipv6_route_sysctl_init into
the right ifdef section otherwise that does not compile when
CONFIG_SYSCTL=yes and CONFIG_PROC_FS=no
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
include/net/ipv6.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: net-2.6.25-fix/include/net/ipv6.h
===================================================================
--- net-2.6.25-fix.orig/include/net/ipv6.h
+++ net-2.6.25-fix/include/net/ipv6.h
@@ -110,7 +110,6 @@ struct frag_hdr {
/* sysctls */
extern int sysctl_mld_max_msf;
-
extern struct ctl_path net_ipv6_ctl_path[];
#define _DEVINC(statname, modifier, idev, field) \
@@ -586,9 +585,6 @@ extern int ip6_mc_msfget(struct sock *sk
int __user *optlen);
#ifdef CONFIG_PROC_FS
-extern struct ctl_table *ipv6_icmp_sysctl_init(struct net *net);
-extern struct ctl_table *ipv6_route_sysctl_init(struct net *net);
-
extern int ac6_proc_init(void);
extern void ac6_proc_exit(void);
extern int raw6_proc_init(void);
@@ -621,6 +617,8 @@ static inline int snmp6_unregister_dev(s
extern ctl_table ipv6_route_table_template[];
extern ctl_table ipv6_icmp_table_template[];
+extern struct ctl_table *ipv6_icmp_sysctl_init(struct net *net);
+extern struct ctl_table *ipv6_route_sysctl_init(struct net *net);
extern int ipv6_sysctl_register(void);
extern void ipv6_sysctl_unregister(void);
#endif
^ permalink raw reply
* [FIB] fix fib_proc compilation error
From: Daniel Lezcano @ 2008-02-05 9:11 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: fix-fib-frontend-compilation-error.patch --]
[-- Type: text/x-patch, Size: 827 bytes --]
Subject: fix fib_proc compilation error
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Fix fib_proc_[init|exit] definition when CONFIG_PROCFS=no
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
include/net/ip_fib.h | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: net-2.6/include/net/ip_fib.h
===================================================================
--- net-2.6.orig/include/net/ip_fib.h
+++ net-2.6/include/net/ip_fib.h
@@ -266,6 +266,16 @@ static inline void fib_res_put(struct fi
#ifdef CONFIG_PROC_FS
extern int __net_init fib_proc_init(struct net *net);
extern void __net_exit fib_proc_exit(struct net *net);
+#else
+static inline int fib_proc_init(struct net *net)
+{
+ return 0;
+}
+
+static inline void fib_proc_exit(struct net *net)
+{
+ return ;
+}
#endif
#endif /* _NET_FIB_H */
^ permalink raw reply
* Re: Slow OOM in netif_RX function
From: Ivan Mitev @ 2008-02-05 9:04 UTC (permalink / raw)
To: Andi Kleen; +Cc: Ivan Dichev, Eric Dumazet, Arnaldo Carvalho de Melo, netdev
In-Reply-To: <20080204155526.GA7988@one.firstfloor.org>
[(the other) Ivan took a few days holidays, so I'm replacing him for
this issue.]
Andi, you spotted it, it was really the start of an IP header, and it
shows up that these are ESP packets for a quite complicated VPN tunnel
we have (re-routing packets from an office to another, with some NAT on
top of that). So openswan/ipsec.ko seems to be the problem here, I will
file a bug report there. Meanwhile we'll try to set up manual keying and
decrypt the encrypted payload to gather more details on the packets.
My apologies, the issue seems to be with an out-of-tree module, but we
really didn't think the problem was there (there's no correlation
between the leak increase and vpn/ike traffic). But it was interesting
to understand slabs, learn how to setup/use crash, and analyze memory
bits :)
Thanks again to all the people who helped !
Ivan Mitev
Andi Kleen wrote:
>> Nothing that looks like a struct net_device. All the dumped leaked slab
>> look the same until "45 20 05 d8" (the ascii 'E' on the 3rd line).
>
> 45 ... is often the start of an IP header (IPv4, 5*4=20 bytes length)
>
> You could dump them to a file (e.g. using a sial script) and then
> look at them with tcpdump or similar to get an idea what kinds
> of packets they are.
>
> -Andi
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: LRO ip_summed
From: Jan-Bernd Themann @ 2008-02-05 9:45 UTC (permalink / raw)
To: Kostya B; +Cc: netdev
In-Reply-To: <BAY121-W3321045858D4A665892759B62C0@phx.gbl>
On Tuesday 05 February 2008 09:56, Kostya B wrote:
>
> 1. Let's assume a driver which has a HW csum capability, however it has a privilege to assign any value for ip_summed.
> For example the driver assigns "unnecessary" for most of the packets, however it fails to verify the packets less than 96 bytes ("checksum_none").
> Now, the LRO will aggregate all of them and assign the value "used for all aggregated packets" - that is wrong,
>
> Of course, it is possible to avoid that situation in driver, however [proposal] from the point of view of the *generic* LRO it could be better to check each newly aggregated skb whether it has the same ip_summed as the first one (preserve coherency). Thus, there is no need to keep ip_summed field in the struct net_lro_mgr.
Yes, checking if ip_summed is equal for all aggregated packets would work
for the "aggregating SKB" mode. For the other mode this information is currently
not passed to LRO but could of course be provided as parameter by the driver.
The question is if there is any HW which would benefit from this (meaning multiple
ip_summed values for TCP packets of different sizes) so that this additional
check is really useful. The less required checks the better.
>
> 2. Now, when a skb could not be aggregated (modes: aggregating SKBs) I think where's no need to override its original ip_summed (see "out" label of __lro_proc_skb()) The comment says "Original SKB has to be posted to stack". I would be wrong, but I don't get the reason to possible change of ip_summed.
>
Good point. This assignment seems to be unnecessary.
Regards,
Jan-Bernd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox