netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next-2.6] bcm63xx_enet: use netdev stats
From: Eric Dumazet @ 2010-08-24 15:53 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Maxime Bizon, Florian Fainelli

Use integrated net_device stats instead of a private one

Get rid of bcm_enet_get_stats()

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 drivers/net/bcm63xx_enet.c |   60 +++++++++++++++--------------------
 drivers/net/bcm63xx_enet.h |    1 
 2 files changed, 27 insertions(+), 34 deletions(-)

diff --git a/drivers/net/bcm63xx_enet.c b/drivers/net/bcm63xx_enet.c
index 0d2c5da..e2f70c3 100644
--- a/drivers/net/bcm63xx_enet.c
+++ b/drivers/net/bcm63xx_enet.c
@@ -293,22 +293,22 @@ static int bcm_enet_receive_queue(struct net_device *dev, int budget)
 		/* if the packet does not have start of packet _and_
 		 * end of packet flag set, then just recycle it */
 		if ((len_stat & DMADESC_ESOP_MASK) != DMADESC_ESOP_MASK) {
-			priv->stats.rx_dropped++;
+			dev->stats.rx_dropped++;
 			continue;
 		}
 
 		/* recycle packet if it's marked as bad */
 		if (unlikely(len_stat & DMADESC_ERR_MASK)) {
-			priv->stats.rx_errors++;
+			dev->stats.rx_errors++;
 
 			if (len_stat & DMADESC_OVSIZE_MASK)
-				priv->stats.rx_length_errors++;
+				dev->stats.rx_length_errors++;
 			if (len_stat & DMADESC_CRC_MASK)
-				priv->stats.rx_crc_errors++;
+				dev->stats.rx_crc_errors++;
 			if (len_stat & DMADESC_UNDER_MASK)
-				priv->stats.rx_frame_errors++;
+				dev->stats.rx_frame_errors++;
 			if (len_stat & DMADESC_OV_MASK)
-				priv->stats.rx_fifo_errors++;
+				dev->stats.rx_fifo_errors++;
 			continue;
 		}
 
@@ -324,7 +324,7 @@ static int bcm_enet_receive_queue(struct net_device *dev, int budget)
 			nskb = netdev_alloc_skb_ip_align(dev, len);
 			if (!nskb) {
 				/* forget packet, just rearm desc */
-				priv->stats.rx_dropped++;
+				dev->stats.rx_dropped++;
 				continue;
 			}
 
@@ -342,8 +342,8 @@ static int bcm_enet_receive_queue(struct net_device *dev, int budget)
 
 		skb_put(skb, len);
 		skb->protocol = eth_type_trans(skb, dev);
-		priv->stats.rx_packets++;
-		priv->stats.rx_bytes += len;
+		dev->stats.rx_packets++;
+		dev->stats.rx_bytes += len;
 		netif_receive_skb(skb);
 
 	} while (--budget > 0);
@@ -403,7 +403,7 @@ static int bcm_enet_tx_reclaim(struct net_device *dev, int force)
 		spin_unlock(&priv->tx_lock);
 
 		if (desc->len_stat & DMADESC_UNDER_MASK)
-			priv->stats.tx_errors++;
+			dev->stats.tx_errors++;
 
 		dev_kfree_skb(skb);
 		released++;
@@ -563,8 +563,8 @@ static int bcm_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (!priv->tx_desc_count)
 		netif_stop_queue(dev);
 
-	priv->stats.tx_bytes += skb->len;
-	priv->stats.tx_packets++;
+	dev->stats.tx_bytes += skb->len;
+	dev->stats.tx_packets++;
 	ret = NETDEV_TX_OK;
 
 out_unlock:
