* Re: TCP sockets stalling - help! (long)
From: Frederic Leroy @ 2009-11-26 22:33 UTC (permalink / raw)
To: Asdo; +Cc: netdev, e1000-devel
In-Reply-To: <4B0CB1B8.8030402@shiftmail.org>
Le Wed, 25 Nov 2009 05:25:28 +0100,
Asdo <asdo@shiftmail.org> a écrit :
> Hi netdev and e1000 people,
>
> I have a weird problem here.
> [...]
I have the same kind of problem at home. I can't copy big files over
ssh unless I limit the rate ( ssh -l 8000 ... )
After reading your mail, I make some quick tests ( see below).
Results in short :
- netcat always work.
- ssh stalls, nearly immediately.
I thought fault cames from a kernel update or my wifi card update.
Apparently, I was wrong for the hardware.
Here are the test I just made :
network:
SG ----- eth_100_Mbps ----- ISV_BOX ))) wifi_~1.5Mb ((( HOUBA
host HOUBA:
----
gentoo - updated frequently (once a week)
kernel vanilla : Linux houba 2.6.32-rc6-fredo4-04866-g47caac1 #5
PREEMPT Fri Nov 6 14:20:20 CET 2009 i686 Intel(R) Pentium(R) M
processor 1400MHz GenuineIntel GNU/Linux
host SG:
----
debian stable - not updated recently
kernel vanilla : Linux sg 2.6.32-rc5-fredo3 #2 Mon Oct 19 02:25:29 CEST
2009 i586 GNU/Linux
/dev/sda is a USB disk mounted on media/big
TESTS
-----
HOUBA command for tests :
netcat -l -p 2000 | pv > /dev/null
TEST1 - OK : ~5min
fredo@sg:~/remote_wake$ cat /dev/null | netcat houba 2000
TEST2 - OK : ~5min
fredo@sg:~/remote_wake$ cat /dev/sda | netcat houba 2000
TEST3 - OK :
fredo@sg:~/remote_wake$
cat /media/big/home/fredo/cdanslair/cdanslair_20091125.wmv | netcat -q
0 houba 2000
result : 291MO 0:03:32 [1,37MO/s]
TEST4 - FAILED
fredo@sg:~/remote_wake$
scp /media/big/home/fredo/cdanslair/cdanslair_20091125.wmv houba:
Stalled within seconds (5216Kb transferred) :
cdanslair_20091125.wmv 1% 5216KB 0.0KB/s - stalled -
--
Frédéric Leroy
^ permalink raw reply
* Re: [Bug 14470] New: freez in TCP stack
From: David Miller @ 2009-11-26 23:37 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: eric.dumazet, akpm, shemminger, netdev, kolo, bugzilla-daemon
In-Reply-To: <alpine.DEB.2.00.0911262352050.24189@melkinpaasi.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 26 Nov 2009 23:54:53 +0200 (EET)
> How about this then... Does the original reporter have NFS in use?
>
> [PATCH] tcp: clear hints to avoid a stale one (nfs only affected?)
I must be getting old and senile, but I specifically remembered that
we prevented a socket from ever being bound again once it has been
bound one time specifically so we didn't have to deal with issues
like this.
I really don't think it's valid for NFS to reuse the socket structure
like this over and over again. And that's why only NFS can reproduce
this, the interfaces provided userland can't actually go through this
sequence after a socket goes down one time all the way to close.
Do we really want to audit each and every odd member of the socket
structure from the generic portion all the way down to INET and
TCP specifics to figure out what needs to get zero'd out?
So much relies upon the one-time full zero out during sock allocation.
Let's fix NFS instead.
^ permalink raw reply
* Re: [PATCH v4 0/7] via-velocity performance fixes
From: David Miller @ 2009-11-26 23:52 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, shemminger, romieu
In-Reply-To: <20091126090429.39cb37ac@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Thu, 26 Nov 2009 09:04:29 +0100
> Hi again!
>
> This is version four of the series posted here:
>
> http://marc.info/?l=linux-netdev&m=125873023117769&w=2
>
> The new version integrates Davids comments. There are 7 patches:
All applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCHv3 0/4] macvlan: add vepa and bridge mode
From: David Miller @ 2009-11-26 23:53 UTC (permalink / raw)
To: kaber
Cc: arnd, netdev, herbert, eric.dumazet, anna.fischer, bridge,
linux-kernel, virtualization, lk-netdev, gerhard.stenzel,
ebiederm, jens, pmullaney, shemminger
In-Reply-To: <4B0EAC29.60601@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 26 Nov 2009 17:26:17 +0100
> Arnd Bergmann wrote:
>> Version 2 description:
>> The patch to iproute2 has not changed, so I'm not including
>> it this time. Patch 4/4 (the netlink interface) is basically
>> unchanged as well but included for completeness.
>>
>> The other changes have moved forward a bit, to the point where
>> I find them a lot cleaner and am more confident in the code
>> being ready for inclusion. The implementation hardly resembles
>> Erics original patch now, so I've dropped his signed-off-by.
>>
>> Please take a look and ack if you are happy so we can get it
>> into 2.6.33.
>
> Looks good to me, nice work.
>
> Acked-by: Patrick McHardy <kaber@trash.net>
>
> for the entire series.
All applied to net-next-2.6, thanks everyone!
^ permalink raw reply
* Re: vlan: support "loose binding" to the underlying network device
From: David Miller @ 2009-11-27 0:01 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4B0D6F6E.4090901@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 25 Nov 2009 18:54:54 +0100
> vlan: support "loose binding" to the underlying network device
>
> Currently the UP/DOWN state of VLANs is synchronized to the state of the
> underlying device, meaning all VLANs are set down once the underlying
> device is set down. This causes all routes to the VLAN devices to vanish.
>
> Add a flag to specify a "loose binding" mode, in which only the operstate
> is transfered, but the VLAN device state is independant.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied, thanks Patrick.
^ permalink raw reply
* Re: [PATCH 01/16] sfc: Fix descriptor cache sizes
From: David Miller @ 2009-11-27 0:01 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1259201310.2806.5.camel@achroite.uk.solarflarecom.com>
All 16 patches look fine, applied to net-next-2.6, thanks Ben!
^ permalink raw reply
* Re: [Bug 14470] New: freez in TCP stack
From: Eric Dumazet @ 2009-11-27 6:17 UTC (permalink / raw)
To: David Miller
Cc: ilpo.jarvinen, akpm, shemminger, netdev, kolo, bugzilla-daemon,
Trond Myklebust
In-Reply-To: <20091126.153745.115170133.davem@davemloft.net>
David Miller a écrit :
> I must be getting old and senile, but I specifically remembered that
> we prevented a socket from ever being bound again once it has been
> bound one time specifically so we didn't have to deal with issues
> like this.
>
> I really don't think it's valid for NFS to reuse the socket structure
> like this over and over again. And that's why only NFS can reproduce
> this, the interfaces provided userland can't actually go through this
> sequence after a socket goes down one time all the way to close.
>
> Do we really want to audit each and every odd member of the socket
> structure from the generic portion all the way down to INET and
> TCP specifics to figure out what needs to get zero'd out?
An audit is always welcomed, we might find bugs :)
>
> So much relies upon the one-time full zero out during sock allocation.
>
> Let's fix NFS instead.
bugzilla reference : http://bugzilla.kernel.org/show_bug.cgi?id=14580
Trond said :
NFS MUST reuse the same port because on most servers, the replay cache is keyed
to the port number. In other words, when we replay an RPC call, the server will
only recognise it as a replay if it originates from the same port.
See http://www.connectathon.org/talks96/werme1.html
Please note the socket stays bound to a given local port.
We want to connect() it to a possible other target, that's all.
In NFS case 'other target' is in fact the same target, but this
is a special case of a more general one.
Hmm... if an application wants to keep a local port for itself (not
allowing another one to get this (ephemeral ?) port during the
close()/socket()/bind() window), this is the only way.
TCP state machine allows this IMHO.
google for "tcp AF_UNSPEC connect" to find many references and man pages
for this stuff.
http://kerneltrap.org/Linux/Connect_Specification_versus_Man_Page
How other Unixes / OS handle this ?
How many applications use this trick ?
^ permalink raw reply
* [PATCH] sch_htb: ix the deficit overflows
From: Changli Gao @ 2009-11-27 8:14 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller; +Cc: netdev, xiaosuo
fix the deficit overflows.
HTB uses WDRR(Weighted Deficit Round Robin) algorithm to schedule the spare bandwidth, but it doesn't check if the deficit is big enough for the skb when dequeuing skb from a class. In some case(the quantum is smaller than the packet size), the deficit will be decreased, even when it is smaller than ZERO. At last, the deficit will overflows, and become MAX_INT.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
sch_htb.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 2e38d1a..293983e 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -783,6 +783,7 @@ static struct sk_buff *htb_dequeue_tree(struct htb_sched *q, int prio,
{
struct sk_buff *skb = NULL;
struct htb_class *cl, *start;
+ unsigned int len;
/* look initial class up in the row */
start = cl = htb_lookup_leaf(q->row[level] + prio, prio,
q->ptr[level] + prio,
@@ -815,9 +816,23 @@ next:
goto next;
}
- skb = cl->un.leaf.q->dequeue(cl->un.leaf.q);
- if (likely(skb != NULL))
- break;
+ skb = cl->un.leaf.q->ops->peek(cl->un.leaf.q);
+ if (likely(skb != NULL)) {
+ len = qdisc_pkt_len(skb);
+ if (len <= cl->un.leaf.deficit[level]) {
+ skb = qdisc_dequeue_peeked(cl->un.leaf.q);
+ break;
+ }
+ skb = NULL;
+ cl->un.leaf.deficit[level] += cl->quantum;
+ htb_next_rb_node((level ? cl->parent->un.inner.ptr :
+ q->ptr[0]) + prio);
+ cl = htb_lookup_leaf(q->row[level] + prio, prio,
+ q->ptr[level] + prio,
+ q->last_ptr_id[level] + prio);
+ start = cl;
+ goto next;
+ }
qdisc_warn_nonwc("htb", cl->un.leaf.q);
htb_next_rb_node((level ? cl->parent->un.inner.ptr : q->
@@ -829,8 +844,8 @@ next:
} while (cl != start);
if (likely(skb != NULL)) {
- cl->un.leaf.deficit[level] -= qdisc_pkt_len(skb);
- if (cl->un.leaf.deficit[level] < 0) {
+ cl->un.leaf.deficit[level] -= len;
+ if (cl->un.leaf.deficit[level] <= 0) {
cl->un.leaf.deficit[level] += cl->quantum;
htb_next_rb_node((level ? cl->parent->un.inner.ptr : q->
ptr[0]) + prio);
^ permalink raw reply related
* Re: [tproxy,regression] tproxy broken in 2.6.32
From: KOVACS Krisztian @ 2009-11-27 8:26 UTC (permalink / raw)
To: Andreas Schultz; +Cc: tproxy, netdev, jamal
In-Reply-To: <db81a9a20911260919w1ffded25ref5ae24ee73f8eda@mail.gmail.com>
Hi,
On Thu, 2009-11-26 at 18:19 +0100, Andreas Schultz wrote:
> Hi,
>
> git bisect shows that TPROXY has been broken by commit
> f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0, [PATCH] net: Fix RPF to work
> with policy routing
>
> I had a look at the patch, and it seems logical that this would break TPROXY.
Indeed, that's a good catch. If this is indeed the problem you should be
able to work it around by disabling rpfilter on the ingress interface.
Does it work that way?
Cheers,
Krisztian
^ permalink raw reply
* Re: [RFC PATCH 08/10] be2net: remove use of skb_dma_map/unmap
From: Ajit Khaparde @ 2009-11-27 8:58 UTC (permalink / raw)
To: Alexander Duyck; +Cc: mcarlson, mchan, sathyap, subbus, davem, netdev
In-Reply-To: <20091125012054.32704.71183.stgit@gitlad.jf.intel.com>
On 24/11/09 17:20 -0800, Alexander Duyck wrote:
> Due to the fact that skb_dma_map/unmap do not work correctly when a HW
> IOMMU is enabled it has been recommended to go about removing the calls
> from the network device drivers.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
>
> drivers/net/benet/be_main.c | 37 ++++++++++++++++++++++++++-----------
> 1 files changed, 26 insertions(+), 11 deletions(-)
>
Thanks for the changes. They are good to go.
Acked-by: Ajit Khaparde <ajitk@serverengines.com>
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Ilpo Järvinen @ 2009-11-27 9:10 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Asdo, Netdev, e1000-devel
In-Reply-To: <20091126233302.42be8780@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 782 bytes --]
On Thu, 26 Nov 2009, Frederic Leroy wrote:
> Le Wed, 25 Nov 2009 05:25:28 +0100,
> Asdo <asdo@shiftmail.org> a écrit :
>
> > Hi netdev and e1000 people,
> >
> > I have a weird problem here.
> > [...]
>
> I have the same kind of problem at home. I can't copy big files over
> ssh unless I limit the rate ( ssh -l 8000 ... )
> After reading your mail, I make some quick tests ( see below).
>
> Results in short :
> - netcat always work.
> - ssh stalls, nearly immediately.
One important result is missing though... could you perhaps get a tcpdump
from the stall and get also the info available in /proc/net/tcp for the
connection (during the stall), that would help some in figuring out what
is going on... ...Preferably in new/renamed thread, don't forget to cc me.
--
i.
^ permalink raw reply
* [PROPOSAL]: Support Alternate Network Device Naming Schemes
From: Narendra K @ 2009-11-27 9:11 UTC (permalink / raw)
To: anaconda-devel-list
Cc: netdev, matt_domsch, charles_rose, sandeep_k_shandilya,
jordan_hargrave, shyam_iyer
We have been having discussions in the netdev list about creating multiple names for the network interfaces to bring determinism into the way network interfaces are named in the OSes. In specific, "eth0 in the OS does not always map to the integrated NIC Gb1 as labelled on the chassis".
http://marc.info/?l=linux-netdev&m=125510301513312&w=2 - (Re: PATCH: Network Device Naming mechanism and policy)
http://marc.info/?l=linux-netdev&m=125619338904322&w=2 - ([PATCH] udev: create empty regular files to represent net)
As a result of those discussions, we propose an installer based solution.
Installers as of now allow the discovered network interfaces to be configured. This solution proposes to provide an option for the users to either retain the default naming convention that the kernel now has, i.e ethN names or rename the network interfaces based on the chassis label, MAC addresses, Driver name and any other naming convention. Here is how the modified network configuration wizard would look during the os installation process -
---------- Network Configuration ------------------------
Default [ ] | SMBIOS Names [x] | Driver Names [] | MAC Names []
-----------------------------------------------------------------------
eth0 | Addin_NIC_1 | ice0 |
-----------------------------------------------------------------------
eth1 | Embedded_NIC_1 | bce0 |
-----------------------------------------------------------------------
eth2 | Embedded_NIC_2 | bce1 |
-----------------------------------------------------------------------
eth3 | Embedded_NIC_3 | bce2 |
-----------------------------------------------------------------------
eth4 | Embedded_NIC_4 | bce3 |
-----------------------------------------------------------------------
------------
| Next |
------------
[ ice0 - Intel Controller 0, bce0 - Broadcom Controller 0 ]
1. In addition to the default ethN names the user can check against the available naming conventions and the wizard would show the names the interfaces will be renamed to.
2. The moment the user hits the Next button all interfaces are renamed as per the Naming convention they have selected.
3. Any further network communication would be using the new names.
4. Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.
This way the OS names of network interfaces would have a co-relation to the chassis names. Irrespective of what the OS names the integrated port one, i.e eth0 or eth1, Embedded_NIC_1 will always refer to the integrated port 1, bringing in determinism.
Additional Reference:
http://marc.info/?l=linux-hotplug&m=125692284431543&w=2
http://marc.info/?l=linux-netdev&m=125683519310462&w=2
http://marc.info/?l=linux-netdev&m=125754944814387&w=2
http://marc.info/?l=linux-hotplug&m=125536996902867&w=2
With regards,
Narendra K
^ permalink raw reply
* Re: [tproxy,regression] tproxy broken in 2.6.32
From: Andreas Schultz @ 2009-11-27 9:11 UTC (permalink / raw)
To: KOVACS Krisztian; +Cc: tproxy, netdev, jamal
In-Reply-To: <1259310417.3809.5.camel@nienna.balabit>
Hi,
On Fri, Nov 27, 2009 at 9:26 AM, KOVACS Krisztian <hidden@balabit.hu> wrote:
> Hi,
>
> On Thu, 2009-11-26 at 18:19 +0100, Andreas Schultz wrote:
>> Hi,
>>
>> git bisect shows that TPROXY has been broken by commit
>> f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0, [PATCH] net: Fix RPF to work
>> with policy routing
>>
>> I had a look at the patch, and it seems logical that this would break TPROXY.
>
> Indeed, that's a good catch. If this is indeed the problem you should be
> able to work it around by disabling rpfilter on the ingress interface.
> Does it work that way?
That was my first guess also. I disabled rp_filter on all interfaces
and it had no impact. So far, only reverting that patch has solved the
problem.
Andreas
^ permalink raw reply
* [PROPOSAL]: Support Alternate Network Device Naming Schemes
From: Narendra K @ 2009-11-27 9:42 UTC (permalink / raw)
To: anaconda-devel-list
Cc: netdev, matt_domsch, charles_rose, sandeep_k_shandilya,
jordan_hargrave, shyam_iyer
We have been having discussions in the netdev list about creating multiple names for the network interfaces to bring determinism into the way network interfaces are named in the OSes. In specific, "eth0 in the OS does not always map to the integrated NIC Gb1 as labelled on the chassis".
http://marc.info/?l=linux-netdev&m=125510301513312&w=2 - (Re: PATCH: Network Device Naming mechanism and policy)
http://marc.info/?l=linux-netdev&m=125619338904322&w=2 - ([PATCH] udev: create empty regular files to represent net)
As a result of those discussions, we propose an installer based solution.
Installers as of now allow the discovered network interfaces to be configured. This solution proposes to provide an option for the users to either retain the default naming convention that the kernel now has, i.e ethN names or rename the network interfaces based on the chassis label, MAC addresses, Driver name and any other naming convention. Here is how the modified network configuration wizard would look during the os installation process -
---------- Network Configuration ------------------------
Default [ ] | SMBIOS Names [x] | Driver Names [] | MAC Names []
-----------------------------------------------------------------------
eth0 | Addin_NIC_1 | ice0 |
-----------------------------------------------------------------------
eth1 | Embedded_NIC_1 | bce0 |
-----------------------------------------------------------------------
eth2 | Embedded_NIC_2 | bce1 |
-----------------------------------------------------------------------
eth3 | Embedded_NIC_3 | bce2 |
-----------------------------------------------------------------------
eth4 | Embedded_NIC_4 | bce3 |
-----------------------------------------------------------------------
------------
| Next |
------------
[ ice0 - Intel Controller 0, bce0 - Broadcom Controller 0 ]
1. In addition to the default ethN names the user can check against the available naming conventions and the wizard would show the names the interfaces will be renamed to.
2. The moment the user hits the Next button all interfaces are renamed as per the Naming convention they have selected.
3. Any further network communication would be using the new names.
4. Ifconfig would show names like "Embedded_NIC_1" and not eth0 etc.
This way the OS names of network interfaces would have a co-relation to the chassis names. Irrespective of what the OS names the integrated port one, i.e eth0 or eth1, Embedded_NIC_1 will always refer to the integrated port 1, bringing in determinism.
Additional Reference:
http://marc.info/?l=linux-hotplug&m=125692284431543&w=2
http://marc.info/?l=linux-netdev&m=125683519310462&w=2
http://marc.info/?l=linux-netdev&m=125754944814387&w=2
http://marc.info/?l=linux-hotplug&m=125536996902867&w=2
With regards,
Narendra K
^ permalink raw reply
* [PATCH, resend] iproute2/iplink: add macvlan options for bridge mode
From: Arnd Bergmann @ 2009-11-27 10:57 UTC (permalink / raw)
To: linux-kernel
Cc: virtualization, Herbert Xu, Arnd Bergmann, Anna Fischer, netdev,
bridge, David Miller, Gerhard Stenzel, Eric W. Biederman,
Jens Osterkamp, Patrick Mullaney, Stephen Hemminger,
Edge Virtual Bridging
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
Resending, the kernel patches have gone into net-next,
so a version of this should go into iproute2.
---
Macvlan can now optionally support forwarding between its
ports, if they are in "bridge" mode. This adds support
for this option to "ip link add", "ip link set" and "ip
-d link show".
The default mode in the kernel is now "vepa" mode, meaning
"virtual ethernet port aggregator". This mode is used
together with the "hairpin" mode of an ethernet bridge
that the parent of the macvlan device is connected to.
All frames still get sent out to the external interface,
but the adjacent bridge is able to send them back on
the same wire in hairpin mode, so the macvlan ports
are able to see each other, which the bridge can be
configured to monitor and control traffic between
all macvlan instances. Multicast traffic coming in
from the external interface is checked for the source
MAC address and only delivered to ports that have not
yet seen it.
In bridge mode, macvlan will send all multicast traffic
to other interfaces that are also in bridge mode but
not to those in vepa mode, which get them on the way
back from the hairpin.
The third supported mode is "private", which prevents
communication between macvlans even if the adjacent
bridge is in hairpin mode. This behavior is closer to
the original implementation of macvlan but stricly
maintains isolation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/if_link.h | 15 ++++++++
ip/Makefile | 3 +-
ip/iplink_macvlan.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 ip/iplink_macvlan.c
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index b0b9e8a..425c489 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -188,4 +188,19 @@ struct ifla_vlan_qos_mapping
__u32 to;
};
+/* MACVLAN section */
+enum {
+ IFLA_MACVLAN_UNSPEC,
+ IFLA_MACVLAN_MODE,
+ __IFLA_MACVLAN_MAX,
+};
+
+enum ifla_macvlan_mode {
+ MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
+ MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
+ MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
+};
+
+#define IFLA_MACVLAN_MAX (__IFLA_MACVLAN_MAX - 1)
+
#endif /* _LINUX_IF_LINK_H */
diff --git a/ip/Makefile b/ip/Makefile
index 51914e8..46a9836 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -2,7 +2,8 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o \
rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \
ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o \
ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
- iplink_vlan.o link_veth.o link_gre.o iplink_can.o
+ iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
+ iplink_macvlan.o
RTMONOBJ=rtmon.o
diff --git a/ip/iplink_macvlan.c b/ip/iplink_macvlan.c
new file mode 100644
index 0000000..307f559
--- /dev/null
+++ b/ip/iplink_macvlan.c
@@ -0,0 +1,93 @@
+/*
+ * iplink_vlan.c VLAN device support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Patrick McHardy <kaber@trash.net>
+ * Arnd Bergmann <arnd@arndb.de>
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/socket.h>
+#include <linux/if_link.h>
+
+#include "rt_names.h"
+#include "utils.h"
+#include "ip_common.h"
+
+static void explain(void)
+{
+ fprintf(stderr,
+ "Usage: ... macvlan mode { private | vepa | bridge }\n"
+ );
+}
+
+static int mode_arg(void)
+{
+ fprintf(stderr, "Error: argument of \"mode\" must be \"private\", "
+ "\"vepa\" or \"bridge\"\n");
+ return -1;
+}
+
+static int macvlan_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *n)
+{
+ while (argc > 0) {
+ if (matches(*argv, "mode") == 0) {
+ __u32 mode = 0;
+ NEXT_ARG();
+
+ if (strcmp(*argv, "private") == 0)
+ mode = MACVLAN_MODE_PRIVATE;
+ else if (strcmp(*argv, "vepa") == 0)
+ mode = MACVLAN_MODE_VEPA;
+ else if (strcmp(*argv, "bridge") == 0)
+ mode = MACVLAN_MODE_BRIDGE;
+ else
+ return mode_arg();
+
+ addattr32(n, 1024, IFLA_MACVLAN_MODE, mode);
+ } else if (matches(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr, "macvlan: what is \"%s\"?\n", *argv);
+ explain();
+ return -1;
+ }
+ argc--, argv++;
+ }
+
+ return 0;
+}
+
+static void macvlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
+{
+ __u32 mode;
+
+ if (!tb)
+ return;
+
+ if (!tb[IFLA_MACVLAN_MODE] ||
+ RTA_PAYLOAD(tb[IFLA_MACVLAN_MODE]) < sizeof(__u32))
+ return;
+
+ mode = *(__u32 *)RTA_DATA(tb[IFLA_VLAN_ID]);
+ fprintf(f, " mode %s ",
+ mode == MACVLAN_MODE_PRIVATE ? "private"
+ : mode == MACVLAN_MODE_VEPA ? "vepa"
+ : mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : "unknown");
+}
+
+struct link_util macvlan_link_util = {
+ .id = "macvlan",
+ .maxattr = IFLA_MACVLAN_MAX,
+ .parse_opt = macvlan_parse_opt,
+ .print_opt = macvlan_print_opt,
+};
--
1.6.3.3
^ permalink raw reply related
* Re: Problem with tcp (2.6.31) as first, http://bugzilla.kernel.org/show_bug.cgi?id=14580
From: Eric Dumazet @ 2009-11-27 11:48 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Krzysztof Oledzki, David Miller, Herbert Xu, Linux Netdev List
In-Reply-To: <alpine.DEB.2.00.0911271246030.2459@melkinpaasi.cs.helsinki.fi>
Ilpo Järvinen a écrit :
> What would you expect to happen? If out-of-window stuff arrives we send
> dupacks. If we would send resets, that would introduce blind rst attacks.
> In theory we might be able to quench the loop by using pingpong thing but
> that needs very careful thought in order to not introduce other problems,
> and even then your connections will not be re-usable until either end
> times out so the gain is rather limited. We simply cannot rst the
> connection, that's not an option.
>
> I find this problem simply stem from the introduced loss of end-to-end
> connectivity. Would you really "lose" that server so that its TCP state is
> not maintained, you'd get resets etc (crash, scheduled reboot or
> whatever). Only real solution would be a kill switch for TCP connection
> when you break e-2-e connectivity (ie., switch servers so that the same IP
> is reacquired by somebody else). In theory you can "simulate" the kill
> switch by setting tcp_retries sysctls to small values to make the
> connections to timeout much faster, but still that might not be enough for
> you (and has other implications you might not like).
>
RST is not an option, sure, but ACK storms are unlikely good things too.
Could'nt we do something smart in presence of tcp timestamps ?
11:23:27.669910 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.669991 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670000 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670093 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670099 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670175 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670183 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670268 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670276 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
11:23:27.670359 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583>
11:23:27.670368 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404>
Or we could
Count number N of strange/bad acks we received from peer.
- At first one, send our ACK immediately
- For following, delay our ACK answer by N*100 ms, to reduce the flood.
(or if we have data in flight, only rely on retransmit timer and not sending acks)
^ permalink raw reply
* Re: Problem with tcp (2.6.31) as first, http://bugzilla.kernel.org/show_bug.cgi?id=14580
From: Krzysztof Olędzki @ 2009-11-27 11:43 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Eric Dumazet, David Miller, Herbert Xu, netdev
In-Reply-To: <alpine.DEB.2.00.0911271246030.2459@melkinpaasi.cs.helsinki.fi>
On 2009-11-27 12:04, Ilpo Järvinen wrote:
> On Fri, 27 Nov 2009, Krzysztof Oledzki wrote:
>
>>
>> On Thu, 26 Nov 2009, Eric Dumazet wrote:
>>
>>> Ilpo Järvinen a écrit :
>>>> On Thu, 26 Nov 2009, Eric Dumazet wrote:
>>>>
>>>>> Eric Dumazet a écrit :
>>>>>> Krzysztof Olędzki a écrit :
>>>>>>> On 2009-11-26 21:47, Eric Dumazet wrote:
>>>>>>>
>>>>>>>> About wscale being not sent, I suppose last kernel is fixed
>>>>>>> Thanks, I'll check it. But it is quite strange, that while reusing
>>>>>>> the
>>>>>>> old connection, Linux uses wscale==0.
>>>>>>>
>>>>>> It only 'reuse' sequence of previous connection to compute its ISN.
>>>>>>
>>>>>> Its a new socket, a new connection, with possibly different RCVBUF
>>>>>> settings -> different window.
>>>>>>
>>>>>> In my tests on net-next-2.6, I always have wscale set, but I am using
>>>>>> a program of my own,
>>>>>> not full NFS setup.
>>>>>>
>>>>>>
>>>>> Well, it seems NFS reuses its socket, so maybe we miss some cleaning
>>>>> as spotted in this old patch :
>>>> ...Nice, so we have this reuse of socket after all. ...It seems that our
>>>> other bugs might have just been solved (wq purge can then cause stale
>>>> hints if this reusing is indeed true).
>>>>
>>> Indeed, and we can do this in user space too :)
>>>
>>>
>>> sockaddr.sin_family = AF_INET;
>>> sockaddr.sin_port = htons(PORT);
>>> sockaddr.sin_addr.s_addr = inet_addr("192.168.20.112");
>>> res = connect(fd, (struct sockaddr *)&sockaddr, sizeof(sockaddr));
>>> ...
>>>
>>> /*
>>> * following code calls tcp_disconnect()
>>> */
>>> memset(&sockaddr, 0, sizeof(sockaddr));
>>> sockaddr.sin_family = AF_UNSPEC;
>>> connect(fd, (struct sockaddr *)&sockaddr, sizeof(sockaddr));
>>>
>>> /* reuse socket and reconnect on same target */
>>> sockaddr.sin_family = AF_INET;
>>> sockaddr.sin_port = htons(PORT);
>>> sockaddr.sin_addr.s_addr = inet_addr("192.168.20.112");
>>> res = connect(fd, (struct sockaddr *)&sockaddr, sizeof(sockaddr));
>>>
>>>
>>> I reproduced the problem (of too small window, wscale = 0 instead of 6)
>>>
>>>
>>>
>>> 23:14:53.608106 IP client.3434 > 192.168.20.112.333: S
>>> 392872616:392872616(0) win 5840 <mss 1460,nop,nop,timestamp 82516578
>>> 0,nop,wscale 6>
>>> 23:14:53.608199 IP 192.168.20.112.333 > client.3434: S
>>> 2753948468:2753948468(0) ack 392872617 win 5792 <mss 1460,nop,nop,timestamp
>>> 1660900486 82516578,nop,wscale 6>
>>> 23:14:53.608218 IP client.3434 > 192.168.20.112.333: . ack 1 win 92
>>> <nop,nop,timestamp 82516578 1660900486>
>>> 23:14:53.608232 IP client.3434 > 192.168.20.112.333: P 1:7(6) ack 1 win 92
>>> <nop,nop,timestamp 82516578 1660900486>
>>> 23:14:53.608320 IP 192.168.20.112.333 > client.3434: . ack 7 win 91
>>> <nop,nop,timestamp 1660900486 82516578>
>>> 23:14:53.608328 IP 192.168.20.112.333 > client.3434: P 1:7(6) ack 7 win 91
>>> <nop,nop,timestamp 1660900486 82516578>
>>> 23:14:53.608331 IP 192.168.20.112.333 > client.3434: F 7:7(0) ack 7 win 91
>>> <nop,nop,timestamp 1660900486 82516578>
>>> 23:14:53.608341 IP client.3434 > 192.168.20.112.333: . ack 7 win 92
>>> <nop,nop,timestamp 82516578 1660900486>
>>> 23:14:53.647202 IP client.3434 > 192.168.20.112.333: . ack 8 win 92
>>> <nop,nop,timestamp 82516618 1660900486>
>>> 23:14:56.614341 IP client.3434 > 192.168.20.112.333: F 7:7(0) ack 8 win 92
>>> <nop,nop,timestamp 82519584 1660900486>
>>> 23:14:56.614439 IP 192.168.20.112.333 > client.3434: . ack 8 win 91
>>> <nop,nop,timestamp 1660903493 82519584>
>>> 23:14:56.614461 IP client.3434 > 192.168.20.112.333: R
>>> 392872624:392872624(0) win 0
>>>
>>> <<HERE : win = 5840 wscale = 0>>
>>> 23:14:56.616260 IP client.3434 > 192.168.20.112.333: S
>>> 392878450:392878450(0) win 5840 <mss 1460,nop,nop,timestamp 82519586
>>> 0,nop,wscale 0>
>>>
>>> 23:14:56.616352 IP 192.168.20.112.333 > client.3434: S
>>> 2800950724:2800950724(0) ack 392878451 win 5792 <mss 1460,nop,nop,timestamp
>>> 1660903494 82519586,nop,wscale 6>
>>>
>>>
>>>
>>> Following patch solves this problem, but maybe we need a flag
>>> (a la sk->sk_userlocks |= SOCK_WINCLAMP_LOCK;)
>>> in case user set window_clamp.
>>> Or just document the clearing after a tcp disconnect ?
>>>
>>> [PATCH] tcp: tcp_disconnect() should clear window_clamp
>>>
>>> Or reuse of socket possibly selects a small window, wscale = 0 for next
>>> connection.
>>>
>>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>>> index 524f976..7d4648f 100644
>>> --- a/net/ipv4/tcp.c
>>> +++ b/net/ipv4/tcp.c
>>> @@ -2059,6 +2059,7 @@ int tcp_disconnect(struct sock *sk, int flags)
>>> tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
>>> tp->snd_cwnd_cnt = 0;
>>> tp->bytes_acked = 0;
>>> + tp->window_clamp = 0;
>>> tcp_set_ca_state(sk, TCP_CA_Open);
>>> tcp_clear_retrans(tp);
>>> inet_csk_delack_init(sk);
>>>
>> Thanks!
>>
>> 10:07:31.429627 IP 192.168.152.205.44678 > 192.168.152.20.2049: Flags [S], seq
>> 2012792102, win 5840, options [mss 1460,sackOK,TS val 4294877898 ecr
>> 0,nop,wscale 7], length 0
>> 10:07:31.429736 IP 192.168.152.20.2049 > 192.168.152.205.44678: Flags [S.],
>> seq 1548680033, ack 2012792103, win 5792, options [mss 1460,sackOK,TS val
>> 68439846 ecr 4294877898,nop,wscale 7], length 0
>> (switching servers)
>> 10:08:05.186989 IP 192.168.152.20.2049 > 192.168.152.205.44678: Flags [R], seq
>> 1548680550, win 0, length 0
>> 10:08:11.187117 IP 192.168.152.205.44678 > 192.168.152.20.2049: Flags [S], seq
>> 2012804321, win 5840, options [mss 1460,sackOK,TS val 4294917656 ecr
>> 0,nop,wscale 7], length 0
>> 10:08:11.187276 IP 192.168.152.20.2049 > 192.168.152.205.44678: Flags [S.],
>> seq 2176044714, ack 2012804322, win 5792, options [mss 1460,sackOK,TS val
>> 68482560 ecr 4294917656,nop,wscale 7], length 0
>>
>> This indeed fixes the problem with missing/zero wscale, however the original
>> problem (tcp loop flood) still remains. I wonder why the client is not able to
>> handle it, especially that seq numbers received from both servers are
>> distanced by much, much more than the current window size: 627364681 is much
>> larger than 5840 << 7 (747520).
>
> What would you expect to happen? If out-of-window stuff arrives we send
> dupacks. If we would send resets, that would introduce blind rst attacks.
> In theory we might be able to quench the loop by using pingpong thing but
> that needs very careful thought in order to not introduce other problems,
> and even then your connections will not be re-usable until either end
> times out so the gain is rather limited. We simply cannot rst the
> connection, that's not an option.
Right, the idea of sending RST is indeed stupid. But at risk of being
silly, why do we need to send anything in response to out-of-window
packets? Especially as we are doing it without ratelimiting, even for a
packet that contains no data, only pure ack. The current situation can
be easily abused for a hard to trace DoS - just send a lot of spoofed
packed to a port from established connection and such server will
response at the same rate, flooding the client.
> I find this problem simply stem from the introduced loss of end-to-end
> connectivity. Would you really "lose" that server so that its TCP state is
> not maintained, you'd get resets etc (crash, scheduled reboot or
> whatever).
In brain-split situation, when your network is temporary segmented, two
redundant servers may take the same VIP simultaneously. When such
networks restores full functionality, one of the servers loses the IP.
It is how I have found this problem.
> Only real solution would be a kill switch for TCP connection
> when you break e-2-e connectivity (ie., switch servers so that the same IP
> is reacquired by somebody else). In theory you can "simulate" the kill
> switch by setting tcp_retries sysctls to small values to make the
> connections to timeout much faster, but still that might not be enough for
> you (and has other implications you might not like).
Now I wonder - maybe we can simply kill ESTABLISHED connections
containing a addresses being removed?
>> But there is one more thing that still bugs me, please look at one of my
>> previous dump:
>>
>> 17:39:48.339503 IP (tos 0x0, ttl 64, id 31305, offset 0, flags [DF], proto TCP
>> (6), length 56)
>> 192.168.152.205.55329 > 192.168.152.20.2049: Flags [S], cksum 0x7d35
>> (correct), seq 3093379972, win 5840, options [mss 1460,sackOK,TS val 16845 ecr
>> 0], length 0
>>
>> 17:39:48.339588 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP
>> (6), length 56)
>> 192.168.152.20.2049 > 192.168.152.205.55329: Flags [S.], cksum 0x7930
>> (correct), seq 4250661905, ack 3093379973, win 5792, options [mss
>> 1460,sackOK,TS val 9179690 ecr 16845], length 0
>>
>> OK, now we know that the client is buggy and sends small windows, but why the
>> response from the server also contains so small window?
>
> Perhaps I don't fully understand what you find here to be a problem...
> Anyway, initially we start with small window and enlarge it while we keep
> going (receiver window auto-tuning).
Yes, Eric already explained it to me. I was just debating why we had
started with such small window here. Normally, with wscale enabled the
window is much higher, so without wscale it should be higher too, of
course with respect to the 16bit limit. But as windows can grow later,
it is not a problem.
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-27 12:56 UTC (permalink / raw)
To: Frederic Leroy; +Cc: e1000-devel, netdev, Ilpo Järvinen
In-Reply-To: <20091126233302.42be8780@houba>
[-- Attachment #1.1: Type: text/plain, Size: 1423 bytes --]
Frederic Leroy wrote:
> Le Wed, 25 Nov 2009 05:25:28 +0100,
> Asdo <asdo@shiftmail.org> a écrit :
>
>
>> Hi netdev and e1000 people,
>>
>> I have a weird problem here.
>> [...]
>>
>
> I have the same kind of problem at home. I can't copy big files over
> ssh unless I limit the rate ( ssh -l 8000 ... )
> After reading your mail, I make some quick tests ( see below).
>
> Results in short :
> - netcat always work.
> - ssh stalls, nearly immediately.
>
Good God it's true then!
I think I have an idea for why Netcat works while scp doesn't:
probably SCP pushing data requires replies from the application layer
(the 60 bytes I was telling about for SFTP) while netcat doesnt, it just
needs the Acks to keep pushing data.
Still if I am right, with Netcat you might end up with a corrupted file
on the other side (shorter). Or maybe not, depending on how exactly the
bug is made. Could you check this? Filesize and md5sum.
I think I just reproduced the bug on another machine, different hardware
(Supermicro mainboard), same Ubuntu, same kernel, same integrated Intel
network card. It just takes 5 hours or so for me to trigger.
Do you have Intel network card, with e1000e driver on SG? (see lsmod)
(sorry I was wrong before, it's e1000e in my case not e1000) Otherwise
it's probably the TCP layer...
Would you paste here your lspci and lsmod?
Thank you
[-- Attachment #2: Type: text/plain, Size: 354 bytes --]
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
* Re: [PATCH 1/3] netdevice: provide common routine for macvlan and vlan operstate management
From: Arnd Bergmann @ 2009-11-27 13:09 UTC (permalink / raw)
To: Patrick Mullaney; +Cc: kaber, netdev, alacrityvm-devel, linux-kernel, bridge
In-Reply-To: <20091113195513.11184.63631.stgit@mimic.site>
On Friday 13 November 2009, Patrick Mullaney wrote:
> @@ -551,7 +532,7 @@ static int macvlan_newlink(struct net_device *dev,
> return err;
>
> list_add_tail(&vlan->list, &port->vlans);
> - macvlan_transfer_operstate(dev);
> + netif_stacked_transfer_operstate(dev, lowerdev);
> return 0;
> }
>
> @@ -591,7 +572,8 @@ static int macvlan_device_event(struct notifier_block *unused,
> switch (event) {
> case NETDEV_CHANGE:
> list_for_each_entry(vlan, &port->vlans, list)
> - macvlan_transfer_operstate(vlan->dev);
> + netif_stacked_transfer_operstate(vlan->dev,
> + vlan->lowerdev);
> break;
> case NETDEV_FEAT_CHANGE:
> list_for_each_entry(vlan, &port->vlans, list) {
These have the arguments reversed, lowerdev should come first.
Arnd <><
^ permalink raw reply
* ucc_geth doesn't work properly with vlans enabled.
From: Lennart Sorensen @ 2009-11-27 15:08 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: LKML, netdev, Len Sorensen
We just started using vlans on our powerpc platform, and we noticed that
we were getting dropped packets when using the vlan interfaces.
After a bit of debuging it turned out that dropping the MUT on the
client machine to 1496 made the problem go away, which was of course
also very suspicious.
So looking through the driver I found the max packet length is set to 1518
which of course is the right size for a 1500byte packet as long as it is
not vlan tagged. The UCC happens to have support for recognizing vlan
tagged packets and dynamically increasing the allowed size in the vlan
tagged case by 4 bytes which is great if it works. Well it turns out,
that feature works, but isn't actually enabled in the driver. The code
to handle activating it is there, but there is no code anywhere to ever
set that parameter.
Specifically:
if (ug_info->dynamicMaxFrameLength)
remoder |= REMODER_DYNAMIC_MAX_FRAME_LENGTH;
This code works fine, but ug_info->dynamicMaxFrameLength is never touched
anywhere other than being memset to 0 initially as part of the struct.
So a simple hack of:
if (ug_info->dynamicMaxFrameLength || 1)
remoder |= REMODER_DYNAMIC_MAX_FRAME_LENGTH;
makes it work perfectly with vlans, but is obviously not the right way
to solve this.
What would be the right way to solve this? What was the intent here I
wonder when it was written? Certainly the current behaviour means vlans
can't be used on this driver.
--
Len Sorensen
^ permalink raw reply
* Re: [tproxy,regression] tproxy broken in 2.6.32
From: jamal @ 2009-11-27 16:05 UTC (permalink / raw)
To: KOVACS Krisztian; +Cc: Andreas Schultz, tproxy, netdev
In-Reply-To: <1259310417.3809.5.camel@nienna.balabit>
On Fri, 2009-11-27 at 09:26 +0100, KOVACS Krisztian wrote:
> Hi,
>
> On Thu, 2009-11-26 at 18:19 +0100, Andreas Schultz wrote:
> > Hi,
> >
> > git bisect shows that TPROXY has been broken by commit
> > f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0, [PATCH] net: Fix RPF to work
> > with policy routing
> >
> > I had a look at the patch, and it seems logical that this would break TPROXY.
>
> Indeed, that's a good catch. If this is indeed the problem you should be
> able to work it around by disabling rpfilter on the ingress interface.
> Does it work that way?
Not familiar with tproxy, but I suspect the system doesnt see the mark
before policy routing happens. So probably the wrong route cache gets
created. Easy to validate by dumping the route cache.
If thats so, you have to set the mark in pre-route hook if it uses
iptables.
cheers,
jamal
^ permalink raw reply
* [PATCH] bnx2: avoid flushing statistics when doing a MTU change
From: leitao @ 2009-11-27 16:59 UTC (permalink / raw)
To: netdev; +Cc: mchan
Actually when bnx2 changes the interface's MTU size, it resets
the chip and consequently flushes the interface statistics.
This patch saves the statistics in a temporary space in order to
maintain the statistics correct after the chip reset.
Signed-off-by: Breno Leitao<leitao@linux.vnet.ibm.com>
---
drivers/net/bnx2.c | 52 +++++++++++++++++++++++++++++++++++++---------------
drivers/net/bnx2.h | 1 +
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 7fa4048..f99e688 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6469,46 +6469,58 @@ bnx2_get_stats(struct net_device *dev)
net_stats->rx_packets =
GET_NET_STATS(stats_blk->stat_IfHCInUcastPkts) +
GET_NET_STATS(stats_blk->stat_IfHCInMulticastPkts) +
- GET_NET_STATS(stats_blk->stat_IfHCInBroadcastPkts);
+ GET_NET_STATS(stats_blk->stat_IfHCInBroadcastPkts) +
+ bp->stats_extra->rx_packets;
net_stats->tx_packets =
GET_NET_STATS(stats_blk->stat_IfHCOutUcastPkts) +
GET_NET_STATS(stats_blk->stat_IfHCOutMulticastPkts) +
- GET_NET_STATS(stats_blk->stat_IfHCOutBroadcastPkts);
+ GET_NET_STATS(stats_blk->stat_IfHCOutBroadcastPkts) +
+ bp->stats_extra->tx_packets;
net_stats->rx_bytes =
- GET_NET_STATS(stats_blk->stat_IfHCInOctets);
+ GET_NET_STATS(stats_blk->stat_IfHCInOctets) +
+ bp->stats_extra->rx_bytes;
net_stats->tx_bytes =
- GET_NET_STATS(stats_blk->stat_IfHCOutOctets);
+ GET_NET_STATS(stats_blk->stat_IfHCOutOctets) +
+ bp->stats_extra->tx_bytes;
net_stats->multicast =
- GET_NET_STATS(stats_blk->stat_IfHCOutMulticastPkts);
+ GET_NET_STATS(stats_blk->stat_IfHCOutMulticastPkts) +
+ bp->stats_extra->multicast;
net_stats->collisions =
- (unsigned long) stats_blk->stat_EtherStatsCollisions;
+ (unsigned long) stats_blk->stat_EtherStatsCollisions +
+ bp->stats_extra->collisions;
net_stats->rx_length_errors =
(unsigned long) (stats_blk->stat_EtherStatsUndersizePkts +
- stats_blk->stat_EtherStatsOverrsizePkts);
+ stats_blk->stat_EtherStatsOverrsizePkts) +
+ bp->stats_extra->rx_length_errors;
net_stats->rx_over_errors =
(unsigned long) (stats_blk->stat_IfInFTQDiscards +
- stats_blk->stat_IfInMBUFDiscards);
+ stats_blk->stat_IfInMBUFDiscards) +
+ bp->stats_extra->rx_over_errors;
net_stats->rx_frame_errors =
- (unsigned long) stats_blk->stat_Dot3StatsAlignmentErrors;
+ (unsigned long) stats_blk->stat_Dot3StatsAlignmentErrors +
+ bp->stats_extra->rx_frame_errors;
net_stats->rx_crc_errors =
- (unsigned long) stats_blk->stat_Dot3StatsFCSErrors;
+ (unsigned long) stats_blk->stat_Dot3StatsFCSErrors +
+ bp->stats_extra->rx_crc_errors;
net_stats->rx_errors = net_stats->rx_length_errors +
net_stats->rx_over_errors + net_stats->rx_frame_errors +
- net_stats->rx_crc_errors;
+ net_stats->rx_crc_errors +
+ bp->stats_extra->rx_errors;
net_stats->tx_aborted_errors =
(unsigned long) (stats_blk->stat_Dot3StatsExcessiveCollisions +
- stats_blk->stat_Dot3StatsLateCollisions);
+ stats_blk->stat_Dot3StatsLateCollisions) +
+ bp->stats_extra->tx_aborted_errors;
if ((CHIP_NUM(bp) == CHIP_NUM_5706) ||
(CHIP_ID(bp) == CHIP_ID_5708_A0))
@@ -6516,7 +6528,8 @@ bnx2_get_stats(struct net_device *dev)
else {
net_stats->tx_carrier_errors =
(unsigned long)
- stats_blk->stat_Dot3StatsCarrierSenseErrors;
+ stats_blk->stat_Dot3StatsCarrierSenseErrors +
+ bp->stats_extra->tx_carrier_errors;
}
net_stats->tx_errors =
@@ -6524,11 +6537,13 @@ bnx2_get_stats(struct net_device *dev)
stats_blk->stat_emac_tx_stat_dot3statsinternalmactransmiterrors
+
net_stats->tx_aborted_errors +
- net_stats->tx_carrier_errors;
+ net_stats->tx_carrier_errors +
+ bp->stats_extra->tx_errors;
net_stats->rx_missed_errors =
(unsigned long) (stats_blk->stat_IfInFTQDiscards +
- stats_blk->stat_IfInMBUFDiscards + stats_blk->stat_FwRxDrop);
+ stats_blk->stat_IfInMBUFDiscards + stats_blk->stat_FwRxDrop) +
+ bp->stats_extra->rx_missed_errors;
return net_stats;
}
@@ -6989,6 +7004,11 @@ bnx2_change_ring_size(struct bnx2 *bp, u32 rx, u32 tx)
{
if (netif_running(bp->dev)) {
bnx2_netif_stop(bp);
+
+ /* Save statistics that is going to be reseted */
+ memcpy(bp->stats_extra, &bp->dev->stats,
+ sizeof(struct net_device_stats));
+
bnx2_reset_chip(bp, BNX2_DRV_MSG_CODE_RESET);
bnx2_free_skbs(bp);
bnx2_free_mem(bp);
@@ -7649,6 +7669,7 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
bp->flags = 0;
bp->phy_flags = 0;
+ bp->stats_extra = kzalloc(sizeof(struct net_device_stats), GFP_KERNEL);
/* enable device (incl. PCI PM wakeup), and bus-mastering */
rc = pci_enable_device(pdev);
@@ -8162,6 +8183,7 @@ bnx2_remove_one(struct pci_dev *pdev)
if (bp->regview)
iounmap(bp->regview);
+ kfree(bp->stats_extra);
free_netdev(dev);
pci_release_regions(pdev);
pci_disable_device(pdev);
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index a4d8340..b29b0d5 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6912,6 +6912,7 @@ struct bnx2 {
const struct firmware *mips_firmware;
const struct firmware *rv2p_firmware;
+ struct net_device_stats *stats_extra;
};
#define REG_RD(bp, offset) \
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 1/3] netdevice: provide common routine for macvlan and vlan operstate management
From: Patrick Mullaney @ 2009-11-27 17:06 UTC (permalink / raw)
To: arnd; +Cc: bridge, alacrityvm-devel, kaber, linux-kernel, netdev
Thanks. I'll post an updated patch.
On Fri, 2009-11-27 at 14:09 +0100, Arnd Bergmann wrote:
> On Friday 13 November 2009, Patrick Mullaney wrote:
> > @@ -551,7 +532,7 @@ static int macvlan_newlink(struct net_device *dev,
> > return err;
> >
> > list_add_tail(&vlan->list, &port->vlans);
> > - macvlan_transfer_operstate(dev);
> > + netif_stacked_transfer_operstate(dev, lowerdev);
> > return 0;
> > }
> >
> > @@ -591,7 +572,8 @@ static int macvlan_device_event(struct notifier_block *unused,
> > switch (event) {
> > case NETDEV_CHANGE:
> > list_for_each_entry(vlan, &port->vlans, list)
> > - macvlan_transfer_operstate(vlan->dev);
> > + netif_stacked_transfer_operstate(vlan->dev,
> > + vlan->lowerdev);
> > break;
> > case NETDEV_FEAT_CHANGE:
> > list_for_each_entry(vlan, &port->vlans, list) {
>
> These have the arguments reversed, lowerdev should come first.
>
> Arnd <><
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-27 18:07 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Frans Pop, Andi Kleen, linux-kernel, netdev, Jeff Kirsher,
Jesse Brandeburg, e1000-devel
In-Reply-To: <20091125191105.GA3167@ami.dom.local>
2.6.32-rc8 seemed to be affected (guess. because my net didn't come up
on reboot. further testing will likely verify) also during reboots I
found out that the version I've been thinking is good is afflicted. I
supposed maybe I should try bisecting again? starting with that point.
not sure it'll do us much good if that version was able to slip by for
so long. I really hate intermittent bugs.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Frederic Leroy @ 2009-11-27 20:53 UTC (permalink / raw)
To: Asdo; +Cc: netdev, e1000-devel, Ilpo Järvinen
In-Reply-To: <4B0FCC6D.3050003@shiftmail.org>
Le Fri, 27 Nov 2009 13:56:13 +0100,
Asdo <asdo@shiftmail.org> a écrit :
> Frederic Leroy wrote:
> > Le Wed, 25 Nov 2009 05:25:28 +0100,
> > Asdo <asdo@shiftmail.org> a écrit :
> >
> >
> >> Hi netdev and e1000 people,
> >>
> >> I have a weird problem here.
> >> [...]
> > I have the same kind of problem at home. I can't copy big files over
> > [...]
> Good God it's true then!
Yes :)
> Still if I am right, with Netcat you might end up with a corrupted
> file on the other side (shorter). Or maybe not, depending on how
> exactly the bug is made. Could you check this? Filesize and md5sum.
md5sum are ok.
I can't reproduce the problem on wire with a switch ( using both
10 and 100Mbp FD )
> Do you have Intel network card, with e1000e driver on SG? (see lsmod)
> (sorry I was wrong before, it's e1000e in my case not e1000)
> Otherwise it's probably the TCP layer...
Sorry, I forgot to precise the network hardware.
I forgot a noname 100Mbp switch between the isv box and sg host.
SG:
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
using module 8139cp
Devel:
02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller (rev 03)
using b43 driver.
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB)
Ethernet Controller (rev 81)
using e100 in kernel ( no module )
My isv box is broadcom based, but I don't know which chipset for
wireless.
Since our hardware are different, I don't think it's coming from
hardware driver. I'm preparing traces for Ilpo
--
Frédéric Leroy
^ 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