* Re: [PATCH] sgi-xp: fix a use after free
From: Robin Holt @ 2011-06-20 2:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Robin Holt, netdev
In-Reply-To: <1308523956.3539.105.camel@edumazet-laptop>
Thank you Eric.
David, if you want me to submit this through Andrew Morton, I can do
that instead.
Acked-by: Robin Holt <holt@sgi.com>
On Mon, Jun 20, 2011 at 12:52:36AM +0200, Eric Dumazet wrote:
> Its illegal to dereference skb after dev_kfree_skb(skb)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Robin Holt <holt@sgi.com>
> ---
> David, I am not sure Robin is active these days, maybe you can take this
> patch, since its clearly network related ?
>
> drivers/misc/sgi-xp/xpnet.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/misc/sgi-xp/xpnet.c b/drivers/misc/sgi-xp/xpnet.c
> index ee5109a..42f0673 100644
> --- a/drivers/misc/sgi-xp/xpnet.c
> +++ b/drivers/misc/sgi-xp/xpnet.c
> @@ -495,14 +495,14 @@ xpnet_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
> }
> }
>
> + dev->stats.tx_packets++;
> + dev->stats.tx_bytes += skb->len;
> +
> if (atomic_dec_return(&queued_msg->use_count) == 0) {
> dev_kfree_skb(skb);
> kfree(queued_msg);
> }
>
> - dev->stats.tx_packets++;
> - dev->stats.tx_bytes += skb->len;
> -
> return NETDEV_TX_OK;
> }
>
>
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2011-06-20 2:56 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Hans Schillstrom, Simon Horman
Hi all,
Today's linux-next merge of the net tree got a conflict in
net/netfilter/ipvs/ip_vs_core.c between commit 8f4e0a18682d ("IPVS netns
exit causes crash in conntrack") from the net-current tree and commit
503cf15a5ecc ("IPVS: rename of netns init and cleanup functions") from
the net tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/netfilter/ipvs/ip_vs_core.c
index 24c28d2,2200bae..0000000
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@@ -1945,8 -1945,7 +1945,8 @@@ static void __net_exit __ip_vs_dev_clea
{
EnterFunction(2);
net_ipvs(net)->enable = 0; /* Disable packet reception */
+ smp_wmb();
- __ip_vs_sync_cleanup(net);
+ ip_vs_sync_net_cleanup(net);
LeaveFunction(2);
}
^ permalink raw reply
* Re: [PATCH] sgi-xp: fix a use after free
From: David Miller @ 2011-06-20 3:19 UTC (permalink / raw)
To: holt; +Cc: eric.dumazet, netdev
In-Reply-To: <20110620024455.GF3525@sgi.com>
From: Robin Holt <holt@sgi.com>
Date: Sun, 19 Jun 2011 21:44:56 -0500
> Thank you Eric.
>
> David, if you want me to submit this through Andrew Morton, I can do
> that instead.
I applied it to my net-2.6 tree long before you replied.
^ permalink raw reply
* Re: [RFC] Moving files around in drivers/net
From: Ben Hutchings @ 2011-06-20 3:22 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Joe Perches, netdev, David Miller, Paul Gortmaker, Jan Engelhardt
In-Reply-To: <1308536729.22851.42.camel@jtkirshe-mobl>
On Sun, 2011-06-19 at 19:25 -0700, Jeff Kirsher wrote:
> On Wed, 2011-06-15 at 18:10 -0700, Joe Perches wrote:
[...]
> > Some manufacturer directories are directly populated
> > with multiple drivers, some have subdirectories.
> > Should one style be consistently used?
>
> This is a grey area. I think it makes more sense to group drivers
> either by company, maintainer, bus or commonly used header. It has been
> expressed by others in the community and while placing drivers in
> driver/net/ethernet/<company name> is nice way to organize, companies
> get bought and sold and driver ownership moves from one company to
> another. To constantly rename directories based on the ownership may
> cause un-necessary flux in the directory structure. I tried to tried to
> avoid using company names unless I was confident about it.
You could try to futureproof by leaving out companies altogether and
just considering the technical heritage of hardware. For example, the
netxen and qlcnic drivers appear to work with related hardware, but qlge
and qlcnic do not. But this is possibly not a lot more objective than
what you've done so far, and it doesn't make it any easier to name the
directories.
> Some of the suggestions you listed below seem fine, especially since
> several of these companies have been around for some time and actively
> maintain their driver(s).
[...]
> > sfc may be solarflare
[...]
This directory only contains a single net driver, and its name matches
the prefix for Solarflare controller part numbers (not LOMs, but the
driver doesn't care about the distinction). Any separate driver for
future Solarflare hardware is also likely to be named beginning with the
letters 'sfc'. So I'd be happier if this was *not* renamed.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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: linux-next: manual merge of the net tree with the net-current tree
From: Simon Horman @ 2011-06-20 3:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Hans Schillstrom
In-Reply-To: <20110620125616.e319c55c.sfr@canb.auug.org.au>
On Mon, Jun 20, 2011 at 12:56:16PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> net/netfilter/ipvs/ip_vs_core.c between commit 8f4e0a18682d ("IPVS netns
> exit causes crash in conntrack") from the net-current tree and commit
> 503cf15a5ecc ("IPVS: rename of netns init and cleanup functions") from
> the net tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Thanks.
I think this should all come out in the wash
when Dave merges net-2.6 into net-next-2.6.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc net/netfilter/ipvs/ip_vs_core.c
> index 24c28d2,2200bae..0000000
> --- a/net/netfilter/ipvs/ip_vs_core.c
> +++ b/net/netfilter/ipvs/ip_vs_core.c
> @@@ -1945,8 -1945,7 +1945,8 @@@ static void __net_exit __ip_vs_dev_clea
> {
> EnterFunction(2);
> net_ipvs(net)->enable = 0; /* Disable packet reception */
> + smp_wmb();
> - __ip_vs_sync_cleanup(net);
> + ip_vs_sync_net_cleanup(net);
> LeaveFunction(2);
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* ??: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment
From: ?? @ 2011-06-20 4:01 UTC (permalink / raw)
To: 'David Laight', 'Holger Brunck', linuxppc-dev
Cc: netdev, 'Clive Stubbings', 'Vitaly Bordug'
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8ADA6@saturn3.aculab.com>
Hi David Laight, Thank you so much~~
1. Hardware based on FPGA, it dose not support buffer chaining.
2. How dose the dma map support buffer chaining function?
3. On the align issue, the hardware designer start to fix it, maybe it's a
better way.
-----????-----
???: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] ??
David Laight
????: 2011?6?17? 18:16
???: yangyong@neusoft.com; Holger Brunck; linuxppc-dev@lists.ozlabs.org
??: netdev@vger.kernel.org; Clive Stubbings; Vitaly Bordug
??: RE: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment
> Hello,
> Motioned to the memory aligned, now there is such requirement:
> When the driver send an packet to hardware, the skb's address passed
by
> stack do a dma map into hardware, the skb's dma address must
> be 64-byte aligned.
Does the hardware support buffer chaining?
In which case you only need to copy the data upto the first
64 byte boundary into another buffer.
Actually, given that you are likely to have to fixup every
fragment of the frame being transmitted, if might be worth
allocating a fixed transmnit buffer area and copying the
frames into it prior to sending.
Certainly you need to allow for transmits made up of a
significant number of small buffers linked together.
Really you should beat up the hardware designers!
Copying the data to even a 4 byte boundary is almost
always a misaligned copy. Typically this only applies
to the receive dma - when writing a 2 byte pad before
the frame data would be much better.
David
--
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
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC] Moving files around in drivers/net
From: Jeff Kirsher @ 2011-06-20 4:02 UTC (permalink / raw)
To: Ben Hutchings
Cc: Joe Perches, netdev, David Miller, Paul Gortmaker, Jan Engelhardt
In-Reply-To: <1308540132.11457.97.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]
On Sun, 2011-06-19 at 20:22 -0700, Ben Hutchings wrote:
> On Sun, 2011-06-19 at 19:25 -0700, Jeff Kirsher wrote:
> > On Wed, 2011-06-15 at 18:10 -0700, Joe Perches wrote:
> [...]
> > > Some manufacturer directories are directly populated
> > > with multiple drivers, some have subdirectories.
> > > Should one style be consistently used?
> >
> > This is a grey area. I think it makes more sense to group drivers
> > either by company, maintainer, bus or commonly used header. It has been
> > expressed by others in the community and while placing drivers in
> > driver/net/ethernet/<company name> is nice way to organize, companies
> > get bought and sold and driver ownership moves from one company to
> > another. To constantly rename directories based on the ownership may
> > cause un-necessary flux in the directory structure. I tried to tried to
> > avoid using company names unless I was confident about it.
>
> You could try to futureproof by leaving out companies altogether and
> just considering the technical heritage of hardware. For example, the
> netxen and qlcnic drivers appear to work with related hardware, but qlge
> and qlcnic do not. But this is possibly not a lot more objective than
> what you've done so far, and it doesn't make it any easier to name the
> directories.
>
> > Some of the suggestions you listed below seem fine, especially since
> > several of these companies have been around for some time and actively
> > maintain their driver(s).
> [...]
> > > sfc may be solarflare
> [...]
>
> This directory only contains a single net driver, and its name matches
> the prefix for Solarflare controller part numbers (not LOMs, but the
> driver doesn't care about the distinction). Any separate driver for
> future Solarflare hardware is also likely to be named beginning with the
> letters 'sfc'. So I'd be happier if this was *not* renamed.
>
> Ben.
>
Thanks Ben, I will keep it sfc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 5/7] qlcnic: fix default operating state of interface
From: Anirban Chakraborty @ 2011-06-20 4:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Amit Salecha
In-Reply-To: <20110617.001035.1602476678651330954.davem@davemloft.net>
On Jun 16, 2011, at 9:10 PM, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Thu, 16 Jun 2011 13:37:36 -0700
>
>> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>>
>> Currently interface shows status as RUNNING, even if there is no link.
>> To fix this, netif_carrier_off should be called after register_netdev().
>>
>> netif_carrier_off calls linkwatch_fire_event(dev); only if netdev is registered,
>> otherwise it skips. linkwatch_fire_event set default state of nic interface.
>>
>> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>
> You cannot do this.
>
> The exact second that register_netdev() is called, the device can
> be brought up asynchronously and the link brought into the up state.
>
> Your netif_carrier_off() call will race with this.
>
> This is why no other (properly functioning) driver does what you're
> trying to do here.
>
We will take care of it. Please ignore the series.
thanks much,
Anirban
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2011-06-20 4:26 UTC (permalink / raw)
To: horms; +Cc: sfr, netdev, linux-next, linux-kernel, hans.schillstrom
In-Reply-To: <20110620033951.GA2457@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Mon, 20 Jun 2011 12:39:52 +0900
> I think this should all come out in the wash
> when Dave merges net-2.6 into net-next-2.6.
Indeed, it will.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2011-06-20 4:58 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Greg KH, Alexey Dobriyan
In-Reply-To: <20110615085617.949d418f.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
Hi Dave,
On Wed, 15 Jun 2011 08:56:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 9 Jun 2011 14:56:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the net tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > [See summary in patch below.]
> >
> > I assume that this is fallout from commit a6b7a407865a ("net: remove
> > interrupt.h inclusion from netdevice.h").
> >
> > I added the following patch for today:
> >
> > From 520e46c255afa851b33e5c4a2bcf2112ecccbb6f Mon Sep 17 00:00:00 2001
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 9 Jun 2011 14:19:09 +1000
> > Subject: [PATCH] net/staging: add needed interrupt.h and hardirq.h includes
>
> I am still getting these build errors and applying the patch. I would
> assume that if you merge Linus' tree (-rc3 will do it) into net-next, you
> will get these failures as well (for an x86_64 allmodconfig build at
> least).
>
> I think that this patch would probably apply to just the net-next tree
> anyway.
Ping.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 04/17] ixgbevf: provide 64 bit statistics
From: Eric Dumazet @ 2011-06-20 4:59 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Stephen Hemminger, netdev, gospo
In-Reply-To: <1308531518-17298-5-git-send-email-jeffrey.t.kirsher@intel.com>
Le dimanche 19 juin 2011 à 17:58 -0700, Jeff Kirsher a écrit :
> From: Stephen Hemminger <shemminger@vyatta.com>
>
> Compute statistics per ring using 64 bits, and provide
> network device stats in 64 bits.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Acked-by: Greg Rose <Gregory.v.rose@intel.com>
> Tested-by: Evan Swanson <evan.swanson@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>
> +static struct rtnl_link_stats64 *ixgbevf_get_stats(struct net_device *netdev,
> + struct rtnl_link_stats64 *stats)
> +{
> + struct ixgbevf_adapter *adapter = netdev_priv(netdev);
> + int i;
> +
> + ixgbevf_update_stats(adapter);
> +
> + stats->multicast = adapter->stats.vfmprc - adapter->stats.base_vfmprc;
> +
> + for (i = 0; i < adapter->num_rx_queues; i++) {
> + stats->rx_bytes += adapter->rx_ring[i].total_bytes;
> + stats->rx_packets += adapter->rx_ring[i].total_packets;
> + }
> +
> + for (i = 0; i < adapter->num_tx_queues; i++) {
> + stats->tx_bytes += adapter->tx_ring[i].total_bytes;
> + stats->tx_packets += adapter->tx_ring[i].total_packets;
> + }
> +
> + return stats;
> +}
> +
Unfortunately this patch is racy on 32bit arches.
Jeff, maybe you missed all the discussion we had lately on these
conversions, needing appropriate synchronization ?
It seems a lot of bugs were added lately with Stephen patches, this is
rather unfortunate...
I guess I'll have to review them and send fixes.
^ permalink raw reply
* Re: [RFC] Moving files around in drivers/net
From: Jan Engelhardt @ 2011-06-20 5:23 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Joe Perches, netdev, David Miller, Paul Gortmaker
In-Reply-To: <1308536729.22851.42.camel@jtkirshe-mobl>
On Monday 2011-06-20 04:25, Jeff Kirsher wrote:
>> pktgen in hamachi/yellowfin should be pkteng
>>
>> I think it might be better if:
>>
>> Things were more spelled out:
>> pkteng should be packetengines
>
>That sounds fine. I will make the change.
What's next, directory naming by Windows-originating coding styles -
"Drivers/Networking/Ethernet/Packet Engines/"?
>> And things maybe not spelled out
>> ixp2000 might just be ixp (what not intel?:)
I don't understand your logic of doing pkteng -> packetengines
and ixp2000 -> ixp at the same time. I was quite thankful that
Linux's driver names were not (always) TLAs like in OpenBSD.
>While this is an Intel chip, the part was sold off and the driver is not
>maintained by Intel. That is reason why it does not reside in
>the /driver/net/ethernet/intel/ directory.
And that's why it probably should not be attempted. The i in ixp
will remind us enough that it once was Intel's doing - just as
in ixgb, rtl*, atl*, etc. Separation by company seems unnecessary
to me.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2011-06-20 5:36 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, greg, adobriyan
In-Reply-To: <20110620145807.9c202509.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 20 Jun 2011 14:58:07 +1000
> On Wed, 15 Jun 2011 08:56:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Thu, 9 Jun 2011 14:56:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> I think that this patch would probably apply to just the net-next tree
>> anyway.
>
> Ping.
Sorry, this slipped through the cracks, I'll take care of this right now.
^ permalink raw reply
* Re: [PATCH]rionet: fix NULL pointer dereference in rionet_remove
From: David Miller @ 2011-06-20 5:44 UTC (permalink / raw)
To: synmyth; +Cc: netdev, mporter, jj, cmdkhh
In-Reply-To: <1308410839.9175.11.camel@localhost>
From: Yinglin Luan <synmyth@gmail.com>
Date: Sat, 18 Jun 2011 23:27:15 +0800
> -static int rionet_setup_netdev(struct rio_mport *mport)
> +static int rionet_setup_netdev(struct rio_mport *mport, struct
> net_device *ndev)
This patch has been mangled by your email client.
Read Documentation/email-clients.txt
Send a test patch to yourself, make sure it applies for you.
Then resend your patch here.
^ permalink raw reply
* [PATCH net-next-2.6] veth: fix 64bit stats on 32bit arches
From: Eric Dumazet @ 2011-06-20 5:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger, Jeff Kirsher
Using 64bit stats on 32bit arches must use a synchronization or readers
can get transient values.
Fixes bug introduced in commit 6311cc44a2 (veth: convert to 64 bit
statistics)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/veth.c | 55 ++++++++++++++++++++++++++++---------------
1 file changed, 37 insertions(+), 18 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 8730d64..8acb3af 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/ethtool.h>
#include <linux/etherdevice.h>
+#include <linux/u64_stats_sync.h>
#include <net/dst.h>
#include <net/xfrm.h>
@@ -24,12 +25,13 @@
#define MAX_MTU 65535 /* Max L3 MTU (arbitrary) */
struct veth_net_stats {
- u64 rx_packets;
- u64 tx_packets;
- u64 rx_bytes;
- u64 tx_bytes;
- u64 tx_dropped;
- u64 rx_dropped;
+ u64 rx_packets;
+ u64 tx_packets;
+ u64 rx_bytes;
+ u64 tx_bytes;
+ u64 rx_dropped;
+ u64 tx_dropped;
+ struct u64_stats_sync syncp;
};
struct veth_priv {
@@ -137,21 +139,29 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)
if (dev_forward_skb(rcv, skb) != NET_RX_SUCCESS)
goto rx_drop;
+ u64_stats_update_begin(&stats->syncp);
stats->tx_bytes += length;
stats->tx_packets++;
+ u64_stats_update_end(&stats->syncp);
+ u64_stats_update_begin(&rcv_stats->syncp);
rcv_stats->rx_bytes += length;
rcv_stats->rx_packets++;
+ u64_stats_update_end(&rcv_stats->syncp);
return NETDEV_TX_OK;
tx_drop:
kfree_skb(skb);
+ u64_stats_update_begin(&stats->syncp);
stats->tx_dropped++;
+ u64_stats_update_end(&stats->syncp);
return NETDEV_TX_OK;
rx_drop:
+ u64_stats_update_begin(&rcv_stats->syncp);
rcv_stats->rx_dropped++;
+ u64_stats_update_end(&rcv_stats->syncp);
return NETDEV_TX_OK;
}
@@ -162,21 +172,30 @@ rx_drop:
static struct rtnl_link_stats64 *veth_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *tot)
{
- struct veth_priv *priv;
+ struct veth_priv *priv = netdev_priv(dev);
int cpu;
- struct veth_net_stats *stats;
-
- priv = netdev_priv(dev);
for_each_possible_cpu(cpu) {
- stats = per_cpu_ptr(priv->stats, cpu);
-
- tot->rx_packets += stats->rx_packets;
- tot->tx_packets += stats->tx_packets;
- tot->rx_bytes += stats->rx_bytes;
- tot->tx_bytes += stats->tx_bytes;
- tot->tx_dropped += stats->tx_dropped;
- tot->rx_dropped += stats->rx_dropped;
+ struct veth_net_stats *stats = per_cpu_ptr(priv->stats, cpu);
+ u64 rx_packets, rx_bytes, rx_dropped;
+ u64 tx_packets, tx_bytes, tx_dropped;
+ unsigned int start;
+
+ do {
+ start = u64_stats_fetch_begin_bh(&stats->syncp);
+ rx_packets = stats->rx_packets;
+ tx_packets = stats->tx_packets;
+ rx_bytes = stats->rx_bytes;
+ tx_bytes = stats->tx_bytes;
+ rx_dropped = stats->rx_dropped;
+ tx_dropped = stats->tx_dropped;
+ } while (u64_stats_fetch_retry_bh(&stats->syncp, start));
+ tot->rx_packets += rx_packets;
+ tot->tx_packets += tx_packets;
+ tot->rx_bytes += rx_bytes;
+ tot->tx_bytes += tx_bytes;
+ tot->rx_dropped += rx_dropped;
+ tot->tx_dropped += tx_dropped;
}
return tot;
^ permalink raw reply related
* Re: [PATCH net-next-2.6] veth: fix 64bit stats on 32bit arches
From: David Miller @ 2011-06-20 5:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger, jeffrey.t.kirsher
In-Reply-To: <1308548772.3539.121.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 20 Jun 2011 07:46:12 +0200
> Using 64bit stats on 32bit arches must use a synchronization or readers
> can get transient values.
>
> Fixes bug introduced in commit 6311cc44a2 (veth: convert to 64 bit
> statistics)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [RFC] Moving files around in drivers/net
From: Joe Perches @ 2011-06-20 6:01 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jeff Kirsher, netdev, David Miller, Paul Gortmaker
In-Reply-To: <alpine.LNX.2.01.1106200717100.10183@frira.zrqbmnf.qr>
On Mon, 2011-06-20 at 07:23 +0200, Jan Engelhardt wrote:
> What's next, directory naming by Windows-originating coding styles -
> "Drivers/Networking/Ethernet/Packet Engines/"?
> >> And things maybe not spelled out
> >> ixp2000 might just be ixp (what not intel?:)
Using embedded spaces is a poor choice.
> I don't understand your logic of doing pkteng -> packetengines
As demonstrated, it's too easy to typo
pkteng as pktgen.
> and ixp2000 -> ixp at the same time. I was quite thankful that
> Linux's driver names were not (always) TLAs like in OpenBSD.
The (what not intel?:) was just teasing.
I think ixp is sufficient.
I never thought of ixp2000 as the family
for the 2400 and 2800/2850.
Castine maybe, ixp2xxx maybe.
ixp2000? Never heard of it.
Though maybe ixp would be confused for
those ixp4xx and maybe even the original
Digital/Intel ixp1200 parts too.
'course all of this is 10 years old now
and kind of pointless.
cheers, Joe
^ permalink raw reply
* [PATCH net-next-2.6] myricom: remove stats_lock
From: Eric Dumazet @ 2011-06-20 6:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Gallatin, Brice Goglin, Stephen Hemminger
stats_lock is non useless, lets remove it.
Also, ndo_get_stats64() doesnt have to clear the stats, caller takes
care of this.
Note: folding 32bit fields in 64bit one is problematic when one of 32bit
values wraps : SNMP reader will see a ~2^32 back change in a 64bit
value. A future patch should fix this.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
CC: Andrew Gallatin <gallatin@myri.com>
CC: Brice Goglin <brice@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 04e10f4..3e89a84 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -210,7 +210,6 @@ struct myri10ge_priv {
int big_bytes;
int max_intr_slots;
struct net_device *dev;
- spinlock_t stats_lock;
u8 __iomem *sram;
int sram_size;
unsigned long board_span;
@@ -1837,6 +1836,7 @@ myri10ge_get_ethtool_stats(struct net_device *netdev,
int i;
/* force stats update */
+ memset(&link_stats, 0, sizeof(link_stats));
(void)myri10ge_get_stats(netdev, &link_stats);
for (i = 0; i < MYRI10GE_NET_STATS_LEN; i++)
data[i] = ((u64 *)&link_stats)[i];
@@ -2981,12 +2981,10 @@ drop:
static struct rtnl_link_stats64 *myri10ge_get_stats(struct net_device *dev,
struct rtnl_link_stats64 *stats)
{
- struct myri10ge_priv *mgp = netdev_priv(dev);
- struct myri10ge_slice_netstats *slice_stats;
+ const struct myri10ge_priv *mgp = netdev_priv(dev);
+ const struct myri10ge_slice_netstats *slice_stats;
int i;
- spin_lock(&mgp->stats_lock);
- memset(stats, 0, sizeof(*stats));
for (i = 0; i < mgp->num_slices; i++) {
slice_stats = &mgp->ss[i].stats;
stats->rx_packets += slice_stats->rx_packets;
@@ -2996,7 +2994,6 @@ static struct rtnl_link_stats64 *myri10ge_get_stats(struct net_device *dev,
stats->rx_dropped += slice_stats->rx_dropped;
stats->tx_dropped += slice_stats->tx_dropped;
}
- spin_unlock(&mgp->stats_lock);
return stats;
}
@@ -3966,7 +3963,6 @@ static int myri10ge_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
setup_timer(&mgp->watchdog_timer, myri10ge_watchdog_timer,
(unsigned long)mgp);
- spin_lock_init(&mgp->stats_lock);
SET_ETHTOOL_OPS(netdev, &myri10ge_ethtool_ops);
INIT_WORK(&mgp->watchdog_work, myri10ge_watchdog);
status = register_netdev(netdev);
^ permalink raw reply related
* [PATCH] netxen: fix race in skb->len access
From: Eric Dumazet @ 2011-06-20 6:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Amit Kumar Salecha
As soon as skb is given to hardware, TX completion can free skb under
us.
Therefore, we should update dev stats before kicking the device.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index b644383..c0788a3 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1965,11 +1965,11 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
netxen_tso_check(netdev, tx_ring, first_desc, skb);
- netxen_nic_update_cmd_producer(adapter, tx_ring);
-
adapter->stats.txbytes += skb->len;
adapter->stats.xmitcalled++;
+ netxen_nic_update_cmd_producer(adapter, tx_ring);
+
return NETDEV_TX_OK;
drop_packet:
^ permalink raw reply related
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Oliver Neukum @ 2011-06-20 6:47 UTC (permalink / raw)
To: Marius Kotsbak
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <4DFE6FD8.1080003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Am Sonntag, 19. Juni 2011, 23:53:28 schrieb Marius Kotsbak:
> On 14. juni 2011 11:46, Oliver Neukum wrote:
> > Am Dienstag, 14. Juni 2011, 11:32:00 schrieb Marius Kotsbak:
> >> Den 14. juni 2011 10:49, skrev Oliver Neukum:
> > The API is correct. You just need to copy the init strings into buffers
> > allocated with kmalloc.
> >
>
> This should be addressed in the extra patch just sent. And it still
> works on my x86-64.
x86-64 works. ppc and arm are hurt.
> The 2 patches might be squashed if desired.
David?
> Okay, I can see the reasoning behind that. The problem is just that it
> would be nice to avoid it because >1.1.4 versions of it does not work
> with this modem, but that can be addressed there as well.
All's well, as far as I can see.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 07/11] fs_enet: enable transmit time stamping.
From: Richard Cochran @ 2011-06-20 6:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller, Matt Carlson, Michael Chan
In-Reply-To: <1308508249.3539.78.camel@edumazet-laptop>
On Sun, Jun 19, 2011 at 08:30:49PM +0200, Eric Dumazet wrote:
> Le dimanche 19 juin 2011 à 20:12 +0200, Richard Cochran a écrit :
>
> > Thanks for your review. I have posted a fix for the first batch (since
> > they are already in next) and reposted this series.
> >
> > But, considering your point, it looks like pxa168_eth and mv643xx_eth
> > (see patches 9 and 10 of this series) already access skb->len unsafely.
> >
> > Would you care to comment on those spots, too?
>
> They certainly are buggy, at a first glance.
>
> Not only skb->len is unsafe, but netif_tx_stop_queue() calls are unsafe
> too.
Out of the MAC drivers in my two batches, only drivers/net/tg3.c calls
netif_tx_stop_queue(txq);
However, I don't know how to fix that. Anyone else care to take a look?
Thanks,
Richard
^ permalink raw reply
* [PATCH] linux-firmware: update firmware for RTL8111E-VL
From: Hayes Wang @ 2011-06-20 7:39 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
Updated firmware with stability fixes.
Versin: RL6210B_RAM_Code_110610
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3248 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/rtl_nic/rtl8168e-3.fw b/rtl_nic/rtl8168e-3.fw
index cb494071d0273c7b3102b97552f4bc7b756c0e17..0b9f907a2acae6818c1478218e10e440b4fba900 100644
GIT binary patch
literal 3248
zcmaKvTWplo7RPs|oz*E61K0|~Wtd(lB1k(87WBo6mtdmCkeG;`9C&~SpEx<196UEy
zg^t=PF~@66to8DuG8K{NgOTBZK%$AU2#I((`KGksImgT-1X?aF<8RIWMn4TXlYCiw
zuj_xUz1IG|an89-_w;mUx;AXtblbgKZr`zO`<6_mt0&Wi#Q%CBi)x)~bX`52-CdoT
zOgeMZEnVwwS-T#|GIa}`I@j#VC6|UCavPo2!|!w{`0h_N&IQgbF{QM+*zh*zo_8)z
z0B>u$ZNJf7;IK(MbelrmI69N%xT=$iZ_}6B>$INd1J|rudy~2k>UJjeL!<vp>VD|H
zKPUAg+dq-i1GaxOsWmmt8h1&ph1Npj(3!5J3UuoAq}D@^uqT&F3`dNZVGW<HEek3b
zdcjcV7V7bah3beuZZwh9b4JTat()cfO-37&+HMs7V@4;@Tjb?+i=o&x8J$7TDE`(O
z#qN%f|DsXsDmWq-92krjt&vk|6%(D>C>l_+sj{dJi;lpHO^P<xh}PJ;RdiUx^{t|t
z;hSCTGtqD14+f%zr$wI`L?^|*AetJ0hu&b6_pIkV7v=52H+n~%=%*v1eaA(|kBR;Z
zoxusw(HBJXwW4kPqU(q`+QuH*5$=oZ6IszBI<t&!6`gAofAd0m5G=)d?2JAt`V!Q9
zJWUMuljyri(dStgFADwRZLJogSJ1=HqG)WeE)Dl}#11Zq4q%(kVb|o>F>GF2MjiqA
zc8IPRXI&%**5ebR(<?+T)cLyQo)c|KvqtV%4`8$NA<-f7i8Y9R7Z-ifYW+9SOt)y=
zw2!$bj5)a!pV-^J&-DHv`o${I8*RN(^Z<V9Z2gkx=W9fF+xn>Jj%xfpqO)5>TR87Q
zaK_lLMYb5d;79MbmE0!5G2ZI;cHTMk66D_&v0IV}b3ztx7i|w^0ei!@yy|E9@BC1g
zj)<T0H%9zWs}&L1Uo9VMaFM!~E`jk8(Wk;%9NX^C>pz{MJ>XAamnXOL;l7c5YM$p^
zi1Oxp-sLFoTF-lhb2MKSTh7<~rTZhi>%ai-S$ZmlZtD<dc$)gq>rK?7i=0cud=MW)
zjqvHiL=Sw<xb6++WfZ#+&K}yCXML8Mt`mK^BsxR?RdfB4TrJ;A<Xgjx9C!dM$XAD0
z_LAG|>qYy`2j@OXjO+I@%Xg!<O>|{M?_u=ZSH7?IZsn}N-)g#G%-<(^nDfmZ6g@`1
z-_Q#unU8v&<o7&3Fz4h@dPek*_${;EK8Jp$?@~_m`@2McKzBdS@iDN%t75XemXd3L
z@BCrvlO;c9J^2mKNo?_DwifH$elU`!&7Wbn*}p=+SzV5hx78+2AB<fT{V#ZfQ=$+3
zk8{FDiXJ(g4*6%0!Jjsr0(LWg_5$qs=$j7m4i@=!i>=AI-}=ec*Z6gttrNb_+F4tj
ziru11#-Y?_DRd0__Yg<$57G5uyxh&q(i+j5>4Q<~l&=vzLA@=X82KD~l5?Xb>qEaW
z5uLwFbQkg&>k)D+(Cg>uugcu@k#`5@g?#EAaB-HFM+^RAaqcpFuAB;Wsau>nG@0)E
z=-v?K6Y8FsFS@F#`xLtEKJL`Vq7$oq%<6qpsg>DL+X?Vju{5x@J8SPb(OP1)5i58#
ztRebAgZE>#HQUR~RmB!;4PgDnww1iimL9ixZjabn{mu5%U01J1f_m%%LylgGEvN69
zg(|*T;M<LCau)BI709X4%Bma;2{0Rm+>gl6y&)<CpZOU^$KtQ5%BWR>T4hZJW|OT(
zHZURjCUr<SKhG^Tizoa%TOG4S_~`#~_v0rO@e{|+&V6JIzvnrRns9%X{cQHg?EW61
zFNcZgc+Br5`r{Gi!emAAk1<yzY_GiR<wfKT@a(<x@NUnWOV2sO`F|dJx7oWjTM%8w
zIS%1-p0Fp+5%$*m7Hb;5<#dUeG93BK#DM=eYsZ<`9H(00gYTzK-~0JC(X;e|-K}$|
z-R3*Nyo~vOg_vK9zQ9b*=dO8cf#|>ST`K#0ro;KI#wrraFr1(kN-kMyUNZg1iHFat
z#mf;dMlY0i`rH=N8}E@rX$^NB@g26ShQQKCAKMvr`!lTE)#TJTS9BkD`W$MXhj#Wy
zzD>YT-P^Z`VYB<<S}+a1E&BBV@=~8y?kaiNy=3=~y(@!_+;`0VK!Ll(aN+wVa1B@=
zakdo--}<+35G?3s$3#zo&%S-EwmGX~+UwSaHlJWq=|%J^lpN;K52u^`w^Q~EnBf(<
z^P=BUGsLglN6^3YiuQsl;EcLkMek=_c#N9f!8c(5pYz&u2p_gS3Eq1|Hx%NQgMGKp
tg&ykt-M;#L>cam6<+5`ar0xGe^&8**2W+ta0d4+!_SgRf_U-L|KLei;K0N>c
literal 2804
zcmaKuS!|S56vyvuXDEwdX=z8WolZ+xrAP=!Vq#-Nc`(M9m<Srf13vJiQ4@-BIfa&`
zMS>d`6R?UeXp0DaGtxc~Ow<@#AOWSxH%JAQw21-A(sulv@B5~F;_~q2-gE9*{^x(s
zJu}W#sjG16T$w8jxh!jsTkSNBzTQ=$cQ3}A^PHP)Mp<?7_Vv!~b}qHVg}!E6^Ecaa
zhfmgFTN>J?u(?)9sXFmvo4q7vYMSp0SElP4GJ2TRHD>fnTi?j&5!S;mW%Q`YZ)UX1
z<d-uVi<N20Wi-K>U`?@(F3G5{4)4oon)L)SwfH$4IpT&j{MJ>M`xqL)kaQJVo32nd
zmeFOlj%KvBf^`JhR%G8V;^Xi!U9={r)D{;VUM=cT<8VP#+eHtdi(eBhi;2c;pA)Sw
z?jICg!`}SjJ4FwwXqzXR-!8hN4f{&uyl7=BI_%n_I_ypNR#dl3v>n|y<p1iBXwxat
z3;RXi!KQ6MwD(=n?u6*u&7v#F*;|9m`d%mxB1?<tAT|?NyVr?s$Jbp3TSjy@`@tK+
zJ+hL+YU~}uj{Wv%Ov4(=Nn(1}1Dx4T{7QqpakQ4Y5{;rIU`!bYKZ`!FS#&A;k^4li
zCyC>Uc2d{fS<x&!wq3vud0vy~Li71fbpE}>v3-~5`}i!j{kNhoMEoaJi&jVcmvJ@=
zJMWU{F6zpG?OF=Ha)DgTI|2MP5x?2sDxRfkMQg(|4@?$kPBG4$JL1%d)<xo61@m~E
zxuSC;XRpG4azyk7ybaw1;|9@f#5Vr=o)7r`tzL9F_$%@2rnal0JQ=xiTA;fg)lCm{
zx1zckfo^YA5X<-Fek|Uu=7?@47|`wHzT(*CxUbe<xfgn{6h4-KYlxgrgJ=I_^lAEM
zIr_EK@ezI8iy!^ySnIpl{|TonME4Adj?zEHT7RHctM?}L#^~Lyr@+Gbhar|uYI}5^
zXtTxG%YBh!UWe$9&mhxJ)tmW{JGe)CXOEN9!}i#5aBd|}pJ?U`-&xUfVC<)-(|kL2
zh^_}q`Z>`l1<_~W*uniHmDrx+>lZzL1Ra>VW1@S(WAEn>y>aXw(c|>!R`T@0-I=85
z*)VR=_XxR8UBMrWMeJ7p5Vei%;X6UUk8<DO_Rfp`^1J9C#7x6q0zR|g@ZkGmsP{O_
z(;uU(N%I4%^-@O@@1*YbzLY!j^(~@zWpD4Tr+xi4c&g>S!PA97V$BX$YVvWsCi*&Y
z{e1U}u4KQMyY8F?Pb-6at+u;39o*+;<AfR0F$o>^LR{0uPx98b1U1^5Zp{-DKAPz1
zI^xBt`_mkEIUL~Xq>dEWYw#UDi0ypQmazZL_H%e%P_(7C6!lCu+l$yP4Bkp@7<VIi
z7h&5vKz?$L&lGYb;Hnxwk2AwkjgMC%dWAmE(ns-x=m*3$t~$w60*9^aJBX72-wgA;
z6=180_~t_2o4h&S7oJPtdEA$nTksu$-+$x7n?Nst+n*(tgPtG9H&JwAb1*Mb?Ysdy
zkMLu@m%wke_-6|u_&Cc_XQJpA;mZ6RH5ShX76m-GkD2kD*^EC;&DQrL;2-23%|40V
z=DW=&<J_ZHP4CEIcXfa|uF?mwP(F%02{|6hUn3`wE$@g6_^=re-@u#UtYr{i^foI-
zcrV76=^SsW*|5;FzRu%K2ycemu_}6Rzvuun$>b#Qi*bsx#&X;uM+^NsM4Y}&<Redx
zFHQ~qoVpzJ^$hEAW|qyHRZ~Q()-VIWbF!cJ1~>im{8Vz-`~JVLoPJ1tB3k(VpR;cq
z549yM4sWVk$qW8X<XXk|Uzp~?dm}aE3&HPpjQ6?tvjF3!v&>}THF4M7;BBXOiog9s
zF>vEIZ8AI_W~DZNKJ5$Yws{?ujYFHW#^(WkJG!`Y<!z7G1&-)U&tto>L9`)HUyyrg
zPV@=(`B&iJVbPyF^k9Cnhkmj>Slwfy59L$Fqy2}R%G%R#hg|&c<--4_g@POZZ(97n
VdHX+Uxf?6kf6?+D|9>1#e*sYqwB!H)
--
1.7.3.2
^ permalink raw reply
* [PATCH 0/2] fix tiny races in MAC drivers
From: Richard Cochran @ 2011-06-20 7:48 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet
In course of adding transmit time stamping, some unrelated problems
were uncovered. Drivers which free transmit buffers in an ISR must not
access the buffers after giving them to the hardware.
Richard Cochran (2):
pxa168_eth: fix race in transmit path.
mv643xx_eth: fix race in trasmit path.
drivers/net/mv643xx_eth.c | 6 ++++--
drivers/net/pxa168_eth.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/2] pxa168_eth: fix race in transmit path.
From: Richard Cochran @ 2011-06-20 7:48 UTC (permalink / raw)
To: netdev
Cc: David Miller, Eric Dumazet, stable, Sachin Sanap, Zhangfei Gao,
Philip Rakity
In-Reply-To: <cover.1308555865.git.richard.cochran@omicron.at>
Because the socket buffer is freed in the completion interrupt, it is not
safe to access it after submitting it to the hardware.
Cc: stable@kernel.org
Cc: Sachin Sanap <ssanap@marvell.com>
Cc: Zhangfei Gao <zgao6@marvell.com>
Cc: Philip Rakity <prakity@marvell.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/pxa168_eth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index 89f7540..5f597ca 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -1273,7 +1273,7 @@ static int pxa168_eth_start_xmit(struct sk_buff *skb, struct net_device *dev)
wmb();
wrl(pep, SDMA_CMD, SDMA_CMD_TXDH | SDMA_CMD_ERD);
- stats->tx_bytes += skb->len;
+ stats->tx_bytes += length;
stats->tx_packets++;
dev->trans_start = jiffies;
if (pep->tx_ring_size - pep->tx_desc_count <= 1) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] mv643xx_eth: fix race in trasmit path.
From: Richard Cochran @ 2011-06-20 7:48 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Eric Dumazet, stable, Lennert Buytenhek
In-Reply-To: <cover.1308555865.git.richard.cochran@omicron.at>
Because the socket buffer is freed in the completion interrupt, it is not
safe to access it after submitting it to the hardware.
Cc: stable@kernel.org
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/mv643xx_eth.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index a5d9b1c..1b7d2c1 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -859,7 +859,7 @@ no_csum:
static netdev_tx_t mv643xx_eth_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct mv643xx_eth_private *mp = netdev_priv(dev);
- int queue;
+ int length, queue;
struct tx_queue *txq;
struct netdev_queue *nq;
@@ -881,10 +881,12 @@ static netdev_tx_t mv643xx_eth_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
+ length = skb->len;
+
if (!txq_submit_skb(txq, skb)) {
int entries_left;
- txq->tx_bytes += skb->len;
+ txq->tx_bytes += length;
txq->tx_packets++;
entries_left = txq->tx_ring_size - txq->tx_desc_count;
--
1.7.0.4
^ permalink raw reply related
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