@@ -1141,17 +1141,6 @@ static int bcm_enet_stop(struct net_device *dev)
 }
 
 /*
- * core request to return device rx/tx stats
- */
-static struct net_device_stats *bcm_enet_get_stats(struct net_device *dev)
-{
-	struct bcm_enet_priv *priv;
-
-	priv = netdev_priv(dev);
-	return &priv->stats;
-}
-
-/*
  * ethtool callbacks
  */
 struct bcm_enet_stats {
@@ -1163,16 +1152,18 @@ struct bcm_enet_stats {
 
 #define GEN_STAT(m) sizeof(((struct bcm_enet_priv *)0)->m),		\
 		     offsetof(struct bcm_enet_priv, m)
+#define DEV_STAT(m) sizeof(((struct net_device_stats *)0)->m),		\
+		     offsetof(struct net_device_stats, m)
 
 static const struct bcm_enet_stats bcm_enet_gstrings_stats[] = {
-	{ "rx_packets", GEN_STAT(stats.rx_packets), -1 },
-	{ "tx_packets",	GEN_STAT(stats.tx_packets), -1 },
-	{ "rx_bytes", GEN_STAT(stats.rx_bytes), -1 },
-	{ "tx_bytes", GEN_STAT(stats.tx_bytes), -1 },
-	{ "rx_errors", GEN_STAT(stats.rx_errors), -1 },
-	{ "tx_errors", GEN_STAT(stats.tx_errors), -1 },
-	{ "rx_dropped",	GEN_STAT(stats.rx_dropped), -1 },
-	{ "tx_dropped",	GEN_STAT(stats.tx_dropped), -1 },
+	{ "rx_packets", DEV_STAT(rx_packets), -1 },
+	{ "tx_packets",	DEV_STAT(tx_packets), -1 },
+	{ "rx_bytes", DEV_STAT(rx_bytes), -1 },
+	{ "tx_bytes", DEV_STAT(tx_bytes), -1 },
+	{ "rx_errors", DEV_STAT(rx_errors), -1 },
+	{ "tx_errors", DEV_STAT(tx_errors), -1 },
+	{ "rx_dropped",	DEV_STAT(rx_dropped), -1 },
+	{ "tx_dropped",	DEV_STAT(tx_dropped), -1 },
 
 	{ "rx_good_octets", GEN_STAT(mib.rx_gd_octets), ETH_MIB_RX_GD_OCTETS},
 	{ "rx_good_pkts", GEN_STAT(mib.rx_gd_pkts), ETH_MIB_RX_GD_PKTS },
@@ -1328,7 +1319,11 @@ static void bcm_enet_get_ethtool_stats(struct net_device *netdev,
 		char *p;
 
 		s = &bcm_enet_gstrings_stats[i];
-		p = (char *)priv + s->stat_offset;
+		if (s->mib_reg == -1)
+			p = (char *)&netdev->stats;
+		else
+			p = (char *)priv;
+		p += s->stat_offset;
 		data[i] = (s->sizeof_stat == sizeof(u64)) ?
 			*(u64 *)p : *(u32 *)p;
 	}
@@ -1605,7 +1600,6 @@ static const struct net_device_ops bcm_enet_ops = {
 	.ndo_open		= bcm_enet_open,
 	.ndo_stop		= bcm_enet_stop,
 	.ndo_start_xmit		= bcm_enet_start_xmit,
-	.ndo_get_stats		= bcm_enet_get_stats,
 	.ndo_set_mac_address	= bcm_enet_set_mac_address,
 	.ndo_set_multicast_list = bcm_enet_set_multicast_list,
 	.ndo_do_ioctl		= bcm_enet_ioctl,
diff --git a/drivers/net/bcm63xx_enet.h b/drivers/net/bcm63xx_enet.h
index bd3684d..0e3048b 100644
--- a/drivers/net/bcm63xx_enet.h
+++ b/drivers/net/bcm63xx_enet.h
@@ -274,7 +274,6 @@ struct bcm_enet_priv {
 	int pause_tx;
 
 	/* stats */
-	struct net_device_stats stats;
 	struct bcm_enet_mib_counters mib;
 
 	/* after mib interrupt, mib registers update is done in this



^ permalink raw reply related

* Re: [PATCH] TCP_FAILFAST: a new socket option to timeout/abort a connection quicker
From: Hagen Paul Pfeifer @ 2010-08-24 16:28 UTC (permalink / raw)
  To: Arnd Hannemann; +Cc: Eric Dumazet, H.K. Jerry Chu, ilpo.jarvinen, davem, netdev
In-Reply-To: <4C73DE32.1030802@nets.rwth-aachen.de>

* Arnd Hannemann | 2010-08-24 16:58:58 [+0200]:

>Nice, so did you come up with a name for the socket option yet?

+#define      TCP_UTO       18  /* User Timeout Option */

The patch is an early state and details as well as testing is a little bit
costly.

>Hmm, is there really a difference? If an application specifies
>a wanted timeout e.g. with USER_TIMEOUT, CHANGEABLE will
>become false and the value would be announced via ADV_UTO.
>The connection could be aborted locally after that time passed,
>regardless of what the remote site thinks the timeout should be.
>
>As I understand it U_LIMIT and L_LIMIT would only be there
>for safety to disallow nonsensical values of USER_TIMEOUT.
>
>Did I miss something?

Maybe not, aot sure. I must take a look at the patch from Jerry. I had no time
until now.

Hagen

^ permalink raw reply

* kernel hangs when removing a dummy netdev with an attached macvlan
From: Daniel Lezcano @ 2010-08-24 16:32 UTC (permalink / raw)
  To: Linux Netdev List

Hi all,

I noticed the kernel hangs when we create a dummy interface, assign a 
macvlan on it and then delete the dummy interface.

How to reproduce:

  ip link add dummy0 type dummy
  ip link add mc0 link dummy0 type macvlan
  ip link del dummy0

That triggers:

Call Trace:
Code: 8b 84 24 08 08 00 00 49 81 c4 08 08 00 00 48 83 e8 08 48 8b 58 08 
48 83 eb 08 eb 1a 48 8b 38 31 f6 48 8b 87 c8 05 00 00 ff 50 50 <48> 8b 
53 08 48 89 d8 48 8d 5a f8 48 8d 50 08 49 39 d4 75 dd 5a
Kernel panic - not syncing: softlockup: hung tasks
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:2322 trace_hardirqs_on_caller+0xb8/0x13b()
Hardware name: Bochs
Modules linked in:
Pid: 3915, comm: ip Not tainted 2.6.34 #468
Call Trace:
<IRQ>  [<ffffffff8102b2c0>] warn_slowpath_common+0x77/0x8f
  [<ffffffff814002dd>] ? panic+0xda/0xe7
  [<ffffffff8102b2e7>] warn_slowpath_null+0xf/0x11
  [<ffffffff81051b9f>] trace_hardirqs_on_caller+0xb8/0x13b
  [<ffffffff81051c2f>] trace_hardirqs_on+0xd/0xf
  [<ffffffff814002dd>] panic+0xda/0xe7
  [<ffffffff81076538>] softlockup_tick+0x164/0x16d
  [<ffffffff81038334>] run_local_timers+0x18/0x1a
  [<ffffffff81038357>] update_process_times+0x21/0x47
  [<ffffffff8104ec6f>] T.289+0x63/0x65
  [<ffffffff8104ec80>] tick_handle_periodic+0xf/0x57
  [<ffffffff8101330e>] smp_apic_timer_interrupt+0x74/0x86
  [<ffffffff81003493>] apic_timer_interrupt+0x13/0x20
<EOI>  [<ffffffff812fd7c4>] ? macvlan_device_event+0x101/0x11f
  [<ffffffff812fd7c4>] ? macvlan_device_event+0x101/0x11f
  [<ffffffff81405d7b>] notifier_call_chain+0x32/0x5e
  [<ffffffff81048ad8>] raw_notifier_call_chain+0xf/0x11
  [<ffffffff81339942>] call_netdevice_notifiers+0x16/0x18
  [<ffffffff8133a22c>] rollback_registered_many+0x11b/0x205
  [<ffffffff8133a393>] rollback_registered+0x2c/0x33
  [<ffffffff8133a3f7>] unregister_netdevice_queue+0x5d/0x7c
  [<ffffffff81342b17>] rtnl_dellink+0xab/0xc0
  [<ffffffff8134433c>] rtnetlink_rcv_msg+0x1c1/0x1de
  [<ffffffff8134417b>] ? rtnetlink_rcv_msg+0x0/0x1de
  [<ffffffff813536e3>] netlink_rcv_skb+0x3e/0x8f
  [<ffffffff81344174>] rtnetlink_rcv+0x21/0x28
  [<ffffffff81353403>] netlink_unicast+0x226/0x29c
  [<ffffffff81353ea8>] netlink_sendmsg+0x269/0x278
  [<ffffffff813287fa>] sock_sendmsg+0xd3/0xf4
  [<ffffffff810ae5b8>] ? might_fault+0x4c/0x9c
  [<ffffffff810ae5b8>] ? might_fault+0x4c/0x9c
  [<ffffffff810ae601>] ? might_fault+0x95/0x9c
  [<ffffffff810ae5b8>] ? might_fault+0x4c/0x9c
  [<ffffffff81332622>] ? verify_iovec+0x59/0x97
  [<ffffffff81328a61>] sys_sendmsg+0x209/0x273
  [<ffffffff8104823c>] ? up_read+0x1e/0x36
  [<ffffffff81405d0c>] ? do_page_fault+0x329/0x366
  [<ffffffff810b5921>] ? do_brk+0x23f/0x322
  [<ffffffff81051bf8>] ? trace_hardirqs_on_caller+0x111/0x13b
  [<ffffffff81402643>] ? trace_hardirqs_on_thunk+0x3a/0x3f
  [<ffffffff81002ae8>] system_call_fastpath+0x16/0x1b
---[ end trace 34536d0c9f1bbf5b ]---


^ permalink raw reply

* Re: [PATCH RFC] net: save RX queue number in sock for dev_pick_tx() use
From: Ben Hutchings @ 2010-08-24 16:45 UTC (permalink / raw)
  To: Changli Gao
  Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1282640519-15541-1-git-send-email-xiaosuo@gmail.com>

On Tue, 2010-08-24 at 17:01 +0800, Changli Gao wrote:
> For the packets sent out from a local server socket, we can use the queue
> from which the packets from the client socket are received.
> 
> It may help on a TCP or UDP server. Because I don't have a multiqueue NIC,
> I don't even test it.
[...]

There are some fairly cheap 1G multiqueue NICs around now (and even
several of the ARM embedded Ethernet controllers support multiqueue).

Could you compare this with my patch in
<http://thread.gmane.org/gmane.linux.network/158477>?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply

* [patch 1/4] pxa168_eth: remove unneeded null check
From: Dan Carpenter @ 2010-08-24 16:52 UTC (permalink / raw)
  To: Sachin Sanap; +Cc: David S. Miller, netdev, kernel-janitors

"pep->pd" isn't checked consistently in this function.  For example it's
dereferenced unconditionally on the next line after the end of the if
condition.  This function is only called from pxa168_eth_probe() and
pep->pd is always non-NULL so I removed the check.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index ecc64d7..857a681 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -1414,10 +1414,8 @@ static int ethernet_phy_setup(struct net_device *dev)
 {
 	struct pxa168_eth_private *pep = netdev_priv(dev);
 
-	if (pep->pd != NULL) {
-		if (pep->pd->init)
-			pep->pd->init();
-	}
+	if (pep->pd->init)
+		pep->pd->init();
 	pep->phy = phy_scan(pep, pep->pd->phy_addr & 0x1f);
 	if (pep->phy != NULL)
 		phy_init(pep, pep->pd->speed, pep->pd->duplex);

^ permalink raw reply related

* [patch 2/4] pxa168_eth: fix error handling in prope
From: Dan Carpenter @ 2010-08-24 16:53 UTC (permalink / raw)
  To: Sachin Sanap; +Cc: David S. Miller, netdev, kernel-janitors

A couple issues here:
* Some resources weren't released.  
* If alloc_etherdev() failed it would have caused a NULL dereference
  because "pep" would be null when we checked "if (pep->clk)".
* Also it's better to propagate the error codes from mdiobus_register()
  instead of just returning -ENOMEM.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index 857a681..302fb48 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -1497,7 +1497,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
 	dev = alloc_etherdev(sizeof(struct pxa168_eth_private));
 	if (!dev) {
 		err = -ENOMEM;
-		goto out;
+		goto err_clk;
 	}
 
 	platform_set_drvdata(pdev, dev);
@@ -1507,12 +1507,12 @@ static int pxa168_eth_probe(struct platform_device *pdev)
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (res == NULL) {
 		err = -ENODEV;
-		goto out;
+		goto err_netdev;
 	}
 	pep->base = ioremap(res->start, res->end - res->start + 1);
 	if (pep->base == NULL) {
 		err = -ENOMEM;
-		goto out;
+		goto err_netdev;
 	}
 	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	BUG_ON(!res);
@@ -1549,7 +1549,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
 	pep->smi_bus = mdiobus_alloc();
 	if (pep->smi_bus == NULL) {
 		err = -ENOMEM;
-		goto out;
+		goto err_base;
 	}
 	pep->smi_bus->priv = pep;
 	pep->smi_bus->name = "pxa168_eth smi";
@@ -1558,31 +1558,31 @@ static int pxa168_eth_probe(struct platform_device *pdev)
 	snprintf(pep->smi_bus->id, MII_BUS_ID_SIZE, "%d", pdev->id);
 	pep->smi_bus->parent = &pdev->dev;
 	pep->smi_bus->phy_mask = 0xffffffff;
-	if (mdiobus_register(pep->smi_bus) < 0) {
-		err = -ENOMEM;
-		goto out;
-	}
+	err = mdiobus_register(pep->smi_bus);
+	if (err)
+		goto err_free_mdio;
+
 	pxa168_init_hw(pep);
 	err = ethernet_phy_setup(dev);
 	if (err)
-		goto out;
+		goto err_mdiobus;
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	err = register_netdev(dev);
 	if (err)
-		goto out;
+		goto err_mdiobus;
 	return 0;
-out:
-	if (pep->clk) {
-		clk_disable(pep->clk);
-		clk_put(pep->clk);
-		pep->clk = NULL;
-	}
-	if (pep->base) {
-		iounmap(pep->base);
-		pep->base = NULL;
-	}
-	if (dev)
-		free_netdev(dev);
+
+err_mdiobus:
+	mdiobus_unregister(pep->smi_bus);
+err_free_mdio:
+	mdiobus_free(pep->smi_bus);
+err_base:
+	iounmap(pep->base);
+err_netdev:
+	free_netdev(dev);
+err_clk:
+	clk_disable(clk);
+	clk_put(clk);
 	return err;
 }
 

^ permalink raw reply related

* [patch 3/4] pxa168_eth: update call to phy_mii_ioctl()
From: Dan Carpenter @ 2010-08-24 16:54 UTC (permalink / raw)
  To: Sachin Sanap; +Cc: David S. Miller, netdev, kernel-janitors

The phy_mii_ioctl() function changed recently.  It now takes a struct
ifreq pointer directly.

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index 302fb48..f324b76 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -1350,7 +1350,7 @@ static int pxa168_eth_do_ioctl(struct net_device *dev, struct ifreq *ifr,
 {
 	struct pxa168_eth_private *pep = netdev_priv(dev);
 	if (pep->phy != NULL)
-		return phy_mii_ioctl(pep->phy, if_mii(ifr), cmd);
+		return phy_mii_ioctl(pep->phy, ifr, cmd);
 
 	return -EOPNOTSUPP;
 }

^ permalink raw reply related

* [patch 4/4] pxa168_eth: silence gcc warnings
From: Dan Carpenter @ 2010-08-24 16:55 UTC (permalink / raw)
  To: Sachin Sanap; +Cc: David S. Miller, netdev, kernel-janitors

Casting "pep->tx_desc_dma" to to a struct tx_desc pointer makes gcc
complain:

drivers/net/pxa168_eth.c:657: warning:
	cast to pointer from integer of different size

Signed-off-by: Dan Carpenter <error27@gmail.com>

diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index f324b76..b1f440b 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -654,15 +654,15 @@ static void eth_port_start(struct net_device *dev)
 	/* Assignment of Tx CTRP of given queue */
 	tx_curr_desc = pep->tx_curr_desc_q;
 	wrl(pep, ETH_C_TX_DESC_1,
-	    (u32) ((struct tx_desc *)pep->tx_desc_dma + tx_curr_desc));
+	    (u32) (pep->tx_desc_dma + tx_curr_desc * sizeof(struct tx_desc)));
 
 	/* Assignment of Rx CRDP of given queue */
 	rx_curr_desc = pep->rx_curr_desc_q;
 	wrl(pep, ETH_C_RX_DESC_0,
-	    (u32) ((struct rx_desc *)pep->rx_desc_dma + rx_curr_desc));
+	    (u32) (pep->rx_desc_dma + rx_curr_desc * sizeof(struct rx_desc)));
 
 	wrl(pep, ETH_F_RX_DESC_0,
-	    (u32) ((struct rx_desc *)pep->rx_desc_dma + rx_curr_desc));
+	    (u32) (pep->rx_desc_dma + rx_curr_desc * sizeof(struct rx_desc)));
 
 	/* Clear all interrupts */
 	wrl(pep, INT_CAUSE, 0);

^ permalink raw reply related

* Re: [PATCH RFC] netns: keep vlan slaves on master netns move
From: Daniel Lezcano @ 2010-08-24 17:00 UTC (permalink / raw)
  To: David Lamparter; +Cc: netdev, Patrick McHardy, Eric W. Biederman
In-Reply-To: <20100824115056.GA235835@jupiter.n2.diac24.net>

On 08/24/2010 01:50 PM, David Lamparter wrote:
> Hi everyone,
>
> attached patch makes it possible to keep macvlan / 802.1q slave devices
> on moving their master to a different namespace. as the opposite works
> without problems (moving the slaves into a different namespace), this
> shouldn't cause problems either.
>
> i've tested this with 802.1q on real ethernet devs and bridges and,
> well, it works without crashing, but that obviously doesn't mean it is
> correct :) - therefore input very welcome.
>
> RFC,
>
> David
>
> P.S.: who do i Cc: on netns related stuff?

Definitively the netns is the brain child of:
Eric W. Biederman <ebiederm@xmission.com>

As I contributed and I am interested by following the changes, that will 
be nice if you can Cc me too.

Daniel Lezcano <daniel.lezcano@free.fr>

> --
> previously, if a vlan master device was moved from one network namespace
> to another, all 802.1q and macvlan slaves were deleted.
>
> we can use dev->reg_state to figure out whether dev_change_net_namespace
> is happening, since that won't set dev->reg_state NETREG_UNREGISTERING.
> so, this changes 8021q and macvlan to ignore NETDEV_UNREGISTER when
> reg_state is not NETREG_UNREGISTERING.
>
> Signed-off-by: David Lamparter<equinox@diac24.net>
> ---
>   drivers/net/macvlan.c |    4 ++++
>   net/8021q/vlan.c      |    4 ++++
>   net/core/dev.c        |    4 ++++
>   3 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index f15fe2c..f43f8e4 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -754,6 +754,10 @@ static int macvlan_device_event(struct notifier_block *unused,
>   		}
>   		break;
>   	case NETDEV_UNREGISTER:
> +		/* twiddle thumbs on netns device moves */
> +		if (dev->reg_state != NETREG_UNREGISTERING)
> +			break;
> +

Hmm, I don't feel comfortable with this change. It is like we are trying 
to catch a transient state, not clearly defined (you need a comment) and 
that may lead to some confusion later.

IMHO, it should be convenient to add a NETREG_NETNS_MOVING and set this 
state in the dev_change_net_namespace.

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5c6f519..0214b77 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -924,6 +924,7 @@ struct net_device {

         /* register/unregister state machine */
         enum { NETREG_UNINITIALIZED=0,
+              NETREG_NETNS_MOVING,     /* changing netns */
                NETREG_REGISTERED,       /* completed register_netdevice */
                NETREG_UNREGISTERING,    /* called unregister_netdevice */
                NETREG_UNREGISTERED,     /* completed unregister todo */
diff --git a/net/core/dev.c b/net/core/dev.c
index e233933..9154123 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5752,6 +5752,8 @@ int dev_change_net_namespace(struct net_device 
*dev, struct net *net, const char
         err = -ENODEV;
         unlist_netdevice(dev);

+       dev->reg_state = NETREG_NETNS_MOVING;
+
         synchronize_net();

         /* Shutdown queueing discipline. */
@@ -5786,6 +5788,8 @@ int dev_change_net_namespace(struct net_device 
*dev, struct net *net, const char
         err = netdev_register_kobject(dev);
         WARN_ON(err);

+       dev->reg_state = NETREG_REGISTERED;
+
         /* Add the device back in the hashes */
         list_netdevice(dev);


Then you can check in macvlan_device_event

	...

	if (dev->reg_state != NETREG_NETNS_MOVING)
		break;

	...


Does it make sense ?

   -- Daniel

^ permalink raw reply related

* Re: kernel hangs when removing a dummy netdev with an attached macvlan
From: Eric Dumazet @ 2010-08-24 17:01 UTC (permalink / raw)
  To: Daniel Lezcano; +Cc: Linux Netdev List
In-Reply-To: <4C73F419.2050204@free.fr>

Le mardi 24 août 2010 à 18:32 +0200, Daniel Lezcano a écrit :
> Hi all,
> 
> I noticed the kernel hangs when we create a dummy interface, assign a 
> macvlan on it and then delete the dummy interface.
> 
> How to reproduce:
> 
>   ip link add dummy0 type dummy
>   ip link add mc0 link dummy0 type macvlan
>   ip link del dummy0
> 

Strange, I could not reproduce it with linux-2.6 current tree

> That triggers:
> 
> Call Trace:
> Code: 8b 84 24 08 08 00 00 49 81 c4 08 08 00 00 48 83 e8 08 48 8b 58 08 
> 48 83 eb 08 eb 1a 48 8b 38 31 f6 48 8b 87 c8 05 00 00 ff 50 50 <48> 8b 
> 53 08 48 89 d8 48 8d 5a f8 48 8d 50 08 49 39 d4 75 dd 5a
> Kernel panic - not syncing: softlockup: hung tasks
> ------------[ cut here ]------------
> WARNING: at kernel/lockdep.c:2322 trace_hardirqs_on_caller+0xb8/0x13b()
> Hardware name: Bochs
> Modules linked in:
> Pid: 3915, comm: ip Not tainted 2.6.34 #468
> Call Trace:
> <IRQ>  [<ffffffff8102b2c0>] warn_slowpath_common+0x77/0x8f
>   [<ffffffff814002dd>] ? panic+0xda/0xe7
>   [<ffffffff8102b2e7>] warn_slowpath_null+0xf/0x11
>   [<ffffffff81051b9f>] trace_hardirqs_on_caller+0xb8/0x13b
>   [<ffffffff81051c2f>] trace_hardirqs_on+0xd/0xf
>   [<ffffffff814002dd>] panic+0xda/0xe7
>   [<ffffffff81076538>] softlockup_tick+0x164/0x16d
>   [<ffffffff81038334>] run_local_timers+0x18/0x1a
>   [<ffffffff81038357>] update_process_times+0x21/0x47
>   [<ffffffff8104ec6f>] T.289+0x63/0x65
>   [<ffffffff8104ec80>] tick_handle_periodic+0xf/0x57
>   [<ffffffff8101330e>] smp_apic_timer_interrupt+0x74/0x86
>   [<ffffffff81003493>] apic_timer_interrupt+0x13/0x20
> <EOI>  [<ffffffff812fd7c4>] ? macvlan_device_event+0x101/0x11f
>   [<ffffffff812fd7c4>] ? macvlan_device_event+0x101/0x11f
>   [<ffffffff81405d7b>] notifier_call_chain+0x32/0x5e
>   [<ffffffff81048ad8>] raw_notifier_call_chain+0xf/0x11
>   [<ffffffff81339942>] call_netdevice_notifiers+0x16/0x18
>   [<ffffffff8133a22c>] rollback_registered_many+0x11b/0x205
>   [<ffffffff8133a393>] rollback_registered+0x2c/0x33
>   [<ffffffff8133a3f7>] unregister_netdevice_queue+0x5d/0x7c
>   [<ffffffff81342b17>] rtnl_dellink+0xab/0xc0
>   [<ffffffff8134433c>] rtnetlink_rcv_msg+0x1c1/0x1de
>   [<ffffffff8134417b>] ? rtnetlink_rcv_msg+0x0/0x1de
>   [<ffffffff813536e3>] netlink_rcv_skb+0x3e/0x8f
>   [<ffffffff81344174>] rtnetlink_rcv+0x21/0x28
>   [<ffffffff81353403>] netlink_unicast+0x226/0x29c
>   [<ffffffff81353ea8>] netlink_sendmsg+0x269/0x278
>   [<ffffffff813287fa>] sock_sendmsg+0xd3/0xf4
>   [<ffffffff810ae5b8>] ? might_fault+0x4c/0x9c
>   [<ffffffff810ae5b8>] ? might_fault+0x4c/0x9c
>   [<ffffffff810ae601>] ? might_fault+0x95/0x9c
>   [<ffffffff810ae5b8>] ? might_fault+0x4c/0x9c
>   [<ffffffff81332622>] ? verify_iovec+0x59/0x97
>   [<ffffffff81328a61>] sys_sendmsg+0x209/0x273
>   [<ffffffff8104823c>] ? up_read+0x1e/0x36
>   [<ffffffff81405d0c>] ? do_page_fault+0x329/0x366
>   [<ffffffff810b5921>] ? do_brk+0x23f/0x322
>   [<ffffffff81051bf8>] ? trace_hardirqs_on_caller+0x111/0x13b
>   [<ffffffff81402643>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>   [<ffffffff81002ae8>] system_call_fastpath+0x16/0x1b
> ---[ end trace 34536d0c9f1bbf5b ]---
> 



^ permalink raw reply

* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-24 17:25 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Plamen Petrov, Jarek Poplawski, Andrew Morton, netdev,
	bugzilla-daemon, bugme-daemon
In-Reply-To: <1282662532.2477.248.camel@edumazet-laptop>

Eric Dumazet написа: 

> Le mardi 24 août 2010 à 16:27 +0300, Plamen Petrov a écrit : 
> 
>> The current status: if I enable GRO on the tg3 - the kernel oopses.
>> It just takes a different amount of time to trigger: somewhere from
>> 30 seconds to 30 minutes. 
>> 
>> The oopses looks the same, and here are the latest: 
>> 
>> [picture 13]
>> http://picpaste.com/c8dbda8f5c15d9ce3e050dd7f245f5d0.jpg 
>> 
>> [picture 14]
>> http://picpaste.com/646cca586b704c5b72d3cf9fa54c7344.jpg 
>> 
>> I was wondering which debug options could help us track this down? 
>> 
> 
> Thanks, here is an updated patch (against linux-2.6) 
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 3721fbb..77c8eb7 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1935,6 +1935,32 @@ static inline int skb_needs_linearize(struct sk_buff *skb,
>  					      illegal_highdma(dev, skb))));
>  }
>  
> +int skb_csum_start_bug(const struct sk_buff *skb, int pos)
> +{
> +
> +	if (skb->ip_summed == CHECKSUM_PARTIAL) {
> +		long csstart;
> +
> +		csstart = skb->csum_start - skb_headroom(skb);
> +		if (WARN_ON(csstart > skb_headlen(skb))) {
> +			int i;
> +
> +			pr_err("%d: csum_start %u, offset %u, headroom %d, headlen %d, len %d\n",
> +				   pos, skb->csum_start, skb->csum_offset, skb_headroom(skb),
> +				   skb_headlen(skb), skb->len);
> +			pr_err("nr_frags=%u gso_size=%u ",
> +					skb_shinfo(skb)->nr_frags,
> +					skb_shinfo(skb)->gso_size);
> +			for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> +				pr_err("frag_size=%u ", skb_shinfo(skb)->frags[i].size);
> +			}
> +			pr_err("\n");
> +			return 1;
> +		}
> +	}
> +	return 0;
> +}
> +
>  int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
>  			struct netdev_queue *txq)
>  {
> @@ -1959,11 +1985,15 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
>  				goto out_kfree_skb;
>  			if (skb->next)
>  				goto gso;
> +			if (skb_csum_start_bug(skb, 10))
> +				goto out_kfree_skb;
>  		} else {
>  			if (skb_needs_linearize(skb, dev) &&
>  			    __skb_linearize(skb))
>  				goto out_kfree_skb;
>  
> +			if (skb_csum_start_bug(skb, 20))
> +				goto out_kfree_skb;
>  			/* If packet is not checksummed and device does not
>  			 * support checksumming for this protocol, complete
>  			 * checksumming here.
> @@ -1974,10 +2004,16 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
>  				if (!dev_can_checksum(dev, skb) &&
>  				     skb_checksum_help(skb))
>  					goto out_kfree_skb;
> +				if (skb_csum_start_bug(skb, 30))
> +					goto out_kfree_skb;
>  			}
>  		}
>  
> -		rc = ops->ndo_start_xmit(skb, dev);
> +		if (skb_csum_start_bug(skb, 40)) {
> +			kfree_skb(skb);
> +			rc = NETDEV_TX_OK;
> +		} else
> +			rc = ops->ndo_start_xmit(skb, dev);
>  		if (rc == NETDEV_TX_OK)
>  			txq_trans_update(txq);
>  		return rc;
> @@ -1997,7 +2033,12 @@ gso:
>  		if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
>  			skb_dst_drop(nskb);
>  
> -		rc = ops->ndo_start_xmit(nskb, dev);
> +		if (skb_csum_start_bug(skb, 50)) {
> +			kfree_skb(skb);
> +			rc = NETDEV_TX_OK;
> +		} else
> +			rc = ops->ndo_start_xmit(nskb, dev);
> +
>  		if (unlikely(rc != NETDEV_TX_OK)) {
>  			if (rc & ~NETDEV_TX_MASK)
>  				goto out_kfree_gso_skb;
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 3a2513f..3d54a1b 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1824,13 +1824,15 @@ void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to)
>  {
>  	__wsum csum;
>  	long csstart;
> +	extern int skb_csum_start_bug(const struct sk_buff *skb, int pos);
>  
>  	if (skb->ip_summed == CHECKSUM_PARTIAL)
>  		csstart = skb->csum_start - skb_headroom(skb);
>  	else
>  		csstart = skb_headlen(skb);
>  
> -	BUG_ON(csstart > skb_headlen(skb));
> +	if (skb_csum_start_bug(skb, 100))
> +		return;
>  
>  	skb_copy_from_linear_data(skb, to, csstart);
>   
> 
> 

Above patch applied, and happy to report the machine now spits data
in the logs instead of oopsing. Here is what we have now: 

[   10.721802] Ending clean XFS mount for filesystem: md12
[   11.669013] IPv4 FIB: Using LC-trie version 0.409
[   11.669101] eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
[   11.746792] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[   11.757230] tg3 0000:04:00.0: irq 44 for MSI/MSI-X
[   11.810133] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   11.957523] sixxs_t: Disabled Privacy Extensions
[   14.843711] tg3 0000:04:00.0: eth1: Link is up at 1000 Mbps, full duplex
[   14.843717] tg3 0000:04:00.0: eth1: Flow control is on for TX and on for 
RX
[   14.843753] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   15.854861] tun0: Disabled Privacy Extensions
[  699.375620] ------------[ cut here ]------------
[  699.475648] WARNING: at net/core/dev.c:1945 
skb_csum_start_bug+0x46/0xf2()
[  699.575667] Hardware name: PowerEdge SC440
[  699.675688] Pid: 2963, comm: FahCore_78.exe Not tainted 
2.6.36-rc2-FS-00103-g2d6fa25 #1
[  699.775706] Call Trace:
[  699.975744]  [<c102d86c>] ? warn_slowpath_common+0x67/0x8c
[  700.175779]  [<c12abc76>] ? skb_csum_start_bug+0x46/0xf2
[  700.375813]  [<c12abc76>] ? skb_csum_start_bug+0x46/0xf2
[  700.575848]  [<c102d8ac>] ? warn_slowpath_null+0x1b/0x1f
[  700.775882]  [<c12abc76>] ? skb_csum_start_bug+0x46/0xf2
[  700.975918]  [<c1024569>] ? __wake_up_sync_key+0x3c/0x52
[  701.175953]  [<c12a7bab>] ? skb_copy_and_csum_dev+0x2a/0xaf
[  701.375989]  [<c122483b>] ? rtl8139_start_xmit+0x4a/0x13a
[  701.576026]  [<c12ae29e>] ? dev_hard_start_xmit+0x220/0x4cc
[  701.776062]  [<c12bfbed>] ? sch_direct_xmit+0xac/0x174
[  701.976096]  [<c12c3f69>] ? nf_iterate+0x69/0x7c
[  702.176131]  [<c12e8976>] ? ip_finish_output+0x0/0x2b6
[  702.376165]  [<c12b00eb>] ? dev_queue_xmit+0xc7/0x355
[  702.576198]  [<c12e8976>] ? ip_finish_output+0x0/0x2b6
[  702.776232]  [<c12e8a92>] ? ip_finish_output+0x11c/0x2b6
[  702.976266]  [<c12e8f11>] ? ip_output+0xa4/0xc3
[  703.176299]  [<c12e8976>] ? ip_finish_output+0x0/0x2b6
[  703.376332]  [<c12e4ff9>] ? ip_forward_finish+0x39/0x44
[  703.576365]  [<c12e3a38>] ? ip_rcv_finish+0xe8/0x39f
[  703.776398]  [<c12ad0fd>] ? __netif_receive_skb+0x237/0x2b3
[  703.976431]  [<c12ad70b>] ? netif_receive_skb+0x5f/0x64
[  704.176464]  [<c12ad75e>] ? napi_gro_complete+0x4e/0x94
[  704.376497]  [<c12ada9a>] ? dev_gro_receive+0x158/0x1f5
[  704.576530]  [<c12adc84>] ? napi_gro_receive+0x16/0x1f
[  704.776563]  [<c1217efb>] ? tg3_poll_work+0x5bc/0xbfb
[  704.976597]  [<c1006e50>] ? nommu_sync_single_for_device+0x0/0x1
[  705.176631]  [<c121ce68>] ? tg3_poll+0x43/0x194
[  705.376665]  [<c12ad8b3>] ? net_rx_action+0xcc/0x15b
[  705.576699]  [<c1031cad>] ? __do_softirq+0x7f/0xfa
[  705.776733]  [<c1053dc9>] ? handle_IRQ_event+0x48/0xa6
[  705.976767]  [<c105689b>] ? move_native_irq+0x9/0x3e
[  706.176799]  [<c1031d4f>] ? do_softirq+0x27/0x2a
[  706.376832]  [<c1031e9d>] ? irq_exit+0x63/0x68
[  706.576864]  [<c1003dda>] ? do_IRQ+0x44/0xa1
[  706.776897]  [<c1031e6b>] ? irq_exit+0x31/0x68
[  706.976930]  [<c101654e>] ? smp_apic_timer_interrupt+0x53/0x83
[  707.176963]  [<c1002d29>] ? common_interrupt+0x29/0x30
[  707.276981] ---[ end trace 75e4f8534893c910 ]---
[  707.376998] 100: csum_start 306, offset 16, headroom 390, headlen 70, 
len 70
[  707.477015] nr_frags=0 gso_size=0
[  707.577031]
[ 1012.931455] ------------[ cut here ]------------
[ 1013.031482] WARNING: at net/core/dev.c:1945 
skb_csum_start_bug+0x46/0xf2()
[ 1013.131501] Hardware name: PowerEdge SC440
[ 1013.231521] Pid: 2963, comm: FahCore_78.exe Tainted: G        W   
2.6.36-rc2-FS-00103-g2d6fa25 #1
[ 1013.331538] Call Trace:
[ 1013.531575]  [<c102d86c>] ? warn_slowpath_common+0x67/0x8c
[ 1013.731608]  [<c12abc76>] ? skb_csum_start_bug+0x46/0xf2
[ 1013.931641]  [<c12abc76>] ? skb_csum_start_bug+0x46/0xf2
[ 1014.131675]  [<c102d8ac>] ? warn_slowpath_null+0x1b/0x1f
[ 1014.331708]  [<c12abc76>] ? skb_csum_start_bug+0x46/0xf2
[ 1014.531742]  [<c1024569>] ? __wake_up_sync_key+0x3c/0x52
[ 1014.731775]  [<c12a7bab>] ? skb_copy_and_csum_dev+0x2a/0xaf
[ 1014.931809]  [<c122483b>] ? rtl8139_start_xmit+0x4a/0x13a
[ 1015.131841]  [<c12ae29e>] ? dev_hard_start_xmit+0x220/0x4cc
[ 1015.331875]  [<c12bfbed>] ? sch_direct_xmit+0xac/0x174
[ 1015.531908]  [<c12c3f69>] ? nf_iterate+0x69/0x7c
[ 1015.731941]  [<c12e8976>] ? ip_finish_output+0x0/0x2b6
[ 1015.931973]  [<c12b00eb>] ? dev_queue_xmit+0xc7/0x355
[ 1016.132007]  [<c12e8976>] ? ip_finish_output+0x0/0x2b6
[ 1016.332039]  [<c12e8a92>] ? ip_finish_output+0x11c/0x2b6
[ 1016.532071]  [<c12e8f11>] ? ip_output+0xa4/0xc3
[ 1016.732103]  [<c12e8976>] ? ip_finish_output+0x0/0x2b6
[ 1016.932135]  [<c12e4ff9>] ? ip_forward_finish+0x39/0x44
[ 1017.132166]  [<c12e3a38>] ? ip_rcv_finish+0xe8/0x39f
[ 1017.332198]  [<c12ad0fd>] ? __netif_receive_skb+0x237/0x2b3
[ 1017.532230]  [<c12ad70b>] ? netif_receive_skb+0x5f/0x64
[ 1017.732262]  [<c12ad75e>] ? napi_gro_complete+0x4e/0x94
[ 1017.932294]  [<c12ada9a>] ? dev_gro_receive+0x158/0x1f5
[ 1018.132326]  [<c12adc84>] ? napi_gro_receive+0x16/0x1f
[ 1018.332358]  [<c1217efb>] ? tg3_poll_work+0x5bc/0xbfb
[ 1018.532392]  [<c1006e50>] ? nommu_sync_single_for_device+0x0/0x1
[ 1018.732424]  [<c121ce68>] ? tg3_poll+0x43/0x194
[ 1018.932456]  [<c12ad8b3>] ? net_rx_action+0xcc/0x15b
[ 1019.132489]  [<c1031cad>] ? __do_softirq+0x7f/0xfa
[ 1019.332522]  [<c1053dc9>] ? handle_IRQ_event+0x48/0xa6
[ 1019.532554]  [<c105689b>] ? move_native_irq+0x9/0x3e
[ 1019.732586]  [<c1031d4f>] ? do_softirq+0x27/0x2a
[ 1019.932617]  [<c1031e9d>] ? irq_exit+0x63/0x68
[ 1020.132648]  [<c1003dda>] ? do_IRQ+0x44/0xa1
[ 1020.332680]  [<c1031e6b>] ? irq_exit+0x31/0x68
[ 1020.532713]  [<c101654e>] ? smp_apic_timer_interrupt+0x53/0x83
[ 1020.732745]  [<c1002d29>] ? common_interrupt+0x29/0x30
[ 1020.932777]  [<c1390000>] ? quirk_io_region+0x1c/0x91
[ 1021.032794] ---[ end trace 75e4f8534893c911 ]---
[ 1021.132812] 100: csum_start 306, offset 16, headroom 390, headlen 153, 
len 153
[ 1021.232828] nr_frags=0 gso_size=0
[ 1021.332844] 

Now what? 

Thanks a lot, Eric and Jarek! 

Plamen 

_
___
_____
 ------------------------------------------
This message was sent by the mail server
at fs.ru.acad.bg using the web interface:
    https://fs.ru.acad.bg/s/m/webmail
E-mail postmaster@fs.ru.acad.bg with anything,
regarding the server itself

^ permalink raw reply

* RE: [PATCH net-next-2.6] bna: fix stats handling
From: Debashis Dutt @ 2010-08-24 17:52 UTC (permalink / raw)
  To: Eric Dumazet, David Miller
  Cc: Rasesh Mody, netdev@vger.kernel.org, Akshay Mathur, Jing Huang
In-Reply-To: <1282627901.2378.1451.camel@edumazet-laptop>

Eric, 

Thanks for the patch. We are working on verifying it on our h/w. 
We will get back to you as soon as we are done.

Thanks
--Debashis

-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com] 
Sent: Monday, August 23, 2010 10:32 PM
To: David Miller
Cc: Rasesh Mody; netdev@vger.kernel.org; Akshay Mathur; Debashis Dutt; Jing Huang
Subject: [PATCH net-next-2.6] bna: fix stats handling

Brocade guys, could you please test the following patch on your
hardware ?

Thanks

[PATCH net-next-2.6] bna: fix stats handling

get_stats() method incorrectly clears a global array before folding
various stats. This can break SNMP applications.

Switch to 64 bit flavor to work on a user supplied buffer, and provide
64bit counters even on 32bit arches.

Fix a bug in bnad_netdev_hwstats_fill(), for rx_fifo_errors, missing a
folding (only the last counter was taken into account)

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 drivers/net/bna/bnad.c         |   52 ++++++++++++++-----------------
 drivers/net/bna/bnad.h         |    5 +-
 drivers/net/bna/bnad_ethtool.c |   17 ++++------
 3 files changed, 33 insertions(+), 41 deletions(-)

diff --git a/drivers/net/bna/bnad.c b/drivers/net/bna/bnad.c
index 491d148..a935b96 100644
--- a/drivers/net/bna/bnad.c
+++ b/drivers/net/bna/bnad.c
@@ -1964,25 +1964,24 @@ bnad_enable_default_bcast(struct bnad *bnad)
 
 /* Statistics utilities */
 void
-bnad_netdev_qstats_fill(struct bnad *bnad)
+bnad_netdev_qstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats)
 {
-	struct net_device_stats *net_stats = &bnad->net_stats;
 	int i, j;
 
 	for (i = 0; i < bnad->num_rx; i++) {
 		for (j = 0; j < bnad->num_rxp_per_rx; j++) {
 			if (bnad->rx_info[i].rx_ctrl[j].ccb) {
-				net_stats->rx_packets += bnad->rx_info[i].
+				stats->rx_packets += bnad->rx_info[i].
 				rx_ctrl[j].ccb->rcb[0]->rxq->rx_packets;
-				net_stats->rx_bytes += bnad->rx_info[i].
+				stats->rx_bytes += bnad->rx_info[i].
 					rx_ctrl[j].ccb->rcb[0]->rxq->rx_bytes;
 				if (bnad->rx_info[i].rx_ctrl[j].ccb->rcb[1] &&
 					bnad->rx_info[i].rx_ctrl[j].ccb->
 					rcb[1]->rxq) {
-					net_stats->rx_packets +=
+					stats->rx_packets +=
 						bnad->rx_info[i].rx_ctrl[j].
 						ccb->rcb[1]->rxq->rx_packets;
-					net_stats->rx_bytes +=
+					stats->rx_bytes +=
 						bnad->rx_info[i].rx_ctrl[j].
 						ccb->rcb[1]->rxq->rx_bytes;
 				}
@@ -1992,9 +1991,9 @@ bnad_netdev_qstats_fill(struct bnad *bnad)
 	for (i = 0; i < bnad->num_tx; i++) {
 		for (j = 0; j < bnad->num_txq_per_tx; j++) {
 			if (bnad->tx_info[i].tcb[j]) {
-				net_stats->tx_packets +=
+				stats->tx_packets +=
 				bnad->tx_info[i].tcb[j]->txq->tx_packets;
-				net_stats->tx_bytes +=
+				stats->tx_bytes +=
 					bnad->tx_info[i].tcb[j]->txq->tx_bytes;
 			}
 		}
@@ -2005,37 +2004,36 @@ bnad_netdev_qstats_fill(struct bnad *bnad)
  * Must be called with the bna_lock held.
  */
 void
-bnad_netdev_hwstats_fill(struct bnad *bnad)
+bnad_netdev_hwstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats)
 {
 	struct bfi_ll_stats_mac *mac_stats;
-	struct net_device_stats *net_stats = &bnad->net_stats;
 	u64 bmap;
 	int i;
 
 	mac_stats = &bnad->stats.bna_stats->hw_stats->mac_stats;
-	net_stats->rx_errors =
+	stats->rx_errors =
 		mac_stats->rx_fcs_error + mac_stats->rx_alignment_error +
 		mac_stats->rx_frame_length_error + mac_stats->rx_code_error +
 		mac_stats->rx_undersize;
-	net_stats->tx_errors = mac_stats->tx_fcs_error +
+	stats->tx_errors = mac_stats->tx_fcs_error +
 					mac_stats->tx_undersize;
-	net_stats->rx_dropped = mac_stats->rx_drop;
-	net_stats->tx_dropped = mac_stats->tx_drop;
-	net_stats->multicast = mac_stats->rx_multicast;
-	net_stats->collisions = mac_stats->tx_total_collision;
+	stats->rx_dropped = mac_stats->rx_drop;
+	stats->tx_dropped = mac_stats->tx_drop;
+	stats->multicast = mac_stats->rx_multicast;
+	stats->collisions = mac_stats->tx_total_collision;
 
-	net_stats->rx_length_errors = mac_stats->rx_frame_length_error;
+	stats->rx_length_errors = mac_stats->rx_frame_length_error;
 
 	/* receive ring buffer overflow  ?? */
 
-	net_stats->rx_crc_errors = mac_stats->rx_fcs_error;
-	net_stats->rx_frame_errors = mac_stats->rx_alignment_error;
+	stats->rx_crc_errors = mac_stats->rx_fcs_error;
+	stats->rx_frame_errors = mac_stats->rx_alignment_error;
 	/* recv'r fifo overrun */
 	bmap = (u64)bnad->stats.bna_stats->rxf_bmap[0] |
 		((u64)bnad->stats.bna_stats->rxf_bmap[1] << 32);
 	for (i = 0; bmap && (i < BFI_LL_RXF_ID_MAX); i++) {
 		if (bmap & 1) {
-			net_stats->rx_fifo_errors =
+			stats->rx_fifo_errors +=
 				bnad->stats.bna_stats->
 					hw_stats->rxf_stats[i].frame_drops;
 			break;
@@ -2638,22 +2636,20 @@ bnad_start_xmit(struct sk_buff *skb, struct net_device *netdev)
  * Used spin_lock to synchronize reading of stats structures, which
  * is written by BNA under the same lock.
  */
-static struct net_device_stats *
-bnad_get_netdev_stats(struct net_device *netdev)
+static struct rtnl_link_stats64 *
+bnad_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 *stats)
 {
 	struct bnad *bnad = netdev_priv(netdev);
 	unsigned long flags;
 
 	spin_lock_irqsave(&bnad->bna_lock, flags);
 
-	memset(&bnad->net_stats, 0, sizeof(struct net_device_stats));
-
-	bnad_netdev_qstats_fill(bnad);
-	bnad_netdev_hwstats_fill(bnad);
+	bnad_netdev_qstats_fill(bnad, stats);
+	bnad_netdev_hwstats_fill(bnad, stats);
 
 	spin_unlock_irqrestore(&bnad->bna_lock, flags);
 
-	return &bnad->net_stats;
+	return stats;
 }
 
 static void
@@ -2858,7 +2854,7 @@ static const struct net_device_ops bnad_netdev_ops = {
 	.ndo_open		= bnad_open,
 	.ndo_stop		= bnad_stop,
 	.ndo_start_xmit		= bnad_start_xmit,
-	.ndo_get_stats		= bnad_get_netdev_stats,
+	.ndo_get_stats64	= bnad_get_stats64,
 	.ndo_set_rx_mode	= bnad_set_rx_mode,
 	.ndo_set_multicast_list = bnad_set_rx_mode,
 	.ndo_validate_addr      = eth_validate_addr,
diff --git a/drivers/net/bna/bnad.h b/drivers/net/bna/bnad.h
index 3261401..ee37788 100644
--- a/drivers/net/bna/bnad.h
+++ b/drivers/net/bna/bnad.h
@@ -273,7 +273,6 @@ struct bnad {
 
 	/* Statistics */
 	struct bnad_stats stats;
-	struct net_device_stats net_stats;
 
 	struct bnad_diag *diag;
 
@@ -308,8 +307,8 @@ extern void bnad_cleanup_rx(struct bnad *bnad, uint rx_id);
 extern void bnad_dim_timer_start(struct bnad *bnad);
 
 /* Statistics */
-extern void bnad_netdev_qstats_fill(struct bnad *bnad);
-extern void bnad_netdev_hwstats_fill(struct bnad *bnad);
+extern void bnad_netdev_qstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats);
+extern void bnad_netdev_hwstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats);
 
 /**
  * MACROS
diff --git a/drivers/net/bna/bnad_ethtool.c b/drivers/net/bna/bnad_ethtool.c
index 7e630f5..1f0c124 100644
--- a/drivers/net/bna/bnad_ethtool.c
+++ b/drivers/net/bna/bnad_ethtool.c
@@ -34,7 +34,7 @@
 #define BNAD_NUM_TXQ_COUNTERS 5
 
 #define BNAD_ETHTOOL_STATS_NUM						\
-	(sizeof(struct net_device_stats) / sizeof(unsigned long) +	\
+	(sizeof(struct rtnl_link_stats64) / sizeof(u64) +	\
 	sizeof(struct bnad_drv_stats) / sizeof(u64) +		\
 	offsetof(struct bfi_ll_stats, rxf_stats[0]) / sizeof(u64))
 
@@ -1159,7 +1159,8 @@ bnad_get_ethtool_stats(struct net_device *netdev, struct ethtool_stats *stats,
 {
 	struct bnad *bnad = netdev_priv(netdev);
 	int i, j, bi;
-	unsigned long *net_stats, flags;
+	unsigned long flags;
+	struct rtnl_link_stats64 *net_stats64;
 	u64 *stats64;
 	u64 bmap;
 
@@ -1176,16 +1177,12 @@ bnad_get_ethtool_stats(struct net_device *netdev, struct ethtool_stats *stats,
 	spin_lock_irqsave(&bnad->bna_lock, flags);
 	bi = 0;
 	memset(buf, 0, stats->n_stats * sizeof(u64));
-	memset(&bnad->net_stats, 0, sizeof(struct net_device_stats));
 
-	bnad_netdev_qstats_fill(bnad);
-	bnad_netdev_hwstats_fill(bnad);
+	net_stats64 = (struct rtnl_link_stats64 *)buf;
+	bnad_netdev_qstats_fill(bnad, net_stats64);
+	bnad_netdev_hwstats_fill(bnad, net_stats64);
 
-	/* Fill net_stats into ethtool buffers */
-	net_stats = (unsigned long *)&bnad->net_stats;
-	for (i = 0; i < sizeof(struct net_device_stats) / sizeof(unsigned long);
-	     i++)
-		buf[bi++] = net_stats[i];
+	bi = sizeof(*net_stats64) / sizeof(u64);
 
 	/* Fill driver stats into ethtool buffers */
 	stats64 = (u64 *)&bnad->stats.drv_stats;



^ permalink raw reply related

* Re: RFC: MTU for serving NFS on Infiniband
From: Ben Hutchings @ 2010-08-24 17:57 UTC (permalink / raw)
  To: Marc Aurele La France
  Cc: Stephen Hemminger, linux-kernel, netdev, David S. Miller,
	Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
	Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <alpine.WNT.2.00.1008240856170.2000@cluij.ucs.ualberta.ca>

On Tue, 2010-08-24 at 09:14 -0600, Marc Aurele La France wrote:
> On Mon, 23 Aug 2010, Stephen Hemminger wrote:
> > On Mon, 23 Aug 2010 08:44:37 -0600 (MDT)
> > Marc Aurele La France <tsi@ualberta.ca> wrote:
> >> In regrouping for my next tack at this, I noticed that all stack traces go
> >> through ip_append_data().  This would be ipv6_append_data() in the IPv6 case.
> >> A _very_ rough draft that would have ip_append_data() temporarily drop down
> >> to a smaller fake MTU follows ...
> 
> > Why doesn't NFS generate page size fragments?  Does Infiniband or your
> > device not support this?  Any thing that requires higher order allocation
> > is going to unstable under load.  Let's fix the cause not the apply bandaid
> > solution to the symptom.
> 
> From what I can tell, IP fragmentation is done centrally.
[...]

Stephen and I are not talking about IP fragmentation, but about the
ability to append 'fragments' to an skb rather than putting the entire
packet payload in a linear buffer.  See
<http://vger.kernel.org/~davem/skb_data.html>.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply

* Re: 2.6.34.1 page allocation failure
From: Pekka Enberg @ 2010-08-24 18:03 UTC (permalink / raw)
  To: Stan Hoeppner
  Cc: Christoph Lameter, Mikael Abrahamsson, Linux Kernel List,
	linux-mm, Mel Gorman, Linux Netdev List
In-Reply-To: <4C72F7C6.3020109@hardwarefreak.com>

  [ I'm CC'ing netdev. ]

On 24.8.2010 1.35, Stan Hoeppner wrote:
> Pekka Enberg put forth on 8/23/2010 4:37 AM:
>>   On 8/23/10 1:40 AM, Christoph Lameter wrote:
>>> On Sun, 22 Aug 2010, Pekka Enberg wrote:
>>>
>>>> In Stan's case, it's a order-1 GFP_ATOMIC allocation but there are
>>>> only order-0 pages available. Mel, any recent page allocator fixes in
>>>> 2.6.35 or 2.6.36-rc1 that Stan/Mikael should test?
>>> This is the TCP slab? Best fix would be in the page allocator. However,
>>> in this particular case the slub allocator would be able to fall back to
>>> an order 0 allocation and still satisfy the request.
>> Looking at the stack trace of the oops, I think Stan has CONFIG_SLAB
>> which doesn't have order-0 fallback.
> That is correct.  The menuconfig help screen led me to believe the SLAB
> allocator was the "safe" choice:
>
> "CONFIG_SLAB:
> The regular slab allocator that is established and known to work well in
> all environments"
>
> Should I be using SLUB instead?  Any downsides to SLUB on an old and
> slow (500 MHz) single core dual CPU box with<512MB RAM?
I don't think the problem here is SLAB so it shouldn't matter which one 
you use. You might not see the problems with SLUB, though, because it 
falls back to 0-order allocations.
> Also, what is the impact of these oopses?  Despite the entries in dmesg,
> the system "seems" to be running ok.  Or is this simply the calm before
> the impending storm?
The page allocation failure in question is this:

kswapd0: page allocation failure. order:1, mode:0x20
Pid: 139, comm: kswapd0 Not tainted 2.6.34.1 #1
Call Trace:
  [<c104b6b3>] ? __alloc_pages_nodemask+0x448/0x48a
  [<c1062ffb>] ? cache_alloc_refill+0x22f/0x422
  [<c11a9a73>] ? tcp_v4_send_check+0x6e/0xa4
  [<c10632c3>] ? kmem_cache_alloc+0x41/0x6a
  [<c11773a5>] ? sk_prot_alloc+0x19/0x55
  [<c117744b>] ? sk_clone+0x16/0x1cc
  [<c119a71d>] ? inet_csk_clone+0xf/0x80
  [<c11ac0e3>] ? tcp_create_openreq_child+0x1a/0x3c8
  [<c11aaf0a>] ? tcp_v4_syn_recv_sock+0x4b/0x151
  [<c11abf9d>] ? tcp_check_req+0x209/0x335
  [<c11aa892>] ? tcp_v4_do_rcv+0x8d/0x14d
  [<c11aacd5>] ? tcp_v4_rcv+0x383/0x56d
  [<c1193ba4>] ? ip_local_deliver+0x76/0xc0
  [<c1193b10>] ? ip_rcv+0x3dc/0x3fa
  [<c103655e>] ? ktime_get_real+0xf/0x2b
  [<c117f8d3>] ? netif_receive_skb+0x219/0x234
  [<c115ff46>] ? e100_poll+0x1d0/0x47e
  [<c117fa98>] ? net_rx_action+0x58/0xf8
  [<c102539c>] ? __do_softirq+0x78/0xe5
  [<c102542c>] ? do_softirq+0x23/0x27
  [<c1003955>] ? do_IRQ+0x7d/0x8e
  [<c1002aa9>] ? common_interrupt+0x29/0x30
  [<c1062870>] ? kmem_cache_free+0xbd/0xc5
  [<c10fa7d1>] ? __xfs_inode_set_reclaim_tag+0x29/0x2f
  [<c1075215>] ? destroy_inode+0x1c/0x2b
  [<c10752ce>] ? dispose_list+0xaa/0xd0
  [<c107548c>] ? shrink_icache_memory+0x198/0x1c5
  [<c104f76b>] ? shrink_slab+0xda/0x12f
  [<c104fc28>] ? kswapd+0x468/0x63b
  [<c104dca3>] ? isolate_pages_global+0x0/0x1bc
  [<c10304d6>] ? autoremove_wake_function+0x0/0x2d
  [<c1018faf>] ? complete+0x28/0x36
  [<c104f7c0>] ? kswapd+0x0/0x63b
  [<c10301cd>] ? kthread+0x61/0x66
  [<c103016c>] ? kthread+0x0/0x66
  [<c1002ab6>] ? kernel_thread_helper+0x6/0x10

It looks to me as if tcp_create_openreq_child() is able to cope with the 
situation so the warning could be harmless. If that's the case, we 
should probably stick a __GFP_NOWARN there.

                 Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH] tc: add meta match on receive hash
From: Stephen Hemminger @ 2010-08-24 18:14 UTC (permalink / raw)
  To: David Miller; +Cc: xiaosuo, hadi, tgraf, netdev
In-Reply-To: <20100823.204422.85408087.davem@davemloft.net>

Trivial extension to existing meta data match rules to allow
matching on skb receive hash value.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
This versions uses skb_get_rxhash()

--- a/include/linux/tc_ematch/tc_em_meta.h	2010-08-24 08:35:29.555651482 -0700
+++ b/include/linux/tc_ematch/tc_em_meta.h	2010-08-24 08:36:51.038237590 -0700
@@ -79,6 +79,7 @@ enum {
  	TCF_META_ID_SK_SENDMSG_OFF,
  	TCF_META_ID_SK_WRITE_PENDING,
 	TCF_META_ID_VLAN_TAG,
+	TCF_META_ID_RXHASH,
 	__TCF_META_ID_MAX
 };
 #define TCF_META_ID_MAX (__TCF_META_ID_MAX - 1)
--- a/net/sched/em_meta.c	2010-08-24 08:35:29.535662209 -0700
+++ b/net/sched/em_meta.c	2010-08-24 08:38:07.191510604 -0700
@@ -223,6 +223,11 @@ META_COLLECTOR(int_maclen)
 	dst->value = skb->mac_len;
 }
 
+META_COLLECTOR(int_rxhash)
+{
+	dst->value = skb_get_rxhash(skb);
+}
+
 /**************************************************************************
  * Netfilter
  **************************************************************************/
@@ -541,6 +546,7 @@ static struct meta_ops __meta_ops[TCF_ME
 		[META_ID(SK_SENDMSG_OFF)]	= META_FUNC(int_sk_sendmsg_off),
 		[META_ID(SK_WRITE_PENDING)]	= META_FUNC(int_sk_write_pend),
 		[META_ID(VLAN_TAG)]		= META_FUNC(int_vlan_tag),
+		[META_ID(RXHASH)]		= META_FUNC(int_rxhash),
 	}
 };
 

^ permalink raw reply

* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Jarek Poplawski @ 2010-08-24 18:22 UTC (permalink / raw)
  To: Plamen Petrov
  Cc: Eric Dumazet, Andrew Morton, netdev, bugzilla-daemon,
	bugme-daemon
In-Reply-To: <courier.4C74007C.00000EE4@fs.ru.acad.bg>

On Tue, Aug 24, 2010 at 08:25:16PM +0300, Plamen Petrov wrote:
> Eric Dumazet ????????????:
...
> 
> Now what?

Good question. IMHO it looks like skbs are overwritten, so better turn
off gro until some next patch.

> 
> Thanks a lot, Eric and Jarek!

Thanks a lot, Plamen and Eric, too!

Jarek P.

^ permalink raw reply

* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Stephan Gatzka @ 2010-08-24 18:30 UTC (permalink / raw)
  To: john stultz
  Cc: Richard Cochran, Rodolfo Giometti, Arnd Bergmann, netdev,
	devicetree-discuss, linux-kernel, linuxppc-dev, linux-arm-kernel,
	Krzysztof Halasa
In-Reply-To: <1282594125.3111.344.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Hello!

> I'm curious if its possible to do the PTP hardware offset/adjustment
> calculation in a module internally to the kernel? That would allow the
> PPS interface to still be used to sync the system time, and not expose
> additional interfaces.
Just my 2 cents on this issue. PTP is very often used in embedded 
systems, where the PTP timestamps will go into some dedicated hardware, 
for instance an FPGA.

I'm currently working on a project where it is not necessary to adjust 
the Linux system time via PTP (although it would be a nice to have), but 
we only need the timestamps from the PHY to put them into our FPGA 
device. So we need some kind of API to access the PTP timestamp registers.

Kind regards,

Stephan


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5136 bytes --]

^ permalink raw reply

* RE: [PATCH net-next-2.6] bna: fix stats handling
From: Rasesh Mody @ 2010-08-24 18:49 UTC (permalink / raw)
  To: Eric Dumazet, David Miller
  Cc: netdev@vger.kernel.org, Akshay Mathur, Debashis Dutt, Jing Huang
In-Reply-To: <1282627901.2378.1451.camel@edumazet-laptop>

Eric,

We tried applying the patch to the source, it looks corrupted. Can you please resubmit the patch?

Thanks,
Rasesh

-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com] 
Sent: Monday, August 23, 2010 10:32 PM
To: David Miller
Cc: Rasesh Mody; netdev@vger.kernel.org; Akshay Mathur; Debashis Dutt; Jing Huang
Subject: [PATCH net-next-2.6] bna: fix stats handling

Brocade guys, could you please test the following patch on your
hardware ?

Thanks

[PATCH net-next-2.6] bna: fix stats handling

get_stats() method incorrectly clears a global array before folding
various stats. This can break SNMP applications.

Switch to 64 bit flavor to work on a user supplied buffer, and provide
64bit counters even on 32bit arches.

Fix a bug in bnad_netdev_hwstats_fill(), for rx_fifo_errors, missing a
folding (only the last counter was taken into account)

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 drivers/net/bna/bnad.c         |   52 ++++++++++++++-----------------
 drivers/net/bna/bnad.h         |    5 +-
 drivers/net/bna/bnad_ethtool.c |   17 ++++------
 3 files changed, 33 insertions(+), 41 deletions(-)

diff --git a/drivers/net/bna/bnad.c b/drivers/net/bna/bnad.c
index 491d148..a935b96 100644
--- a/drivers/net/bna/bnad.c
+++ b/drivers/net/bna/bnad.c
@@ -1964,25 +1964,24 @@ bnad_enable_default_bcast(struct bnad *bnad)
 
 /* Statistics utilities */
 void
-bnad_netdev_qstats_fill(struct bnad *bnad)
+bnad_netdev_qstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats)
 {
-	struct net_device_stats *net_stats = &bnad->net_stats;
 	int i, j;
 
 	for (i = 0; i < bnad->num_rx; i++) {
 		for (j = 0; j < bnad->num_rxp_per_rx; j++) {
 			if (bnad->rx_info[i].rx_ctrl[j].ccb) {
-				net_stats->rx_packets += bnad->rx_info[i].
+				stats->rx_packets += bnad->rx_info[i].
 				rx_ctrl[j].ccb->rcb[0]->rxq->rx_packets;
-				net_stats->rx_bytes += bnad->rx_info[i].
+				stats->rx_bytes += bnad->rx_info[i].
 					rx_ctrl[j].ccb->rcb[0]->rxq->rx_bytes;
 				if (bnad->rx_info[i].rx_ctrl[j].ccb->rcb[1] &&
 					bnad->rx_info[i].rx_ctrl[j].ccb->
 					rcb[1]->rxq) {
-					net_stats->rx_packets +=
+					stats->rx_packets +=
 						bnad->rx_info[i].rx_ctrl[j].
 						ccb->rcb[1]->rxq->rx_packets;
-					net_stats->rx_bytes +=
+					stats->rx_bytes +=
 						bnad->rx_info[i].rx_ctrl[j].
 						ccb->rcb[1]->rxq->rx_bytes;
 				}
@@ -1992,9 +1991,9 @@ bnad_netdev_qstats_fill(struct bnad *bnad)
 	for (i = 0; i < bnad->num_tx; i++) {
 		for (j = 0; j < bnad->num_txq_per_tx; j++) {
 			if (bnad->tx_info[i].tcb[j]) {
-				net_stats->tx_packets +=
+				stats->tx_packets +=
 				bnad->tx_info[i].tcb[j]->txq->tx_packets;
-				net_stats->tx_bytes +=
+				stats->tx_bytes +=
 					bnad->tx_info[i].tcb[j]->txq->tx_bytes;
 			}
 		}
@@ -2005,37 +2004,36 @@ bnad_netdev_qstats_fill(struct bnad *bnad)
  * Must be called with the bna_lock held.
  */
 void
-bnad_netdev_hwstats_fill(struct bnad *bnad)
+bnad_netdev_hwstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats)
 {
 	struct bfi_ll_stats_mac *mac_stats;
-	struct net_device_stats *net_stats = &bnad->net_stats;
 	u64 bmap;
 	int i;
 
 	mac_stats = &bnad->stats.bna_stats->hw_stats->mac_stats;
-	net_stats->rx_errors =
+	stats->rx_errors =
 		mac_stats->rx_fcs_error + mac_stats->rx_alignment_error +
 		mac_stats->rx_frame_length_error + mac_stats->rx_code_error +
 		mac_stats->rx_undersize;
-	net_stats->tx_errors = mac_stats->tx_fcs_error +
+	stats->tx_errors = mac_stats->tx_fcs_error +
 					mac_stats->tx_undersize;
-	net_stats->rx_dropped = mac_stats->rx_drop;
-	net_stats->tx_dropped = mac_stats->tx_drop;
-	net_stats->multicast = mac_stats->rx_multicast;
-	net_stats->collisions = mac_stats->tx_total_collision;
+	stats->rx_dropped = mac_stats->rx_drop;
+	stats->tx_dropped = mac_stats->tx_drop;
+	stats->multicast = mac_stats->rx_multicast;
+	stats->collisions = mac_stats->tx_total_collision;
 
-	net_stats->rx_length_errors = mac_stats->rx_frame_length_error;
+	stats->rx_length_errors = mac_stats->rx_frame_length_error;
 
 	/* receive ring buffer overflow  ?? */
 
-	net_stats->rx_crc_errors = mac_stats->rx_fcs_error;
-	net_stats->rx_frame_errors = mac_stats->rx_alignment_error;
+	stats->rx_crc_errors = mac_stats->rx_fcs_error;
+	stats->rx_frame_errors = mac_stats->rx_alignment_error;
 	/* recv'r fifo overrun */
 	bmap = (u64)bnad->stats.bna_stats->rxf_bmap[0] |
 		((u64)bnad->stats.bna_stats->rxf_bmap[1] << 32);
 	for (i = 0; bmap && (i < BFI_LL_RXF_ID_MAX); i++) {
 		if (bmap & 1) {
-			net_stats->rx_fifo_errors =
+			stats->rx_fifo_errors +=
 				bnad->stats.bna_stats->
 					hw_stats->rxf_stats[i].frame_drops;
 			break;
@@ -2638,22 +2636,20 @@ bnad_start_xmit(struct sk_buff *skb, struct net_device *netdev)
  * Used spin_lock to synchronize reading of stats structures, which
  * is written by BNA under the same lock.
  */
-static struct net_device_stats *
-bnad_get_netdev_stats(struct net_device *netdev)
+static struct rtnl_link_stats64 *
+bnad_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 *stats)
 {
 	struct bnad *bnad = netdev_priv(netdev);
 	unsigned long flags;
 
 	spin_lock_irqsave(&bnad->bna_lock, flags);
 
-	memset(&bnad->net_stats, 0, sizeof(struct net_device_stats));
-
-	bnad_netdev_qstats_fill(bnad);
-	bnad_netdev_hwstats_fill(bnad);
+	bnad_netdev_qstats_fill(bnad, stats);
+	bnad_netdev_hwstats_fill(bnad, stats);
 
 	spin_unlock_irqrestore(&bnad->bna_lock, flags);
 
-	return &bnad->net_stats;
+	return stats;
 }
 
 static void
@@ -2858,7 +2854,7 @@ static const struct net_device_ops bnad_netdev_ops = {
 	.ndo_open		= bnad_open,
 	.ndo_stop		= bnad_stop,
 	.ndo_start_xmit		= bnad_start_xmit,
-	.ndo_get_stats		= bnad_get_netdev_stats,
+	.ndo_get_stats64	= bnad_get_stats64,
 	.ndo_set_rx_mode	= bnad_set_rx_mode,
 	.ndo_set_multicast_list = bnad_set_rx_mode,
 	.ndo_validate_addr      = eth_validate_addr,
diff --git a/drivers/net/bna/bnad.h b/drivers/net/bna/bnad.h
index 3261401..ee37788 100644
--- a/drivers/net/bna/bnad.h
+++ b/drivers/net/bna/bnad.h
@@ -273,7 +273,6 @@ struct bnad {
 
 	/* Statistics */
 	struct bnad_stats stats;
-	struct net_device_stats net_stats;
 
 	struct bnad_diag *diag;
 
@@ -308,8 +307,8 @@ extern void bnad_cleanup_rx(struct bnad *bnad, uint rx_id);
 extern void bnad_dim_timer_start(struct bnad *bnad);
 
 /* Statistics */
-extern void bnad_netdev_qstats_fill(struct bnad *bnad);
-extern void bnad_netdev_hwstats_fill(struct bnad *bnad);
+extern void bnad_netdev_qstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats);
+extern void bnad_netdev_hwstats_fill(struct bnad *bnad, struct rtnl_link_stats64 *stats);
 
 /**
  * MACROS
diff --git a/drivers/net/bna/bnad_ethtool.c b/drivers/net/bna/bnad_ethtool.c
index 7e630f5..1f0c124 100644
--- a/drivers/net/bna/bnad_ethtool.c
+++ b/drivers/net/bna/bnad_ethtool.c
@@ -34,7 +34,7 @@
 #define BNAD_NUM_TXQ_COUNTERS 5
 
 #define BNAD_ETHTOOL_STATS_NUM						\
-	(sizeof(struct net_device_stats) / sizeof(unsigned long) +	\
+	(sizeof(struct rtnl_link_stats64) / sizeof(u64) +	\
 	sizeof(struct bnad_drv_stats) / sizeof(u64) +		\
 	offsetof(struct bfi_ll_stats, rxf_stats[0]) / sizeof(u64))
 
@@ -1159,7 +1159,8 @@ bnad_get_ethtool_stats(struct net_device *netdev, struct ethtool_stats *stats,
 {
 	struct bnad *bnad = netdev_priv(netdev);
 	int i, j, bi;
-	unsigned long *net_stats, flags;
+	unsigned long flags;
+	struct rtnl_link_stats64 *net_stats64;
 	u64 *stats64;
 	u64 bmap;
 
@@ -1176,16 +1177,12 @@ bnad_get_ethtool_stats(struct net_device *netdev, struct ethtool_stats *stats,
 	spin_lock_irqsave(&bnad->bna_lock, flags);
 	bi = 0;
 	memset(buf, 0, stats->n_stats * sizeof(u64));
-	memset(&bnad->net_stats, 0, sizeof(struct net_device_stats));
 
-	bnad_netdev_qstats_fill(bnad);
-	bnad_netdev_hwstats_fill(bnad);
+	net_stats64 = (struct rtnl_link_stats64 *)buf;
+	bnad_netdev_qstats_fill(bnad, net_stats64);
+	bnad_netdev_hwstats_fill(bnad, net_stats64);
 
-	/* Fill net_stats into ethtool buffers */
-	net_stats = (unsigned long *)&bnad->net_stats;
-	for (i = 0; i < sizeof(struct net_device_stats) / sizeof(unsigned long);
-	     i++)
-		buf[bi++] = net_stats[i];
+	bi = sizeof(*net_stats64) / sizeof(u64);
 
 	/* Fill driver stats into ethtool buffers */
 	stats64 = (u64 *)&bnad->stats.drv_stats;



^ permalink raw reply related

* RE: [PATCH net-next-2.6] bna: fix stats handling
From: Eric Dumazet @ 2010-08-24 19:06 UTC (permalink / raw)
  To: Rasesh Mody
  Cc: David Miller, netdev@vger.kernel.org, Akshay Mathur,
	Debashis Dutt, Jing Huang
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A4AE225D69@HQ1-EXCH01.corp.brocade.com>

Le mardi 24 août 2010 à 11:49 -0700, Rasesh Mody a écrit :
> Eric,
> 
> We tried applying the patch to the source, it looks corrupted. Can you please resubmit the patch?

Hmm... could you tell me how it is corrupted ?



^ permalink raw reply

* Re: 2.6.34.1 page allocation failure
From: Stan Hoeppner @ 2010-08-24 19:08 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Christoph Lameter, Mikael Abrahamsson, Linux Kernel List,
	linux-mm, Mel Gorman, Linux Netdev List
In-Reply-To: <4C74097A.5020504@kernel.org>

Pekka Enberg put forth on 8/24/2010 1:03 PM:

> It looks to me as if tcp_create_openreq_child() is able to cope with the
> situation so the warning could be harmless. If that's the case, we
> should probably stick a __GFP_NOWARN there.

If it would be helpful, here's a complete copy of dmesg:
http://www.hardwarefreak.com/2.6.34.1-dmesg-oopses.txt

Something I forgot to mention earlier is that every now and then I
unmount swap and drop caches to clear things out a bit.  Not sure if
that may be relevant, but since it has to do with memory allocation I
thought I'd mention it.

-- 
Stan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: kernel hangs when removing a dummy netdev with an attached macvlan
From: Daniel Lezcano @ 2010-08-24 19:14 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1282669312.2477.262.camel@edumazet-laptop>

On 08/24/2010 07:01 PM, Eric Dumazet wrote:
> Le mardi 24 août 2010 à 18:32 +0200, Daniel Lezcano a écrit :
>    
>> Hi all,
>>
>> I noticed the kernel hangs when we create a dummy interface, assign a
>> macvlan on it and then delete the dummy interface.
>>
>> How to reproduce:
>>
>>    ip link add dummy0 type dummy
>>    ip link add mc0 link dummy0 type macvlan
>>    ip link del dummy0
>>
>>      
> Strange, I could not reproduce it with linux-2.6 current tree
>    

Right, I was not up to date. The bug does no longer appear with the 
net-next-2.6 git head.

Sorry for the noise.

   -- Daniel

^ permalink raw reply

* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Eric Dumazet @ 2010-08-24 19:19 UTC (permalink / raw)
  To: Plamen Petrov
  Cc: Jarek Poplawski, Andrew Morton, netdev, bugzilla-daemon,
	bugme-daemon
In-Reply-To: <courier.4C74007C.00000EE4@fs.ru.acad.bg>

Le mardi 24 août 2010 à 20:25 +0300, Plamen Petrov a écrit :
> Above patch applied, and happy to report the machine now spits data
> in the logs instead of oopsing. Here is what we have now: 
> [  707.276981] ---[ end trace 75e4f8534893c910 ]---
> [  707.376998] 100: csum_start 306, offset 16, headroom 390, headlen 70, 
> len 70
> [  707.477015] nr_frags=0 gso_size=0
> [  707.577031]
> [ 1021.032794] ---[ end trace 75e4f8534893c911 ]---
> [ 1021.132812] 100: csum_start 306, offset 16, headroom 390, headlen 153, 
> len 153
> [ 1021.232828] nr_frags=0 gso_size=0
> [ 1021.332844] 
> 

Thanks !

csum_offset = 16.

so its offsetof(struct tcphdr, check)

maybe a bug in net/ipv4/netfilter/nf_nat_helper.c ?

We should trace all spots where we set csum_start/csum_offset

Or/And trace the skb content.

Please add a :

print_hex_dump(KERN_ERR, "skb data:", DUMP_PREFIX_OFFSET, 
               16, 1, skb->head, skb_end_pointer(skb)-skb->head,true);


call in skb_csum_start_bug(), right after the pr_err("\n") and before
the "return 1;"


int skb_csum_start_bug(const struct sk_buff *skb, int pos)
{

        if (skb->ip_summed == CHECKSUM_PARTIAL) {
                long csstart;

                csstart = skb->csum_start - skb_headroom(skb);
                if (WARN_ON(csstart > skb_headlen(skb))) {
                        int i;

                        pr_err("%d: csum_start %u, offset %u, headroom %d, headlen %d, len %d\n",
                                   pos, skb->csum_start, skb->csum_offset, skb_headroom(skb),
                                   skb_headlen(skb), skb->len);
                        pr_err("nr_frags=%u gso_size=%u ",
                                        skb_shinfo(skb)->nr_frags,
                                        skb_shinfo(skb)->gso_size);
                        for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
                                pr_err("frag_size=%u ", skb_shinfo(skb)->frags[i].size);
                        }
                        pr_err("\n");
                        print_hex_dump(KERN_ERR, "skb data:", DUMP_PREFIX_OFFSET,
                                16, 1, skb->head, skb_end_pointer(skb) - skb->head, true);
                        return 1;
                }
        }
        return 0;
}



^ permalink raw reply

* Re: 2.6.34.1 page allocation failure
From: Mikael Abrahamsson @ 2010-08-24 19:21 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Stan Hoeppner, Christoph Lameter, Linux Kernel List, linux-mm,
	Mel Gorman, Linux Netdev List
In-Reply-To: <4C74097A.5020504@kernel.org>

On Tue, 24 Aug 2010, Pekka Enberg wrote:

> It looks to me as if tcp_create_openreq_child() is able to cope with the 
> situation so the warning could be harmless. If that's the case, we 
> should probably stick a __GFP_NOWARN there.

What about my situation? (a complete dmesg can be had at 
<http://swm.pp.se/dmesg.100809-2.txt.gz>)

[87578.494471] swapper: page allocation failure. order:0, mode:0x4020
[87578.494476] Pid: 0, comm: swapper Not tainted 2.6.32-24-generic #39-Ubuntu
[87578.494480] Call Trace:
[87578.494483]  <IRQ>  [<ffffffff810fad0e>] __alloc_pages_slowpath+0x56e/0x580
[87578.494499]  [<ffffffff810fae7e>] __alloc_pages_nodemask+0x15e/0x1a0
[87578.494506]  [<ffffffff8112dba7>] alloc_pages_current+0x87/0xd0
[87578.494511]  [<ffffffff81133b17>] new_slab+0x2f7/0x310
[87578.494516]  [<ffffffff811363c1>] __slab_alloc+0x201/0x2d0
[87578.494522]  [<ffffffff81455fe6>] ? __netdev_alloc_skb+0x36/0x60
[87578.494528]  [<ffffffff81137408>] __kmalloc_node_track_caller+0xb8/0x180
[87578.494532]  [<ffffffff81455fe6>] ? __netdev_alloc_skb+0x36/0x60
[87578.494536]  [<ffffffff81455ca0>] __alloc_skb+0x80/0x190
[87578.494540]  [<ffffffff81455fe6>] __netdev_alloc_skb+0x36/0x60
[87578.494564]  [<ffffffffa008f5c7>] rtl8169_rx_interrupt+0x247/0x5b0 [r8169]
[87578.494572]  [<ffffffffa008faad>] rtl8169_poll+0x3d/0x270 [r8169]
[87578.494580]  [<ffffffff810397a9>] ? default_spin_lock_flags+0x9/0x10
[87578.494586]  [<ffffffff8146029f>] net_rx_action+0x10f/0x250
[87578.494594]  [<ffffffffa008d54e>] ? rtl8169_interrupt+0xde/0x1e0 [r8169]
[87578.494600]  [<ffffffff8106e467>] __do_softirq+0xb7/0x1e0
[87578.494605]  [<ffffffff810c52c0>] ? handle_IRQ_event+0x60/0x170
[87578.494610]  [<ffffffff810142ec>] call_softirq+0x1c/0x30
[87578.494614]  [<ffffffff81015cb5>] do_softirq+0x65/0xa0
[87578.494618]  [<ffffffff8106e305>] irq_exit+0x85/0x90
[87578.494623]  [<ffffffff81549515>] do_IRQ+0x75/0xf0
[87578.494627]  [<ffffffff81013b13>] ret_from_intr+0x0/0x11
[87578.494629]  <EOI>  [<ffffffff8130f7cb>] ? acpi_idle_enter_c1+0xa3/0xc1
[87578.494639]  [<ffffffff8130f7aa>] ? acpi_idle_enter_c1+0x82/0xc1
[87578.494646]  [<ffffffff8143a5a7>] ? cpuidle_idle_call+0xa7/0x140
[87578.494652]  [<ffffffff81011e73>] ? cpu_idle+0xb3/0x110
[87578.494657]  [<ffffffff8153e27e>] ? start_secondary+0xa8/0xaa
[87578.494660] Mem-Info:
[87578.494662] Node 0 DMA per-cpu:
[87578.494666] CPU    0: hi:    0, btch:   1 usd:   0
[87578.494669] CPU    1: hi:    0, btch:   1 usd:   0
[87578.494672] CPU    2: hi:    0, btch:   1 usd:   0
[87578.494674] CPU    3: hi:    0, btch:   1 usd:   0
[87578.494677] Node 0 DMA32 per-cpu:
[87578.494680] CPU    0: hi:  186, btch:  31 usd: 173
[87578.494683] CPU    1: hi:  186, btch:  31 usd:  87
[87578.494686] CPU    2: hi:  186, btch:  31 usd: 168
[87578.494689] CPU    3: hi:  186, btch:  31 usd:  63
[87578.494691] Node 0 Normal per-cpu:
[87578.494695] CPU    0: hi:  186, btch:  31 usd: 177
[87578.494698] CPU    1: hi:  186, btch:  31 usd: 176
[87578.494700] CPU    2: hi:  186, btch:  31 usd:  82
[87578.494703] CPU    3: hi:  186, btch:  31 usd: 191
[87578.494710] active_anon:22970 inactive_anon:6433 isolated_anon:0
[87578.494711]  active_file:916528 inactive_file:914736 isolated_file:0
[87578.494713]  unevictable:0 dirty:135959 writeback:24423 unstable:0
[87578.494714]  free:9990 slab_reclaimable:59767 slab_unreclaimable:11135
[87578.494716]  mapped:119343 shmem:985 pagetables:2113 bounce:0
[87578.494719] Node 0 DMA free:15860kB min:20kB low:24kB high:28kB 
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15272kB 
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB 
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB 
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 
all_unreclaimable? yes
[87578.494733] lowmem_reserve[]: 0 2866 7852 7852
[87578.494738] Node 0 DMA32 free:21420kB min:4136kB low:5168kB high:6204kB 
active_anon:4056kB inactive_anon:5856kB active_file:1322360kB 
inactive_file:1320432kB unevictable:0kB isolated(anon):0kB 
isolated(file):0kB present:2935456kB mlocked:0kB dirty:190824kB 
writeback:31900kB mapped:157676kB shmem:0kB slab_reclaimable:107316kB 
slab_unreclaimable:15480kB kernel_stack:56kB pagetables:764kB unstable:0kB 
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[87578.494754] lowmem_reserve[]: 0 0 4986 4986
[87578.494759] Node 0 Normal free:2680kB min:7192kB low:8988kB 
high:10788kB active_anon:87824kB inactive_anon:19876kB 
active_file:2343752kB inactive_file:2338512kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:5105664kB mlocked:0kB 
dirty:353012kB writeback:65792kB mapped:319696kB shmem:3940kB 
slab_reclaimable:131752kB slab_unreclaimable:29060kB kernel_stack:2160kB 
pagetables:7688kB unstable:0kB bounce:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
[87578.494775] lowmem_reserve[]: 0 0 0 0
[87578.494779] Node 0 DMA: 3*4kB 3*8kB 3*16kB 1*32kB 2*64kB 2*128kB 
0*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15860kB
[87578.494792] Node 0 DMA32: 789*4kB 765*8kB 589*16kB 1*32kB 1*64kB 
4*128kB 4*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 21356kB
[87578.494805] Node 0 Normal: 374*4kB 4*8kB 20*16kB 1*32kB 0*64kB 0*128kB 
1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 2648kB
[87578.494818] 1832322 total pagecache pages
[87578.494820] 0 pages in swap cache
[87578.494823] Swap cache stats: add 0, delete 0, find 0/0
[87578.494825] Free swap  = 0kB
[87578.494827] Total swap = 0kB
[87578.531041] 2064368 pages RAM
[87578.531044] 66019 pages reserved
[87578.531046] 1501227 pages shared
[87578.531048] 619257 pages non-shared
[87578.531053] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
[87578.531057]   cache: kmalloc-4096, object size: 4096, buffer size: 
4096, default order: 3, min order: 0
[87578.531061]   node 0: slabs: 1322, objs: 4129, free: 0

This actually made the machine go offline for hours before it for some 
reason came back. The second time this happened it did not come back 
(waited 8 hours).

I also seem to have TCP related problems:

[87578.531806]  [<ffffffff8113651f>] kmem_cache_alloc_node+0x8f/0x160
[87578.531812]  [<ffffffff81455c6f>] __alloc_skb+0x4f/0x190
[87578.531820]  [<ffffffff814acbe0>] ? tcp_delack_timer+0x0/0x270
[87578.531828]  [<ffffffff814ab423>] tcp_send_ack+0x33/0x120
[87578.531834]  [<ffffffff814acd22>] tcp_delack_timer+0x142/0x270
[87578.531842]  [<ffffffff8105a34d>] ? scheduler_tick+0x18d/0x260
[87578.531849]  [<ffffffff8107776b>] run_timer_softirq+0x19b/0x340
[87578.531857]  [<ffffffff81094ac0>] ? tick_sched_timer+0x0/0xc0
[87578.531865]  [<ffffffff8108f723>] ? ktime_get+0x63/0xe0
[87578.531871]  [<ffffffff8106e467>] __do_softirq+0xb7/0x1e0
[87578.531878]  [<ffffffff810946aa>] ? tick_program_event+0x2a/0x30
[87578.531885]  [<ffffffff810142ec>] call_softirq+0x1c/0x30
[87578.531891]  [<ffffffff81015cb5>] do_softirq+0x65/0xa0
[87578.531897]  [<ffffffff8106e305>] irq_exit+0x85/0x90
[87578.531904]  [<ffffffff81549601>] smp_apic_timer_interrupt+0x71/0x9c
[87578.531910]  [<ffffffff81013cb3>] apic_timer_interrupt+0x13/0x20
[87578.531914]  <EOI>  [<ffffffff8130fbbe>] ? acpi_idle_enter_simple+0x117/0x14b
[87578.531928]  [<ffffffff8130fbb7>] ? acpi_idle_enter_simple+0x110/0x14b
[87578.531936]  [<ffffffff8143a5a7>] ? cpuidle_idle_call+0xa7/0x140
[87578.531943]  [<ffffffff81011e73>] ? cpu_idle+0xb3/0x110
[87578.531950]  [<ffffffff8153e27e>] ? start_secondary+0xa8/0xaa


-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH] caif-driver: add HAS_DMA dependency
From: David Miller @ 2010-08-24 19:21 UTC (permalink / raw)
  To: heiko.carstens; +Cc: sjur.brandeland, schwidefsky, linux-kernel, netdev
In-Reply-To: <20100824151427.GC2160@osiris.boeblingen.de.ibm.com>

From: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Tue, 24 Aug 2010 17:14:27 +0200

> From: Heiko Carstens <heiko.carstens@de.ibm.com>
> 
> Fix this error on an s390 allyesconfig build:
> 
> linux-2.6/drivers/net/caif/caif_spi.c:98:
>     undefined reference to `dma_free_coherent'
> 
> Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next-2.6] be2net: get rid of be_get_stats()
From: David Miller @ 2010-08-24 19:22 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, somnathk, ajitk
In-Reply-To: <1282663102.2477.253.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Aug 2010 17:18:22 +0200

> drivers can avoid implementing ndo_get_stats method if using netdevice
> stats structure.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).