* [For..2-6]玛奃 [EndFor]...
From: Vanda Schrum @ 2012-06-10 4:34 UTC (permalink / raw)
To: prmexgrniz520@yahoo.com
瞕胂 驜帀診刨 臗予棜 穣柎 瞃釭陼條 夘 敜嗈楬噬佺 熢 籃殱 輵 绾 鄿褸灎廝 涌眲籆 湏徱垈荝蚉 艢鬪褛憯 奛 汇 摤陯 呸擢...
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: Fengguang Wu @ 2012-06-10 4:43 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120609.212147.1738198233131370927.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sat, Jun 09, 2012 at 09:21:47PM -0700, David Miller wrote:
> From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date: Sun, 10 Jun 2012 11:16:34 +0800
>
> > In long run, such build-fix patches can also be auto tested and
> > reported, somehow in this way. You just create a temporary branch
>
> Sorry, no.
That's fine. Then how about including some text "fix build errors" or
"fix build warnings" or paste the original gcc error/warning messages,
somewhere in the changelog or subject?
That will also allow me recognize that it's a build fix commit and to
make it unconditionally report back any build results.
Thanks,
Fengguang
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: Fengguang Wu @ 2012-06-10 4:49 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120610044339.GA10436@localhost>
On Sun, Jun 10, 2012 at 12:43:39PM +0800, Fengguang Wu wrote:
> On Sat, Jun 09, 2012 at 09:21:47PM -0700, David Miller wrote:
> > From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > Date: Sun, 10 Jun 2012 11:16:34 +0800
> >
> > > In long run, such build-fix patches can also be auto tested and
> > > reported, somehow in this way. You just create a temporary branch
> >
> > Sorry, no.
>
> That's fine. Then how about including some text "fix build errors" or
> "fix build warnings" or paste the original gcc error/warning messages,
> somewhere in the changelog or subject?
>
> That will also allow me recognize that it's a build fix commit and to
> make it unconditionally report back any build results.
Or better, simply include a
Reported-by: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
line in the commit. Then I can reliably detect that it actually tries
to fix some build error/waring reported by me, and verbosely report
back whether the commit actually fix things up.
Thanks,
Fengguang
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: David Miller @ 2012-06-10 5:03 UTC (permalink / raw)
To: wfg-VuQAYsv1563Yd54FQh9/CA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120610044339.GA10436@localhost>
From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date: Sun, 10 Jun 2012 12:43:39 +0800
> That will also allow me recognize that it's a build fix commit and to
> make it unconditionally report back any build results.
How many extra tasks do you want me to add to my already backlogged
workflow?
I'm not doing extra work for you, sorry.
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: David Miller @ 2012-06-10 5:04 UTC (permalink / raw)
To: wfg-VuQAYsv1563Yd54FQh9/CA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120610044934.GA10507@localhost>
From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date: Sun, 10 Jun 2012 12:49:34 +0800
> On Sun, Jun 10, 2012 at 12:43:39PM +0800, Fengguang Wu wrote:
>> On Sat, Jun 09, 2012 at 09:21:47PM -0700, David Miller wrote:
>> > From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> > Date: Sun, 10 Jun 2012 11:16:34 +0800
>> >
>> > > In long run, such build-fix patches can also be auto tested and
>> > > reported, somehow in this way. You just create a temporary branch
>> >
>> > Sorry, no.
>>
>> That's fine. Then how about including some text "fix build errors" or
>> "fix build warnings" or paste the original gcc error/warning messages,
>> somewhere in the changelog or subject?
>>
>> That will also allow me recognize that it's a build fix commit and to
>> make it unconditionally report back any build results.
>
> Or better, simply include a
>
> Reported-by: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Now that on the other hand I should have done and was an oversight.
But all the other crap, is absolutely unreasonable of you to ask of me.
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4, 6}/route.c
From: Gao feng @ 2012-06-10 5:14 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
wfg-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <20120609.190929.1165462964087672866.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
于 2012年06月10日 10:09, David Miller 写道:
> From: Fengguang Wu <wfg@linux.intel.com>
> Date: Sun, 10 Jun 2012 10:08:01 +0800
>
>> And in another config, an old error still triggers:
>>
>> net/ipv4/inetpeer.c: In function ‘family_to_base’:
>> net/ipv4/inetpeer.c:397:50: error: ‘struct net’ has no member named ‘ipv6’
>> net/ipv4/inetpeer.c:398:1: warning: control reaches end of non-void function [-Wreturn-type]
>>
>> I'm building this patch on top of net-next master.
>
> What a fucking mess Gao created, I'll fix this.
Ok,I am sorry for these things.
Please just keep cool,If I introduce some messes,I will fix it.
Thanks!
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Rusty Russell @ 2012-06-10 6:36 UTC (permalink / raw)
To: Eric Dumazet, Jason Wang
Cc: netdev, Stephen Hemminger, mst, linux-kernel, virtualization
In-Reply-To: <1338972341.2760.3944.camel@edumazet-glaptop>
On Wed, 06 Jun 2012 10:45:41 +0200, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-06-06 at 10:35 +0200, Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > commit 3fa2a1df909 (virtio-net: per cpu 64 bit stats (v2)) added a race
> > on 32bit arches.
> >
> > We must use separate syncp for rx and tx path as they can be run at the
> > same time on different cpus. Thus one sequence increment can be lost and
> > readers spin forever.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Stephen Hemminger <shemminger@vyatta.com>
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: Jason Wang <jasowang@redhat.com>
> > ---
>
> Just to make clear : even using percpu stats/syncp, we have no guarantee
> that write_seqcount_begin() is done with one instruction. [1]
>
> It is OK on x86 if "incl" instruction is generated by the compiler, but
> on a RISC cpu, the "load memory,%reg ; inc %reg ; store %reg,memory" can
> be interrupted.
>
> So if you are 100% sure all paths are safe against preemption/BH, then
> this patch is not needed, but a big comment in the code would avoid
> adding possible races in the future.
Too fragile; let's keep them separate as per this patch.
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: Fengguang Wu @ 2012-06-10 6:47 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120609.220421.2043389435765629622.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sat, Jun 09, 2012 at 10:04:21PM -0700, David Miller wrote:
> From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date: Sun, 10 Jun 2012 12:49:34 +0800
>
> > On Sun, Jun 10, 2012 at 12:43:39PM +0800, Fengguang Wu wrote:
> >> On Sat, Jun 09, 2012 at 09:21:47PM -0700, David Miller wrote:
> >> > From: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >> > Date: Sun, 10 Jun 2012 11:16:34 +0800
> >> >
> >> > > In long run, such build-fix patches can also be auto tested and
> >> > > reported, somehow in this way. You just create a temporary branch
> >> >
> >> > Sorry, no.
> >>
> >> That's fine. Then how about including some text "fix build errors" or
> >> "fix build warnings" or paste the original gcc error/warning messages,
> >> somewhere in the changelog or subject?
> >>
> >> That will also allow me recognize that it's a build fix commit and to
> >> make it unconditionally report back any build results.
> >
> > Or better, simply include a
> >
> > Reported-by: Fengguang Wu <wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Now that on the other hand I should have done and was an oversight.
That's fine.
Please feel free to add that "Reported-by" to get verbose build report,
as well as to _NOT_ add the above line to avoid receiving reports when
the fix is obviously correct.
Ie. use the tag as a way to control my script.
> But all the other crap, is absolutely unreasonable of you to ask of me.
Yup.. Thanks for your time!
Regards,
Fengguang
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Michael S. Tsirkin @ 2012-06-10 7:03 UTC (permalink / raw)
To: Rusty Russell
Cc: Eric Dumazet, netdev, linux-kernel, virtualization,
Stephen Hemminger
In-Reply-To: <87ipezhdvx.fsf@rustcorp.com.au>
On Sun, Jun 10, 2012 at 04:06:34PM +0930, Rusty Russell wrote:
> On Wed, 06 Jun 2012 10:45:41 +0200, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Wed, 2012-06-06 at 10:35 +0200, Eric Dumazet wrote:
> > > From: Eric Dumazet <edumazet@google.com>
> > >
> > > commit 3fa2a1df909 (virtio-net: per cpu 64 bit stats (v2)) added a race
> > > on 32bit arches.
> > >
> > > We must use separate syncp for rx and tx path as they can be run at the
> > > same time on different cpus. Thus one sequence increment can be lost and
> > > readers spin forever.
> > >
> > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > Cc: Stephen Hemminger <shemminger@vyatta.com>
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Cc: Jason Wang <jasowang@redhat.com>
> > > ---
> >
> > Just to make clear : even using percpu stats/syncp, we have no guarantee
> > that write_seqcount_begin() is done with one instruction. [1]
> >
> > It is OK on x86 if "incl" instruction is generated by the compiler, but
> > on a RISC cpu, the "load memory,%reg ; inc %reg ; store %reg,memory" can
> > be interrupted.
> >
> > So if you are 100% sure all paths are safe against preemption/BH, then
> > this patch is not needed, but a big comment in the code would avoid
> > adding possible races in the future.
>
> Too fragile; let's keep them separate as per this patch.
>
> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
>
> Thanks,
> Rusty.
One question though: do we want to lay the structure
out so that the rx sync structure precedes the rx counters?
--
MST
^ permalink raw reply
* RE: bnx2x: Added EEE support
From: Yuval Mintz @ 2012-06-10 7:47 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120608130921.GA19268@elgon.mountain>
> The patch c8c60d88c59c: "bnx2x: Added EEE support" from Jun 6, 2012,
> leads to the following warning:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:10121
> bnx2x_848x3_config_init()
> error: buffer overflow 'params->req_duplex' 2 <= 4
>
Hi Dan,
You are right - this is indeed an error, although one that shouldn't
affect any existing bnx2x chip supporting EEE.
I'll send a patch correcting it soon.
Thanks,
Yuval
^ permalink raw reply
* Re: PPPoE performance regression
From: David Woodhouse @ 2012-06-10 8:32 UTC (permalink / raw)
To: Nathan Williams; +Cc: Karl Hiramoto, David S. Miller, netdev
In-Reply-To: <1339289425.2661.27.camel@laptop>
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]
On Sun, 2012-06-10 at 10:50 +1000, Nathan Williams wrote:
> > When using iperf with UDP, we can get 20Mbps downstream, but only about
> > 15Mbps throughput when using TCP on a short ADSL line (line sync at
> > 25Mbps). Using iperf to send UDP traffic upstream at the same time
> > doesn't affect the downstream rate.
>
> ...
>
> I found the change responsible for the performance problem and rebuilt
> OpenWrt with the patch reversed on kernel 3.3.8 to confirm everything
> still works. So the TX buffer is getting full, which causes the netif
> queue to be stopped and restarted after some skbs have been freed?
The *Ethernet* netif queue, yes. But not the PPP netif queue, I believe.
I think the PPP code keeps just blindly calling dev_queue_xmit() and
throwing away packets when they're not accepted.
> commit 137742cf9738f1b4784058ff79aec7ca85e769d4
> Author: Karl Hiramoto <karl@hiramoto.org>
> Date: Wed Sep 2 23:26:39 2009 -0700
>
> atm/br2684: netif_stop_queue() when atm device busy and
> netif_wake_queue() when we can send packets again.
Nice work; well done finding that. I've added Karl and DaveM, and the
netdev@ list to Cc.
(Btw, I assume the performance problem also goes away if you use PPPoA?
I've made changes in the PPPoA code recently to *eliminate* excessive
calls to netif_wake_queue(), and also to stop it from filling the ATM
device queue. That was commit 9d02daf7 in 3.5-rc1, which is already in
OpenWRT.)
I was already looking vaguely at how we could limit the PPP queue depth
for PPPoE and implement byte queue limits. Currently the PPP code just
throws the packets at the Ethernet device and considers them 'gone',
which is why it's hitting the ATM limits all the time. The patch you
highlight is changing the behaviour in a case that should never *happen*
with PPP. It's suffering massive queue bloat if it's filling the ATM
queue, and we should fix *that*.
I was looking to see if we could (ab)use the skb->destructor somehow so
that we get *notified* when the packet is actually sent (or dropped),
and then that would allow us to manage the queue 'downstream' of PPP
more sanely. But I haven't really got very far with that yet.
I was planning to find some time to look into it a bit better, and then
send mail to netdev@ asking for more clue. But since you're now falling
over it and it isn't just a theoretical problem, this mail will have to
suffice for now...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* [PATCH 1/1 v3] Ethtool: Add EEE support
From: Yuval Mintz @ 2012-06-10 8:48 UTC (permalink / raw)
To: bhutchings, netdev; +Cc: eilong, peppe.cavallaro, Yuval Mintz
This patch adds 2 new ethtool commands which can be
used to manipulate network interfaces' support in
EEE.
Output of 'get' has the following form:
EEE Settings for p2p1:
EEE status: enabled - active
Tx LPI: 1000 (us)
Supported EEE link modes: 10000baseT/Full
Advertised EEE link modes: 10000baseT/Full
Link partner advertised EEE link modes: 10000baseT/Full
Thanks goes to Giuseppe Cavallaro for his original patch.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
Changes from Version 2:
- Changed --get-eee into --show-eee
- Corrected EEE tests in test-cmdline.c
- Corrected documentation
---
ethtool.8.in | 32 +++++++++++++
ethtool.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++--------
test-cmdline.c | 11 +++++
3 files changed, 159 insertions(+), 20 deletions(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 70ae31d..178322b 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -325,6 +325,16 @@ ethtool \- query or control network driver and hardware settings
.I devname flag
.A1 on off
.RB ...
+.HP
+.B ethtool \-\-show\-eee
+.I devname
+.HP
+.B ethtool \-\-set\-eee
+.I devname
+.B2 eee on off
+.B2 tx-lpi on off
+.BN tx-timer
+.BN advertise
.
.\" Adjust lines (i.e. full justification) and hyphenate.
.ad
@@ -810,6 +820,28 @@ Sets the device's private flags as specified.
.I flag
.A1 on off
Sets the state of the named private flag.
+.TP
+.B \-\-show\-eee
+Queries the specified network device for its support of Efficient Energy
+Ethernet (according to the IEEE 802.3az specifications)
+.TP
+.B \-\-set\-eee
+Sets the device EEE behaviour.
+.TP
+.A2 eee on off
+Enables/disables the device support of EEE.
+.TP
+.A2 tx-lpi on off
+Determines whether the device should assert its Tx LPI.
+.TP
+.BI advertise \ N
+Sets the speeds for which the device should advertise EEE capabiliities.
+Values are as for
+.B \-\-change advertise
+.TP
+.BI tx-timer \ N
+Sets the amount of time the device should stay in idle mode prior to asserting
+its Tx LPI (in microseconds). This has meaning only when Tx LPI is enabled.
.SH BUGS
Not supported (in part or whole) on all network drivers.
.SH AUTHOR
diff --git a/ethtool.c b/ethtool.c
index f09a032..73e0e28 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -416,7 +416,8 @@ static int do_version(struct cmd_context *ctx)
return 0;
}
-static void dump_link_caps(const char *prefix, const char *an_prefix, u32 mask);
+static void dump_link_caps(const char *prefix, const char *an_prefix, u32 mask,
+ int link_mode_only);
static void dump_supported(struct ethtool_cmd *ep)
{
@@ -435,14 +436,15 @@ static void dump_supported(struct ethtool_cmd *ep)
fprintf(stdout, "FIBRE ");
fprintf(stdout, "]\n");
- dump_link_caps("Supported", "Supports", mask);
+ dump_link_caps("Supported", "Supports", mask, 0);
}
/* Print link capability flags (supported, advertised or lp_advertised).
* Assumes that the corresponding SUPPORTED and ADVERTISED flags are equal.
*/
static void
-dump_link_caps(const char *prefix, const char *an_prefix, u32 mask)
+dump_link_caps(const char *prefix, const char *an_prefix, u32 mask,
+ int link_mode_only)
{
int indent;
int did1;
@@ -527,24 +529,26 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask)
fprintf(stdout, "Not reported");
fprintf(stdout, "\n");
- fprintf(stdout, " %s pause frame use: ", prefix);
- if (mask & ADVERTISED_Pause) {
- fprintf(stdout, "Symmetric");
- if (mask & ADVERTISED_Asym_Pause)
- fprintf(stdout, " Receive-only");
- fprintf(stdout, "\n");
- } else {
- if (mask & ADVERTISED_Asym_Pause)
- fprintf(stdout, "Transmit-only\n");
+ if (!link_mode_only) {
+ fprintf(stdout, " %s pause frame use: ", prefix);
+ if (mask & ADVERTISED_Pause) {
+ fprintf(stdout, "Symmetric");
+ if (mask & ADVERTISED_Asym_Pause)
+ fprintf(stdout, " Receive-only");
+ fprintf(stdout, "\n");
+ } else {
+ if (mask & ADVERTISED_Asym_Pause)
+ fprintf(stdout, "Transmit-only\n");
+ else
+ fprintf(stdout, "No\n");
+ }
+
+ fprintf(stdout, " %s auto-negotiation: ", an_prefix);
+ if (mask & ADVERTISED_Autoneg)
+ fprintf(stdout, "Yes\n");
else
fprintf(stdout, "No\n");
}
-
- fprintf(stdout, " %s auto-negotiation: ", an_prefix);
- if (mask & ADVERTISED_Autoneg)
- fprintf(stdout, "Yes\n");
- else
- fprintf(stdout, "No\n");
}
static int dump_ecmd(struct ethtool_cmd *ep)
@@ -552,10 +556,11 @@ static int dump_ecmd(struct ethtool_cmd *ep)
u32 speed;
dump_supported(ep);
- dump_link_caps("Advertised", "Advertised", ep->advertising);
+ dump_link_caps("Advertised", "Advertised", ep->advertising, 0);
if (ep->lp_advertising)
dump_link_caps("Link partner advertised",
- "Link partner advertised", ep->lp_advertising);
+ "Link partner advertised", ep->lp_advertising,
+ 0);
fprintf(stdout, " Speed: ");
speed = ethtool_cmd_speed(ep);
@@ -1234,6 +1239,34 @@ static int dump_rxfhash(int fhash, u64 val)
return 0;
}
+static void dump_eeecmd(struct ethtool_eee *ep)
+{
+
+ fprintf(stdout, " EEE status: ");
+ if (!ep->supported) {
+ fprintf(stdout, "not supported\n");
+ return;
+ } else if (!ep->eee_enabled) {
+ fprintf(stdout, "disabled\n");
+ } else {
+ fprintf(stdout, "enabled - ");
+ if (ep->eee_active)
+ fprintf(stdout, "active\n");
+ else
+ fprintf(stdout, "inactive\n");
+ }
+
+ fprintf(stdout, " Tx LPI:");
+ if (ep->tx_lpi_enabled)
+ fprintf(stdout, " %d (us)\n", ep->tx_lpi_timer);
+ else
+ fprintf(stdout, " disabled\n");
+
+ dump_link_caps("Supported EEE", "", ep->supported, 1);
+ dump_link_caps("Advertised EEE", "", ep->advertised, 1);
+ dump_link_caps("Link partner advertised EEE", "", ep->lp_advertised, 1);
+}
+
#define N_SOTS 7
static char *so_timestamping_labels[N_SOTS] = {
@@ -3463,6 +3496,63 @@ static int do_getmodule(struct cmd_context *ctx)
return 0;
}
+static int do_geee(struct cmd_context *ctx)
+{
+ struct ethtool_eee eeecmd;
+
+ if (ctx->argc != 0)
+ exit_bad_args();
+
+ eeecmd.cmd = ETHTOOL_GEEE;
+ if (send_ioctl(ctx, &eeecmd)) {
+ perror("Cannot get EEE settings");
+ return 1;
+ }
+
+ fprintf(stdout, "EEE Settings for %s:\n", ctx->devname);
+ dump_eeecmd(&eeecmd);
+
+ return 0;
+}
+
+static int do_seee(struct cmd_context *ctx)
+{
+ int adv_c = -1, lpi_c = -1, lpi_time_c = -1, eee_c = -1;
+ int change = -1, change2 = -1;
+ struct ethtool_eee eeecmd;
+ struct cmdline_info cmdline_eee[] = {
+ { "advertise", CMDL_U32, &adv_c, &eeecmd.advertised },
+ { "tx-lpi", CMDL_BOOL, &lpi_c, &eeecmd.tx_lpi_enabled },
+ { "tx-timer", CMDL_U32, &lpi_time_c, &eeecmd.tx_lpi_timer},
+ { "eee", CMDL_BOOL, &eee_c, &eeecmd.eee_enabled},
+ };
+
+ if (ctx->argc == 0)
+ exit_bad_args();
+
+ parse_generic_cmdline(ctx, &change, cmdline_eee,
+ ARRAY_SIZE(cmdline_eee));
+
+ eeecmd.cmd = ETHTOOL_GEEE;
+ if (send_ioctl(ctx, &eeecmd)) {
+ perror("Cannot get EEE settings");
+ return 1;
+ }
+
+ do_generic_set(cmdline_eee, ARRAY_SIZE(cmdline_eee), &change2);
+
+ if (change2) {
+
+ eeecmd.cmd = ETHTOOL_SEEE;
+ if (send_ioctl(ctx, &eeecmd)) {
+ perror("Cannot set EEE settings");
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
#ifndef TEST_ETHTOOL
int send_ioctl(struct cmd_context *ctx, void *cmd)
{
@@ -3611,6 +3701,12 @@ static const struct option {
" [ hex on|off ]\n"
" [ offset N ]\n"
" [ length N ]\n" },
+ { "--show-eee", 1, do_geee, "Show EEE settings"},
+ { "--set-eee", 1, do_seee, "Set EEE settings",
+ " [ eee on|off ]\n"
+ " [ advertise %x ]\n"
+ " [ tx-lpi on|off ]\n"
+ " [ tx-timer %d ]\n"},
{ "-h|--help", 0, show_usage, "Show this help" },
{ "--version", 0, do_version, "Show version number" },
{}
diff --git a/test-cmdline.c b/test-cmdline.c
index 978c312..8fc2b48 100644
--- a/test-cmdline.c
+++ b/test-cmdline.c
@@ -217,6 +217,17 @@ static struct test_case {
{ 0, "-m devname hex off" },
{ 1, "-m devname hex on raw on" },
{ 0, "-m devname offset 4 length 6" },
+ { 1, "--show-eee" },
+ { 0, "--show-eee devname" },
+ { 1, "--show-eee devname foo" },
+ { 1, "--set-eee" },
+ { 1, "--set-eee devname" },
+ { 0, "--set-eee devname eee on" },
+ { 0, "--set-eee devname eee off" },
+ { 0, "--set-eee devname tx-lpi on" },
+ { 0, "--set-eee devname tx-lpi off" },
+ { 1, "--set-eee devname tx-timer foo" },
+ { 1, "--set-eee devname advertise foo" },
/* can't test --set-priv-flags yet */
{ 0, "-h" },
{ 0, "--help" },
--
1.7.9.rc2
^ permalink raw reply related
* Re: [PATCH] inet: Initialize per-netns inetpeer roots in net/ipv{4,6}/route.c
From: Fengguang Wu @ 2012-06-10 10:16 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20120609.221801.2226110181753212240.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sat, Jun 09, 2012 at 10:18:01PM -0400, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sat, 09 Jun 2012 19:09:29 -0700 (PDT)
>
> > From: Fengguang Wu <wfg@linux.intel.com>
> > Date: Sun, 10 Jun 2012 10:08:01 +0800
> >
> >> And in another config, an old error still triggers:
> >>
> >> net/ipv4/inetpeer.c: In function ‘family_to_base’:
> >> net/ipv4/inetpeer.c:397:50: error: ‘struct net’ has no member named ‘ipv6’
> >> net/ipv4/inetpeer.c:398:1: warning: control reaches end of non-void function [-Wreturn-type]
> >>
> >> I'm building this patch on top of net-next master.
> >
> > What a fucking mess Gao created, I'll fix this.
> >
> > Thanks for the report.
>
> I just pushed the following to net-next:
>
> --------------------
> inet: Pass inetpeer root into inet_getpeer*() interfaces.
>
> Otherwise we reference potentially non-existing members when
> ipv6 is disabled.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/net/inetpeer.h | 10 +++++-----
> net/ipv4/inetpeer.c | 9 +--------
> net/ipv4/ip_fragment.c | 2 +-
> net/ipv4/route.c | 6 +++---
> net/ipv6/route.c | 2 +-
> 5 files changed, 11 insertions(+), 18 deletions(-)
It triggers some other errors:
net/ipv4/inetpeer.c: In function ‘inetpeer_invalidate_tree’:
net/ipv4/inetpeer.c:585:9: error: implicit declaration of function ‘family_to_base’ [-Werror=implicit-function-declaration]
net/ipv4/inetpeer.c:585:32: warning: initialization makes pointer from integer without a cast [enabled by default]
net/ipv6/tcp_ipv6.c:1758:2: warning: passing argument 1 of ‘inet_getpeer_v6’ from incompatible pointer type [enabled by default]
include/net/inetpeer.h:101:33: note: expected ‘struct inet_peer_base *’ but argument is of type ‘struct net *’
net/ipv4/tcp_ipv4.c:1843:2: warning: passing argument 1 of ‘inet_getpeer_v4’ from incompatible pointer type [enabled by default]
include/net/inetpeer.h:90:33: note: expected ‘struct inet_peer_base *’ but argument is of type ‘struct net *’
which can be fixed by the following diff.
Thanks,
Fengguang
---
net/ipv4/inetpeer.c | 6 ++++++
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv6/tcp_ipv6.c | 2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 98cf1f8..7ad6b76 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -391,6 +391,12 @@ static void unlink_from_pool(struct inet_peer *p, struct inet_peer_base *base,
call_rcu(&p->rcu, inetpeer_free_rcu);
}
+static struct inet_peer_base *family_to_base(struct net *net,
+ int family)
+{
+ return family == AF_INET ? net->ipv4.peers : net->ipv6.peers;
+}
+
/* perform garbage collect on all items stacked during a lookup */
static int inet_peer_gc(struct inet_peer_base *base,
struct inet_peer __rcu **stack[PEER_MAXDEPTH],
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 77f049d..cf7fe92 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1840,7 +1840,7 @@ void *tcp_v4_tw_get_peer(struct sock *sk)
const struct inet_timewait_sock *tw = inet_twsk(sk);
struct net *net = sock_net(sk);
- return inet_getpeer_v4(net, tw->tw_daddr, 1);
+ return inet_getpeer_v4(net->ipv4.peers, tw->tw_daddr, 1);
}
EXPORT_SYMBOL(tcp_v4_tw_get_peer);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index b5ecf37..927c029 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1755,7 +1755,7 @@ static void *tcp_v6_tw_get_peer(struct sock *sk)
if (tw->tw_family == AF_INET)
return tcp_v4_tw_get_peer(sk);
- return inet_getpeer_v6(net, &tw6->tw_v6_daddr, 1);
+ return inet_getpeer_v6(net->ipv6.peers, &tw6->tw_v6_daddr, 1);
}
static struct timewait_sock_ops tcp6_timewait_sock_ops = {
--
1.7.10
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply related
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Eric Dumazet @ 2012-06-10 10:21 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, virtualization, Stephen Hemminger
In-Reply-To: <20120610070325.GA14010@redhat.com>
On Sun, 2012-06-10 at 10:03 +0300, Michael S. Tsirkin wrote:
> One question though: do we want to lay the structure
> out so that the rx sync structure precedes the rx counters?
>
I am not sure its worth having holes in the structure, since its percpu
data.
That would be 8 bytes lost per cpu and per device.
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Michael S. Tsirkin @ 2012-06-10 10:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Rusty Russell, Jason Wang, netdev, linux-kernel, virtualization,
Stephen Hemminger
In-Reply-To: <1339323674.6001.246.camel@edumazet-glaptop>
On Sun, Jun 10, 2012 at 12:21:14PM +0200, Eric Dumazet wrote:
> On Sun, 2012-06-10 at 10:03 +0300, Michael S. Tsirkin wrote:
>
> > One question though: do we want to lay the structure
> > out so that the rx sync structure precedes the rx counters?
> >
>
> I am not sure its worth having holes in the structure, since its percpu
> data.
>
> That would be 8 bytes lost per cpu and per device.
Right, I forgot it's per cpu.
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Michael S. Tsirkin @ 2012-06-10 10:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel, virtualization, Stephen Hemminger
In-Reply-To: <1338971724.2760.3913.camel@edumazet-glaptop>
On Wed, Jun 06, 2012 at 10:35:24AM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 3fa2a1df909 (virtio-net: per cpu 64 bit stats (v2)) added a race
> on 32bit arches.
>
> We must use separate syncp for rx and tx path as they can be run at the
> same time on different cpus. Thus one sequence increment can be lost and
> readers spin forever.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
I'm still thinking about moving tx to take a xmit lock long term,
meanwhile this fix appears appropriate for 3.5.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Dave, can you pick this up pls?
> ---
> drivers/net/virtio_net.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 5214b1e..f18149a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -42,7 +42,8 @@ module_param(gso, bool, 0444);
> #define VIRTNET_DRIVER_VERSION "1.0.0"
>
> struct virtnet_stats {
> - struct u64_stats_sync syncp;
> + struct u64_stats_sync tx_syncp;
> + struct u64_stats_sync rx_syncp;
> u64 tx_bytes;
> u64 tx_packets;
>
> @@ -300,10 +301,10 @@ static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
>
> hdr = skb_vnet_hdr(skb);
>
> - u64_stats_update_begin(&stats->syncp);
> + u64_stats_update_begin(&stats->rx_syncp);
> stats->rx_bytes += skb->len;
> stats->rx_packets++;
> - u64_stats_update_end(&stats->syncp);
> + u64_stats_update_end(&stats->rx_syncp);
>
> if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
> pr_debug("Needs csum!\n");
> @@ -565,10 +566,10 @@ static unsigned int free_old_xmit_skbs(struct virtnet_info *vi)
> while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> pr_debug("Sent skb %p\n", skb);
>
> - u64_stats_update_begin(&stats->syncp);
> + u64_stats_update_begin(&stats->tx_syncp);
> stats->tx_bytes += skb->len;
> stats->tx_packets++;
> - u64_stats_update_end(&stats->syncp);
> + u64_stats_update_end(&stats->tx_syncp);
>
> tot_sgs += skb_vnet_hdr(skb)->num_sg;
> dev_kfree_skb_any(skb);
> @@ -703,12 +704,16 @@ static struct rtnl_link_stats64 *virtnet_stats(struct net_device *dev,
> u64 tpackets, tbytes, rpackets, rbytes;
>
> do {
> - start = u64_stats_fetch_begin(&stats->syncp);
> + start = u64_stats_fetch_begin(&stats->tx_syncp);
> tpackets = stats->tx_packets;
> tbytes = stats->tx_bytes;
> + } while (u64_stats_fetch_retry(&stats->tx_syncp, start));
> +
> + do {
> + start = u64_stats_fetch_begin(&stats->rx_syncp);
> rpackets = stats->rx_packets;
> rbytes = stats->rx_bytes;
> - } while (u64_stats_fetch_retry(&stats->syncp, start));
> + } while (u64_stats_fetch_retry(&stats->rx_syncp, start));
>
> tot->rx_packets += rpackets;
> tot->tx_packets += tpackets;
>
^ permalink raw reply
* [PATCH] ieee802154: verify packet size before trying to allocate it
From: Sasha Levin @ 2012-06-10 11:10 UTC (permalink / raw)
To: dbaryshkov, slapin, davem
Cc: linux-zigbee-devel, netdev, linux-kernel, Sasha Levin
Currently when sending data over datagram, the send function will attempt to
allocate any size passed on from the userspace.
We should make sure that this size is checked and limited. The maximum size
of an IP packet seemed like the safest limit here.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
Change in v2:
- Limit by maximum size the protocol supports.
net/ieee802154/dgram.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 6fbb2ad..628498c 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -232,6 +232,11 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
hlen = LL_RESERVED_SPACE(dev);
tlen = dev->needed_tailroom;
+ if (hlen + tlen + size > IEEE802154_MTU) {
+ err = -EMSGSIZE;
+ goto out;
+ }
+
skb = sock_alloc_send_skb(sk, hlen + tlen + size,
msg->msg_flags & MSG_DONTWAIT,
&err);
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH] ieee802154: verify packet size before trying to allocate it
From: Alan Cox @ 2012-06-10 11:24 UTC (permalink / raw)
To: Sasha Levin
Cc: dbaryshkov, slapin, davem, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <1339326619-1753-1-git-send-email-levinsasha928@gmail.com>
On Sun, 10 Jun 2012 13:10:19 +0200
Sasha Levin <levinsasha928@gmail.com> wrote:
> Currently when sending data over datagram, the send function will attempt to
> allocate any size passed on from the userspace.
>
> We should make sure that this size is checked and limited. The maximum size
> of an IP packet seemed like the safest limit here.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
>
> Change in v2:
> - Limit by maximum size the protocol supports.
>
> net/ieee802154/dgram.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
> index 6fbb2ad..628498c 100644
> --- a/net/ieee802154/dgram.c
> +++ b/net/ieee802154/dgram.c
> @@ -232,6 +232,11 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
>
> hlen = LL_RESERVED_SPACE(dev);
> tlen = dev->needed_tailroom;
> + if (hlen + tlen + size > IEEE802154_MTU) {
> + err = -EMSGSIZE;
> + goto out;
What stops an overflow at this point. We'll then pass a small value to
sock_alloc_send_skb/sock_alloc_send_pskb and copy a large number of bytes
into it.
This does seem to be already broken, and not fixed by the patch ?
Alan
^ permalink raw reply
* Re: Deadlock, L2TP over IP are not working, 3.4.1
From: Hong zhi guo @ 2012-06-10 12:14 UTC (permalink / raw)
To: Eric Dumazet, davem
Cc: Denys Fedoryshchenko, Benjamin LaHaise, Francois Romieu, netdev,
linux-kernel
In-Reply-To: <1339171495.6001.118.camel@edumazet-glaptop>
Is there any conclusion about the problem? Will bh_lock_sock_nested
fix the lockdep violation?
On Sat, Jun 9, 2012 at 12:04 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-06-08 at 18:56 +0300, Denys Fedoryshchenko wrote:
>
>> Right now i am routing around 700Mbps over there, and noticed some
>> problem with pskb_expand_head,
>> but that's separate question i will ask, if i will not be able to sort
>> it out by myself.
>>
>
> Before spending too much time on this, make sure you use a kernel
> including commit 617c8c11236 ( skb: avoid unnecessary reallocations in
> __skb_cow )
>
>
>
> --
> 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
--
best regards
hong zhi guo
^ permalink raw reply
* Re: [PATCH] ieee802154: verify packet size before trying to allocate it
From: Sasha Levin @ 2012-06-10 12:16 UTC (permalink / raw)
To: Alan Cox
Cc: dbaryshkov, slapin, davem, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <20120610122435.7d5c8fa7@pyramind.ukuu.org.uk>
Hi Alan,
On Sun, 2012-06-10 at 12:24 +0100, Alan Cox wrote:
> On Sun, 10 Jun 2012 13:10:19 +0200
> Sasha Levin <levinsasha928@gmail.com> wrote:
> > + if (hlen + tlen + size > IEEE802154_MTU) {
> > + err = -EMSGSIZE;
> > + goto out;
>
> What stops an overflow at this point. We'll then pass a small value to
> sock_alloc_send_skb/sock_alloc_send_pskb and copy a large number of bytes
> into it.
>
> This does seem to be already broken, and not fixed by the patch ?
>
> Alan
Hm, nothing.
I've added this check to prevent users from being able to allocate huge kernel buffers, and haven't though about the overflow case at all. Thanks for pointing it out.
How about something like this instead:
-----8<-----
From: Sasha Levin <levinsasha928@gmail.com>
Date: Sun, 10 Jun 2012 13:08:03 +0200
Subject: [PATCH] ieee802154: verify packet size before trying to allocate it
Currently when sending data over datagram, the send function will attempt to
allocate any size passed on from the userspace.
We should make sure that this size is checked and limited. The maximum size
of an IP packet seemed like the safest limit here.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/ieee802154/dgram.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 6fbb2ad..b098b9c 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -230,6 +230,12 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
mtu = dev->mtu;
pr_debug("name = %s, mtu = %u\n", dev->name, mtu);
+ if (size > mtu) {
+ pr_debug("size = %Zu, mtu = %u\n", size, mtu);
+ err = -EINVAL;
+ goto out_skb;
+ }
+
hlen = LL_RESERVED_SPACE(dev);
tlen = dev->needed_tailroom;
skb = sock_alloc_send_skb(sk, hlen + tlen + size,
@@ -258,12 +264,6 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
if (err < 0)
goto out_skb;
- if (size > mtu) {
- pr_debug("size = %Zu, mtu = %u\n", size, mtu);
- err = -EINVAL;
- goto out_skb;
- }
-
skb->dev = dev;
skb->sk = sk;
skb->protocol = htons(ETH_P_IEEE802154);
^ permalink raw reply related
* Re: [PATCH] ieee802154: verify packet size before trying to allocate it
From: Jan Ceuleers @ 2012-06-10 12:55 UTC (permalink / raw)
To: Sasha Levin
Cc: dbaryshkov, slapin, davem, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <1339326619-1753-1-git-send-email-levinsasha928@gmail.com>
On 06/10/2012 01:10 PM, Sasha Levin wrote:
> Currently when sending data over datagram, the send function will attempt to
> allocate any size passed on from the userspace.
>
> We should make sure that this size is checked and limited. The maximum size
> of an IP packet seemed like the safest limit here.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
As I understand it this issue was present in the original code that was
introduced in 2.6.31 RC1. Should this therefore be submitted to stable
(in which case David will do so)?
Commit ID 9ec7671603573ede31207eb5b0b3e1aa211b2854
Thanks, Jan
^ permalink raw reply
* Re: Deadlock, L2TP over IP are not working, 3.4.1
From: Eric Dumazet @ 2012-06-10 13:31 UTC (permalink / raw)
To: Hong zhi guo
Cc: davem, Denys Fedoryshchenko, Benjamin LaHaise, Francois Romieu,
netdev, linux-kernel
In-Reply-To: <CAA7+ByWEZDqzZhzH0FZoapqfUrujUrxyjwp6qb1SSfWBTZ=4AA@mail.gmail.com>
On Sun, 2012-06-10 at 20:14 +0800, Hong zhi guo wrote:
> Is there any conclusion about the problem? Will bh_lock_sock_nested
> fix the lockdep violation?
lockdep violation could indeed be fixed like that, but LLTX seems more
appropriate.
But there is still a bug because skb->len is used after
l2tp_xmit_skb(session, skb, session->hdr_len);
There is also a bug in l2tp_core.c, because it assumes RX path is not
reentrant. That should be fixed eventually.
I believe we could avoid percpu stuf and new locking, adding the
following unions in net_device_stats. It seems enough to have machine
long words stats, no need to force 64bit stats on 32bit arches.
include/linux/netdevice.h | 40 ++++++++++++++++++++++++++++--------
net/l2tp/l2tp_eth.c | 29 +++++++++++++-------------
2 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d94cb14..1dee75a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -171,14 +171,38 @@ static inline bool dev_xmit_complete(int rc)
*/
struct net_device_stats {
- unsigned long rx_packets;
- unsigned long tx_packets;
- unsigned long rx_bytes;
- unsigned long tx_bytes;
- unsigned long rx_errors;
- unsigned long tx_errors;
- unsigned long rx_dropped;
- unsigned long tx_dropped;
+ union {
+ unsigned long rx_packets;
+ atomic_long_t rx_packets_atomic;
+ };
+ union {
+ unsigned long tx_packets;
+ atomic_long_t tx_packets_atomic;
+ };
+ union {
+ unsigned long rx_bytes;
+ atomic_long_t rx_bytes_atomic;
+ };
+ union {
+ unsigned long tx_bytes;
+ atomic_long_t tx_bytes_atomic;
+ };
+ union {
+ unsigned long rx_errors;
+ atomic_long_t rx_errors_atomic;
+ };
+ union {
+ unsigned long tx_errors;
+ atomic_long_t tx_errors_atomic;
+ };
+ union {
+ unsigned long rx_dropped;
+ atomic_long_t rx_dropped_atomic;
+ };
+ union {
+ unsigned long tx_dropped;
+ atomic_long_t tx_dropped_atomic;
+ };
unsigned long multicast;
unsigned long collisions;
unsigned long rx_length_errors;
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 185f12f..9e80ec4 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -83,20 +83,20 @@ static void l2tp_eth_dev_uninit(struct net_device *dev)
dev_put(dev);
}
-static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct l2tp_eth *priv = netdev_priv(dev);
struct l2tp_session *session = priv->session;
- l2tp_xmit_skb(session, skb, session->hdr_len);
+ atomic_long_add(skb->len, &dev->stats.tx_bytes_atomic);
+ atomic_long_inc(&dev->stats.tx_packets_atomic);
- dev->stats.tx_bytes += skb->len;
- dev->stats.tx_packets++;
+ l2tp_xmit_skb(session, skb, session->hdr_len);
- return 0;
+ return NETDEV_TX_OK;
}
-static struct net_device_ops l2tp_eth_netdev_ops = {
+static const struct net_device_ops l2tp_eth_netdev_ops = {
.ndo_init = l2tp_eth_dev_init,
.ndo_uninit = l2tp_eth_dev_uninit,
.ndo_start_xmit = l2tp_eth_dev_xmit,
@@ -106,8 +106,9 @@ static void l2tp_eth_dev_setup(struct net_device *dev)
{
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
- dev->netdev_ops = &l2tp_eth_netdev_ops;
- dev->destructor = free_netdev;
+ dev->features |= NETIF_F_LLTX;
+ dev->netdev_ops = &l2tp_eth_netdev_ops;
+ dev->destructor = free_netdev;
}
static void l2tp_eth_dev_recv(struct l2tp_session *session, struct sk_buff *skb, int data_len)
@@ -139,15 +140,15 @@ static void l2tp_eth_dev_recv(struct l2tp_session *session, struct sk_buff *skb,
nf_reset(skb);
if (dev_forward_skb(dev, skb) == NET_RX_SUCCESS) {
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += data_len;
- } else
- dev->stats.rx_errors++;
-
+ atomic_long_inc(&dev->stats.rx_packets_atomic);
+ atomic_long_add(data_len, &dev->stats.rx_bytes_atomic);
+ } else {
+ atomic_long_inc(&dev->stats.rx_errors_atomic);
+ }
return;
error:
- dev->stats.rx_errors++;
+ atomic_long_inc(&dev->stats.rx_errors_atomic);
kfree_skb(skb);
}
^ permalink raw reply related
* Re: Deadlock, L2TP over IP are not working, 3.4.1
From: Eric Dumazet @ 2012-06-10 13:38 UTC (permalink / raw)
To: Hong zhi guo
Cc: davem, Denys Fedoryshchenko, Benjamin LaHaise, Francois Romieu,
netdev, linux-kernel
In-Reply-To: <1339335061.6001.466.camel@edumazet-glaptop>
On Sun, 2012-06-10 at 15:31 +0200, Eric Dumazet wrote:
> include/linux/netdevice.h | 40 ++++++++++++++++++++++++++++--------
> net/l2tp/l2tp_eth.c | 29 +++++++++++++-------------
> 2 files changed, 47 insertions(+), 22 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index d94cb14..1dee75a 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -171,14 +171,38 @@ static inline bool dev_xmit_complete(int rc)
> */
>
> struct net_device_stats {
> - unsigned long rx_packets;
> - unsigned long tx_packets;
> - unsigned long rx_bytes;
> - unsigned long tx_bytes;
> - unsigned long rx_errors;
> - unsigned long tx_errors;
> - unsigned long rx_dropped;
> - unsigned long tx_dropped;
> + union {
> + unsigned long rx_packets;
> + atomic_long_t rx_packets_atomic;
> + };
> + union {
> + unsigned long tx_packets;
> + atomic_long_t tx_packets_atomic;
> + };
> + union {
> + unsigned long rx_bytes;
> + atomic_long_t rx_bytes_atomic;
> + };
> + union {
> + unsigned long tx_bytes;
> + atomic_long_t tx_bytes_atomic;
> + };
> + union {
> + unsigned long rx_errors;
> + atomic_long_t rx_errors_atomic;
> + };
> + union {
> + unsigned long tx_errors;
> + atomic_long_t tx_errors_atomic;
> + };
> + union {
> + unsigned long rx_dropped;
> + atomic_long_t rx_dropped_atomic;
> + };
> + union {
> + unsigned long tx_dropped;
> + atomic_long_t tx_dropped_atomic;
> + };
Other choice would be to have a new structure
struct net_device_atomic_stats {
atomic_long_t rx_packets;
atomic_long_t tx_packets;
atomic_long_t rx_bytes;
atomic_long_t tx_bytes;
atomic_long_t rx_errors;
atomic_long_t tx_errors;
atomic_long_t rx_dropped;
atomic_long_t tx_dropped;
...
};
and to union it in :
struct net_device {
...
union {
struct net_device_stats stats;
struct net_device_atomic_stats atom_stats;
};
...
};
^ permalink raw reply
* Re: [PATCH rfc net] Allow the autoconfigured network interface to be renamed.
From: Scott Parlane @ 2012-06-10 15:53 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Scott Parlane
In-Reply-To: <1339228087-14870-1-git-send-email-scott@scottnz.com>
Hi David,
Can you please deliver this patch (my apologies if you have already).
We have been running it for several months on ~80 x86 machines
(against 3.3.0-gentoo)
and have had no issues related to it.
It applied cleanly to tovalds.git and net.git when I created it.
Please let me know if it requires any changes,
I believe I complied with the coding style present in the file.
Kind Regards,
Scott
On Sat, 2012-06-09 at 19:48 +1200, Scott Parlane wrote:
> From: Scott Parlane <scott.parlane@alliedtelesis.co.nz>
>
> if IP_PNP_RENAME_DEV is set, the first interface to be configured
> automatically by the kernel during boot will be renamed.
>
> IP_PNP_DEV_NEWNAME is the name to give the autoconfigured device.
>
> No changes will be made to any interface that is not autoconfigured.
>
> This allows the assurance of the boot device name, without the need
> for an initramfs.
>
> Signed-off-by: Scott Parlane <scott.parlane@alliedtelesis.co.nz>
> ---
> net/ipv4/Kconfig | 17 +++++++++++++++++
> net/ipv4/ipconfig.c | 35 +++++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index 20f1cb5..c85c654 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -163,6 +163,23 @@ config IP_PNP_RARP
> operating on your network. Read
> <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
>
> +config IP_PNP_RENAME_DEV
> + bool "IP: Rename boot device"
> + depends on IP_PNP
> + help
> + If you want to rename the network device you are booting from
> + to something other than eth%d enable this option, and choose the name
> + below. This is helpful if you want to use udev to keep
> + persistent naming of your other interfaces.
> +
> +config IP_PNP_DEV_NEWNAME
> + string "IP: New name of boot device"
> + depends on IP_PNP_RENAME_DEV
> + default "bootnet"
> + help
> + The name to assign to the network device you are booting from
> + when using ip autoconfigure
> +
> config NET_IPIP
> tristate "IP: tunneling"
> select INET_TUNNEL
> diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
> index 67e8a6b..a4b052a 100644
> --- a/net/ipv4/ipconfig.c
> +++ b/net/ipv4/ipconfig.c
> @@ -86,6 +86,10 @@
> #if defined(IPCONFIG_BOOTP) || defined(IPCONFIG_RARP)
> #define IPCONFIG_DYNAMIC
> #endif
> +#if defined(CONFIG_IP_PNP_RENAME_DEV)
> +#define IPCONFIG_RENAME_DEV
> +#define IPCONFIG_DEV_NEWNAME CONFIG_IP_PNP_DEV_NEWNAME
> +#endif
>
> /* Define the friendly delay before and after opening net devices */
> #define CONF_POST_OPEN 10 /* After opening: 10 msecs */
> @@ -360,6 +364,37 @@ static int __init ic_setup_if(void)
>
> memset(&ir, 0, sizeof(ir));
> strcpy(ir.ifr_ifrn.ifrn_name, ic_dev->name);
> +#ifdef IPCONFIG_RENAME_DEV
> + if ((err = ic_dev_ioctl(SIOCGIFFLAGS, &ir)) < 0) {
> + pr_err("IP-Config: Unable to get interface flags (1,%d).\n",
> + err);
> + return -1;
> + }
> + ir.ifr_flags &= ~IFF_UP;
> + if ((err = ic_dev_ioctl(SIOCSIFFLAGS, &ir)) < 0) {
> + pr_err("IP-Config: Unable to set interface flags (1,%d).\n",
> + err);
> + return -1;
> + }
> + strcpy(ir.ifr_newname, IPCONFIG_DEV_NEWNAME);
> + if ((err = ic_dev_ioctl(SIOCSIFNAME, &ir)) < 0) {
> + pr_err("IP-Config: Unable to change boot interface name to %s (%d).\n",
> + IPCONFIG_DEV_NEWNAME, err);
> + return -1;
> + }
> + strcpy(ir.ifr_ifrn.ifrn_name, IPCONFIG_DEV_NEWNAME);
> + if ((err = ic_dev_ioctl(SIOCGIFFLAGS, &ir)) < 0) {
> + pr_err("IP-Config: Unable to get interface flags (2,%d).\n",
> + err);
> + return -1;
> + }
> + ir.ifr_flags |= IFF_UP;
> + if ((err = ic_dev_ioctl(SIOCSIFFLAGS, &ir)) < 0) {
> + pr_err("IP-Config: Unable to set interface flags (2,%d).\n",
> + err);
> + return -1;
> + }
> +#endif
> set_sockaddr(sin, ic_myaddr, 0);
> if ((err = ic_devinet_ioctl(SIOCSIFADDR, &ir)) < 0) {
> pr_err("IP-Config: Unable to set interface address (%d)\n",
^ permalink raw reply
* Re: [PATCH rfc net] Allow the autoconfigured network interface to be renamed.
From: Jan Ceuleers @ 2012-06-10 17:20 UTC (permalink / raw)
To: Scott Parlane; +Cc: netdev, David Miller, Scott Parlane
In-Reply-To: <1339343619.27293.7.camel@c2d>
On 06/10/2012 05:53 PM, Scott Parlane wrote:
> Hi David,
>
> Can you please deliver this patch (my apologies if you have already).
Scott,
Be patient, you posted your patch yesterday.
Check patchwork for current status:
http://patchwork.ozlabs.org/patch/163892/
Jan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox