* Re: [PATCH 1/2] net: ipv6: af_inet6: Fix warning when CONFIG_SYSCTL=n
From: Hannes Frederic Sowa @ 2013-11-16 18:26 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Fabio Estevam, davem, netdev, Fabio Estevam
In-Reply-To: <5287B3E2.2030301@gmail.com>
On Sat, Nov 16, 2013 at 01:05:22PM -0500, Vlad Yasevich wrote:
> On 11/15/2013 09:52 PM, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam@freescale.com>
> >
> > When CONFIG_SYSCTL=n the following build warning happens:
> >
> > net/ipv6/af_inet6.c:710:13: warning: 'ipv6_packet_cleanup' defined but not used [-Wunused-function]
> >
> > ipv6_packet_cleanup() is only used when CONFIG_SYSCTL=y, so protect its
> > definition with an'ifdef CONFIG_SYSCTL'.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> > net/ipv6/af_inet6.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> > index ff75313..e4ad65c 100644
> > --- a/net/ipv6/af_inet6.c
> > +++ b/net/ipv6/af_inet6.c
> > @@ -707,10 +707,12 @@ static int __init ipv6_packet_init(void)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_SYSCTL
> > static void ipv6_packet_cleanup(void)
> > {
> > dev_remove_pack(&ipv6_packet_type);
> > }
> > +#endif
> >
> > static int __net_init ipv6_init_mibs(struct net *net)
> > {
> >
>
> NACK. ipv6_packet_init and ipv6_packet_cleanup should in no way depend
> on sysctl.
It is only used in an error path if CONFIG_SYSCTL=y. I agree it does
look a bit odd.
Maybe just add __maybe_unused to ipv6_packet_cleanup?
^ permalink raw reply
* [PATCH] ipv6: Fix inet6_init() cleanup order
From: Vlad Yasevich @ 2013-11-16 19:01 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Hannes Frederic Sowa, lorenzo, Fabio Estevam
Commit 6d0bfe22611602f36617bc7aa2ffa1bbb2f54c67
net: ipv6: Add IPv6 support to the ping socket
introduced a change in the cleanup logic of inet6_init and
has a bug in that ipv6_packet_cleanup() may not be called.
Fix the cleanup ordering and add __maybe_unused to pingv6_exit
since it may not be called if CONFIG_SYSCTL is turned off.
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Lorenzo Colitti <lorenzo@google.com>
CC: Fabio Estevam <fabio.estevam@freescale.com>
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
---
net/ipv6/af_inet6.c | 4 ++--
net/ipv6/ping.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 6468bda..56ca35b 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -958,10 +958,10 @@ out:
#ifdef CONFIG_SYSCTL
sysctl_fail:
- ipv6_packet_cleanup();
+ pingv6_exit();
#endif
pingv6_fail:
- pingv6_exit();
+ ipv6_packet_cleanup();
ipv6_packet_fail:
tcpv6_exit();
tcpv6_fail:
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index 8815e31..5da68ae 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -263,7 +263,7 @@ int __init pingv6_init(void)
/* This never gets called because it's not possible to unload the ipv6
module,
* but just in case.
*/
-void pingv6_exit(void)
+void __maybe_unused pingv6_exit(void)
{
pingv6_ops.ipv6_recv_error = dummy_ipv6_recv_error;
pingv6_ops.ip6_datagram_recv_ctl = dummy_ip6_datagram_recv_ctl;
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3] net: don't return uninitialized addresses on concurrent socket shutdown
From: Hannes Frederic Sowa @ 2013-11-16 19:19 UTC (permalink / raw)
To: mpb, netdev, eric.dumazet
In-Reply-To: <20131116054814.GH26901@order.stressinduktion.org>
If a blocking read waits on a socket which gets concurrently shut down we
return 0 as error and so indicate success to the socket functions which
thus copies an uninitialized stack allocated address back to the user.
Fix this by introducing a new AF_INVALID sa_family marker and check if the
recvmsg function overwrote it. In case it was not overwritten, clear the
address with zeros (AF_UNSPEC) before returning it to the user. IMHO we
should only increase msg.msg_namelen (if we have to truncate the address),
so don't clear msg.msg_namelen.
This patch fixes the problem for recvfrom, recvmsg and recvmmsg.
Reported-by: mpb <mpb.mail@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/socket.h | 2 ++
net/socket.c | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 445ef75..bdf9205 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -182,6 +182,8 @@ struct ucred {
#define AF_VSOCK 40 /* vSockets */
#define AF_MAX 41 /* For now.. */
+#define AF_INVALID ((__kernel_sa_family_t)(~0U))
+
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
#define PF_UNIX AF_UNIX
diff --git a/net/socket.c b/net/socket.c
index c226ace..8361e15 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1834,6 +1834,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
if (!sock)
goto out;
+ address.ss_family = AF_INVALID;
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_iovlen = 1;
@@ -1847,6 +1848,8 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
err = sock_recvmsg(sock, &msg, size, flags);
if (err >= 0 && addr != NULL) {
+ if (unlikely(address.ss_family == AF_INVALID))
+ memset(&address, 0, sizeof(address));
err2 = move_addr_to_user(&address,
msg.msg_namelen, addr, addr_len);
if (err2 < 0)
@@ -2226,6 +2229,7 @@ static int ___sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
* kernel msghdr to use the kernel address space)
*/
+ addr.ss_family = AF_INVALID;
uaddr = (__force void __user *)msg_sys->msg_name;
uaddr_len = COMPAT_NAMELEN(msg);
if (MSG_CMSG_COMPAT & flags) {
@@ -2248,6 +2252,8 @@ static int ___sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
len = err;
if (uaddr != NULL) {
+ if (unlikely(addr.ss_family == AF_INVALID))
+ memset(&addr, 0, sizeof(addr));
err = move_addr_to_user(&addr,
msg_sys->msg_namelen, uaddr,
uaddr_len);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] ipv6: Fix inet6_init() cleanup order
From: Hannes Frederic Sowa @ 2013-11-16 19:30 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev@vger.kernel.org, lorenzo, Fabio Estevam
In-Reply-To: <5287C114.3040306@gmail.com>
Hi!
On Sat, Nov 16, 2013 at 02:01:40PM -0500, Vlad Yasevich wrote:
> Commit 6d0bfe22611602f36617bc7aa2ffa1bbb2f54c67
> net: ipv6: Add IPv6 support to the ping socket
>
> introduced a change in the cleanup logic of inet6_init and
> has a bug in that ipv6_packet_cleanup() may not be called.
> Fix the cleanup ordering and add __maybe_unused to pingv6_exit
> since it may not be called if CONFIG_SYSCTL is turned off.
>
> CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
> CC: Lorenzo Colitti <lorenzo@google.com>
> CC: Fabio Estevam <fabio.estevam@freescale.com>
> Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
> ---
> net/ipv6/af_inet6.c | 4 ++--
> net/ipv6/ping.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index 6468bda..56ca35b 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -958,10 +958,10 @@ out:
> #ifdef CONFIG_SYSCTL
> sysctl_fail:
> - ipv6_packet_cleanup();
> + pingv6_exit();
> #endif
> pingv6_fail:
> - pingv6_exit();
> + ipv6_packet_cleanup();
> ipv6_packet_fail:
> tcpv6_exit();
> tcpv6_fail:
Your patch seems corrupt here:
$ patch -p1 < .git/rebase-apply/patch
patching file net/ipv6/af_inet6.c
patch: **** malformed patch at line 22: diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
The logic here looks fine though.
> diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
> index 8815e31..5da68ae 100644
> --- a/net/ipv6/ping.c
> +++ b/net/ipv6/ping.c
> @@ -263,7 +263,7 @@ int __init pingv6_init(void)
> /* This never gets called because it's not possible to unload the ipv6
> module,
> * but just in case.
> */
> -void pingv6_exit(void)
> +void __maybe_unused pingv6_exit(void)
> {
> pingv6_ops.ipv6_recv_error = dummy_ipv6_recv_error;
> pingv6_ops.ip6_datagram_recv_ctl = dummy_ip6_datagram_recv_ctl;
We only would need __maybe_unused if the function which generates
the warning is static in the same compilation unit. So this seems
unneccessary.
Thanks,
Hannes
^ permalink raw reply
* [PATCHv2] ipv6: Fix inet6_init() cleanup order
From: Vlad Yasevich @ 2013-11-16 20:17 UTC (permalink / raw)
To: netdev; +Cc: Vlad Yasevich, Hannes Frederic Sowa, Lorenzo Colitti,
Fabio Estevam
Commit 6d0bfe22611602f36617bc7aa2ffa1bbb2f54c67
net: ipv6: Add IPv6 support to the ping socket
introduced a change in the cleanup logic of inet6_init and
has a bug in that ipv6_packet_cleanup() may not be called.
Fix the cleanup ordering.
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Lorenzo Colitti <lorenzo@google.com>
CC: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
---
net/ipv6/af_inet6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 6468bda..56ca35b 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -958,10 +958,10 @@ out:
#ifdef CONFIG_SYSCTL
sysctl_fail:
- ipv6_packet_cleanup();
+ pingv6_exit();
#endif
pingv6_fail:
- pingv6_exit();
+ ipv6_packet_cleanup();
ipv6_packet_fail:
tcpv6_exit();
tcpv6_fail:
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH net-next] inet: restore gso for vxlan
From: Or Gerlitz @ 2013-11-16 20:23 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Eric Dumazet, David Miller, netdev@vger.kernel.org,
Hannes Frederic Sowa
In-Reply-To: <CAMEtUuwqmUhTgeKyodGKmOxhxe23=umnfc7nouhdVrqVNnk6zQ@mail.gmail.com>
On Fri, Nov 8, 2013, Alexei Starovoitov <ast@plumgrid.com> wrote:
> On Thu, Nov 7, 2013 , Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Sun, 2013-10-27 , Eric Dumazet wrote:
>>> From: Eric Dumazet <edumazet@google.com>
>>> Alexei reported a performance regression on vxlan, caused
>>> by commit 3347c9602955 "ipv4: gso: make inet_gso_segment() stackable"
>>> GSO vxlan packets were not properly segmented, adding IP fragments
>>> while they were not expected.
>>> Rename 'bool tunnel' to 'bool encap', and add a new boolean
>>> to express the fact that UDP should be fragmented.
>>> This fragmentation is triggered by skb->encapsulation being set.
>>>
>>> Remove a "skb->encapsulation = 1" added in above commit,
>>> as its not needed, as frags inherit skb->frag from original
>>> GSO skb.
>>>
>>> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
>>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>>> Tested-by: Alexei Starovoitov <ast@plumgrid.com>
>>> ---
>>> net/ipv4/af_inet.c | 15 +++++++--------
>>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>>> index f4a159e705c0..09d78d4a3cff 100644
>>> --- a/net/ipv4/af_inet.c
>>> +++ b/net/ipv4/af_inet.c
>>> @@ -1251,8 +1251,8 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
>>> struct sk_buff *segs = ERR_PTR(-EINVAL);
>>> const struct net_offload *ops;
>>> unsigned int offset = 0;
>>> + bool udpfrag, encap;
>>> struct iphdr *iph;
>>> - bool tunnel;
>>> int proto;
>>> int nhoff;
>>> int ihl;
>>> @@ -1290,8 +1290,8 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
>>> goto out;
>>> __skb_pull(skb, ihl);
>>>
>>> - tunnel = SKB_GSO_CB(skb)->encap_level > 0;
>>> - if (tunnel)
>>> + encap = SKB_GSO_CB(skb)->encap_level > 0;
>>> + if (encap)
>>> features = skb->dev->hw_enc_features & netif_skb_features(skb);
>>> SKB_GSO_CB(skb)->encap_level += ihl;
>>>
>>> @@ -1306,24 +1306,23 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
>>> if (IS_ERR_OR_NULL(segs))
>>> goto out;
>>>
>>> + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP;
>>
>> It seems I did an error here, shouldn't it be
>>
>> udpfrag = !skb->encapsulation && proto == IPPROTO_UDP;
>>
>> instead ?
>
> oops. yes.
> the segs coming out of udp4_ufo_fragment() in case of udp_tunnel should not
> be marked as ip frags. ip frags are only for UFO.
>
> Thank you for spotting it!
Guys, just to clarify, is this fixed by now? where, net-next?
^ permalink raw reply
* Re: [PATCHv2] ipv6: Fix inet6_init() cleanup order
From: Hannes Frederic Sowa @ 2013-11-16 20:26 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, Lorenzo Colitti, Fabio Estevam
In-Reply-To: <1384633044-26453-1-git-send-email-vyasevich@gmail.com>
On Sat, Nov 16, 2013 at 03:17:24PM -0500, Vlad Yasevich wrote:
> Commit 6d0bfe22611602f36617bc7aa2ffa1bbb2f54c67
> net: ipv6: Add IPv6 support to the ping socket
>
> introduced a change in the cleanup logic of inet6_init and
> has a bug in that ipv6_packet_cleanup() may not be called.
> Fix the cleanup ordering.
>
> CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
> CC: Lorenzo Colitti <lorenzo@google.com>
> CC: Fabio Estevam <fabio.estevam@freescale.com>
> Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v3] net: don't return uninitialized addresses on concurrent socket shutdown
From: Eric Dumazet @ 2013-11-16 20:46 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: mpb, netdev
In-Reply-To: <20131116191916.GC16541@order.stressinduktion.org>
On Sat, 2013-11-16 at 20:19 +0100, Hannes Frederic Sowa wrote:
> If a blocking read waits on a socket which gets concurrently shut down we
> return 0 as error and so indicate success to the socket functions which
> thus copies an uninitialized stack allocated address back to the user.
>
> Fix this by introducing a new AF_INVALID sa_family marker and check if the
> recvmsg function overwrote it. In case it was not overwritten, clear the
> address with zeros (AF_UNSPEC) before returning it to the user. IMHO we
> should only increase msg.msg_namelen (if we have to truncate the address),
> so don't clear msg.msg_namelen.
>
> This patch fixes the problem for recvfrom, recvmsg and recvmmsg.
>
> Reported-by: mpb <mpb.mail@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> include/linux/socket.h | 2 ++
> net/socket.c | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 445ef75..bdf9205 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -182,6 +182,8 @@ struct ucred {
> #define AF_VSOCK 40 /* vSockets */
> #define AF_MAX 41 /* For now.. */
>
> +#define AF_INVALID ((__kernel_sa_family_t)(~0U))
> +
> /* Protocol families, same as address families. */
> #define PF_UNSPEC AF_UNSPEC
> #define PF_UNIX AF_UNIX
> diff --git a/net/socket.c b/net/socket.c
> index c226ace..8361e15 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1834,6 +1834,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
> if (!sock)
> goto out;
>
> + address.ss_family = AF_INVALID;
address.ss_family = AF_UNSPEC;
> msg.msg_control = NULL;
> msg.msg_controllen = 0;
> msg.msg_iovlen = 1;
> @@ -1847,6 +1848,8 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
> err = sock_recvmsg(sock, &msg, size, flags);
>
> if (err >= 0 && addr != NULL) {
> + if (unlikely(address.ss_family == AF_INVALID))
> + memset(&address, 0, sizeof(address));
Why clearing 128 bytes, and return msg.msg_namelen null bytes to the
user ?
What useful information will the user get from this ? Is this even
documented ?
> err2 = move_addr_to_user(&address,
> msg.msg_namelen, addr, addr_len);
> if (err2 < 0)
I really don't think userland should expect to read 128 null bytes if it
asked 128 bytes.
We can certainly return 2 null bytes (AF_UNSPEC) and comply with the
documentation.
if (unlikely(address.ss_family == AF_UNSPEC))
msg.msg_namelen = sizeof(address.ss_family);
^ permalink raw reply
* Re: [PATCH net-next] inet: restore gso for vxlan
From: Eric Dumazet @ 2013-11-16 20:50 UTC (permalink / raw)
To: Or Gerlitz
Cc: Alexei Starovoitov, David Miller, netdev@vger.kernel.org,
Hannes Frederic Sowa
In-Reply-To: <CAJZOPZ+96PudQJabptvb_h5qLLyEVPWruK6mJUh7Z9FW8wk6+A@mail.gmail.com>
On Sat, 2013-11-16 at 22:23 +0200, Or Gerlitz wrote:
> Guys, just to clarify, is this fixed by now? where, net-next?
Should be fixed on all trees :
commit dcd607718385d02ce3741de225927a57f528f93b
("inet: fix a UFO regression")
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe @ 2013-11-16 21:00 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico, Vlad Yasevich; +Cc: Linux Netdev List
In-Reply-To: <5284E137.5010201@gmail.com>
Hi,
sorry for the long delay.
Am 14.11.2013 15:41, schrieb Vlad Yasevich:
> On 11/14/2013 09:29 AM, Stefan Priebe - Profihost AG wrote:
>> Am 14.11.2013 15:27, schrieb Vlad Yasevich:
>>> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>>>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>>>> Can you try out attached patch please. I ran it in my environment and
>>>>> always get promisc link when attaching devices to the bridge.
>>>>
>>>> It's interesting, actually, why do we need to check for IFF_UP at all
>>>> when
>>>> changing flags.
>>>>
>>>> The addition of IFF_UP goes up to:
>>>>
>>>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>>>> Author: Patrick McHardy <kaber@trash.net>
>>>> Date: Tue Oct 7 15:26:48 2008 -0700
>>>>
>>>> net: only invoke dev->change_rx_flags when device is UP
>>>>
>>>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when
>>>> setting a
>>>> VLAN
>>>> device down that is in promiscous mode:
>>>>
>>>> When the VLAN device is set down, the promiscous count on the
>>>> real
>>>> device is decremented by one by vlan_dev_stop(). When removing
>>>> the
>>>> promiscous flag from the VLAN device afterwards, the promiscous
>>>> count on the real device is decremented a second time by the
>>>> vlan_change_rx_flags() callback.
>>>>
>>>> ... snip ...
>>>>
>>>
>>> This was applied in 2.6.27 timeframe.
>>>
>>>> However, I'm not sure that this is still needed, cause:
>>>>
>>>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>>>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>>>> Date: Mon Oct 31 04:53:13 2011 +0000
>>>>
>>>> vlan: Don't propagate flag changes on down interfaces.
>>>>
>>>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>>>> IFF_PROMISC
>>>> flags are cleared or set on the underlying interface. So, if
>>>> these
>>>> flags
>>>> are changed on a vlan interface that is not up, the flags
>>>> underlying
>>>> interface might be set or cleared twice.
>>>>
>>>> Only propagating flag changes when a device is up makes sure this
>>>> does
>>>> not happen. It also makes sure that an underlying device is not
>>>> set to
>>>> promiscuous or allmulti mode for a vlan device that is down.
>>>>
>>>> ... snip ...
>>>>
>>>
>>> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
>>> is something in Ubuntu that changed how the stacked interfaces are
>>> configured and is keeping interfaces down longer then it used to.
>>
>> Stop here ;-) in 3.9 it was the other way round.
>>
>> This one worked:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>
>
> How are you attaching tap to the vlan device? Or is it attached to
> vmbr1?
No, to vmbr1.3000.
>> this one did not:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>
>> Now with the patch - the 2nd one works the first one does not.
>
> Ok, in this case, you have a VLAN (bond1.3000) configured on top of
> bond interface. That vlan is then attached to the bridge (vmbr1v3000).
> The tap interface for your VM (tap114i1) is also attached to the same
> bridge. In this case, VM will receive only traffic for VLAN 3000 and
> it we receive it untagged.
Yes and this is also what i want to archieve.
> I guess I'd like to understand what you are trying to achieve.
>
> Thanks working with us on this.
> -vlad
>
>>
>> Stefan
>>
>>>> which fixed completely the initial issue with vlans.
>>>>
>>>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>>>> and
>>>> let the drivers using it handle its own logic, as vlan does?
>>>>
>>>
>>> This should work, but this might regress a few drivers. Looking through
>>> the callers of dev_set_promiscuity at least DSA driver suffers
>>> the same fate as VLAN.
>>>
>>> -vlad
>>>
>>>> Something like this:
>>>>
>>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>>> index 8ffc52e..9615cd7 100644
>>>> --- a/net/core/dev.c
>>>> +++ b/net/core/dev.c
>>>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>>>> *dev, int flags)
>>>> {
>>>> const struct net_device_ops *ops = dev->netdev_ops;
>>>>
>>>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>>>> + if (ops->ndo_change_rx_flags)
>>>> ops->ndo_change_rx_flags(dev, flags);
>>>> }
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> -vlad
>>>
>
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Stefan Priebe @ 2013-11-16 21:02 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico; +Cc: vyasevic, Linux Netdev List
In-Reply-To: <52853D02.70804@gmail.com>
Am 14.11.2013 22:13, schrieb Vlad Yasevich:
> On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
>> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hi,
>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>
>>> thos one works fine now.
>>>
>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>
>>> this one does not. Another note to this one. It also never worked on
>>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>>> 3.10. But it was the only one where gvrp on vlans had worked.
>>
>> bridge device in this config is neither master nor slave, if I read it
>> correctly.
>
> Bridge doesn't propagate rx_flags to lower-level devices. It
> automatically set all lower devices to promisc mode.
>
> So, in the second case above, eth2 and eth3 have to be in promisc, but
> nothing else does. I am not sure I understand Stefans notation though
> wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
> elaborate?
Sorry . means vlan - so vmbr1.3000 is just a vlan on top of vmbr1. *brX
is a bridge. Bond is a lacp bond ;-)
Stefan
>
> Thanks
> -vlad
>>
>> You might want to try my patch to see if it works (my previous email).
>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: Or Gerlitz @ 2013-11-16 21:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexei Starovoitov, David Miller, Eric Dumazet, Stephen Hemminger,
netdev@vger.kernel.org, Michael S. Tsirkin, John Fastabend
On Sat, Oct 26, 2013 at 6:13 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2013-10-25 at 19:22 -0700, Alexei Starovoitov wrote:
>> On Fri, Oct 25, 2013 at 6:25 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > While investigating on a recent vxlan regression, I found veth
>> > was using a zero features set for vxlan tunnels.
>>
>> oneliner can be better :)
>
> Yes, I'll post the gso fix as well, of course ;)
>
>>
>> > We have to segment GSO frames, copy the payload, and do the checksum.
>> >
>> > This patch brings a ~200% performance increase
>> >
>> > We probably have to add hw_enc_features support
>> > on other virtual devices.
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>> > Cc: Alexei Starovoitov <ast@plumgrid.com>
>> > ---
>>
>> iperf over veth with gre/vxlan tunneling is now ~4Gbps. 20x gain as advertised.
>> Thanks!
>
> Wow, such a difference might show another bug somewhere else...
Guys (thanks Eric for the clarification over the other vxlan thread),
with the latest networking code (e.g 3.12 or net-next) do you expect
notable performance (throughput) difference between these two configs?
1. bridge --> vxlan --> NIC
2. veth --> bridge --> vxlan --> NIC
BTW #2 doesn't work when packets start to be large unless I manually
decrease the veth device pair MTU. E.g if the NIC MTU is 1500, vxlan
advertizes an MTU of 1450 (= 1500 - (14 + 20 + 8 + 8)) and the bridge
inherits that, but not the veth device. Should someone/somewhere here
generate an ICMP packet which will cause the stack to decreate the
path mtu for the neighbour created on the veth device? what about
para-virtualized guests which are plugged into this (or any host based
tunneling) scheme, e.g in this scheme
3. guest virtio NIC --> vhost --> tap/macvtap --> bridge --> vxlan --> NIC
Who/how do we want the guest NIC mtu/path mtu to take into account the
tunneling over-head?
Or.
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: Eric Dumazet @ 2013-11-16 21:40 UTC (permalink / raw)
To: Or Gerlitz
Cc: Alexei Starovoitov, David Miller, Eric Dumazet, Stephen Hemminger,
netdev@vger.kernel.org, Michael S. Tsirkin, John Fastabend
In-Reply-To: <CAJZOPZ+jUanPW2mT_HiSWdvGfdRMHpX6vWyrboS3Zf_gH7rEgQ@mail.gmail.com>
On Sat, 2013-11-16 at 23:11 +0200, Or Gerlitz wrote:
> Guys (thanks Eric for the clarification over the other vxlan thread),
> with the latest networking code (e.g 3.12 or net-next) do you expect
> notable performance (throughput) difference between these two configs?
>
> 1. bridge --> vxlan --> NIC
> 2. veth --> bridge --> vxlan --> NIC
>
> BTW #2 doesn't work when packets start to be large unless I manually
> decrease the veth device pair MTU. E.g if the NIC MTU is 1500, vxlan
> advertizes an MTU of 1450 (= 1500 - (14 + 20 + 8 + 8)) and the bridge
> inherits that, but not the veth device. Should someone/somewhere here
> generate an ICMP packet which will cause the stack to decreate the
> path mtu for the neighbour created on the veth device? what about
> para-virtualized guests which are plugged into this (or any host based
> tunneling) scheme, e.g in this scheme
>
> 3. guest virtio NIC --> vhost --> tap/macvtap --> bridge --> vxlan --> NIC
>
> Who/how do we want the guest NIC mtu/path mtu to take into account the
> tunneling over-head?
I mentioned this problem on another thread : gso packets escape the
normal mtu checks in ip forwarding.
vi +91 net/ipv4/ip_forward.c
gso_size contains the size of the segment minus all headers.
Please try the following :
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index d68633452d9b..489b56935a56 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -388,4 +388,16 @@ static inline int fastopen_init_queue(struct sock *sk, int backlog)
return 0;
}
+static inline unsigned int gso_size_with_headers(const struct sk_buff *skb)
+{
+ unsigned int hdrlen = skb_transport_header(skb) - skb_mac_header(skb);
+
+ if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
+ hdrlen += tcp_hdrlen(skb);
+ else
+ hdrlen += 8; // sizeof(struct udphdr)
+
+ return skb_shinfo(skb)->gso_size + hdrlen;
+}
+
#endif /* _LINUX_TCP_H */
diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
index 694de3b7aebf..3949cc1dd1ca 100644
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -57,6 +57,7 @@ int ip_forward(struct sk_buff *skb)
struct iphdr *iph; /* Our header */
struct rtable *rt; /* Route we use */
struct ip_options *opt = &(IPCB(skb)->opt);
+ unsigned int len;
if (skb_warn_if_lro(skb))
goto drop;
@@ -88,7 +89,11 @@ int ip_forward(struct sk_buff *skb)
if (opt->is_strictroute && rt->rt_uses_gateway)
goto sr_failed;
- if (unlikely(skb->len > dst_mtu(&rt->dst) && !skb_is_gso(skb) &&
+ len = skb->len;
+ if (skb_is_gso(skb))
+ len = gso_size_with_headers(skb);
+
+ if (unlikely(len > dst_mtu(&rt->dst) &&
(ip_hdr(skb)->frag_off & htons(IP_DF))) && !skb->local_df) {
IP_INC_STATS(dev_net(rt->dst.dev), IPSTATS_MIB_FRAGFAILS);
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
^ permalink raw reply related
* Re: [PATCH v3] net: don't return uninitialized addresses on concurrent socket shutdown
From: mpb @ 2013-11-16 21:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Hannes Frederic Sowa, netdev
In-Reply-To: <1384634802.8604.14.camel@edumazet-glaptop2.roam.corp.google.com>
>> @@ -1847,6 +1848,8 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
>> err = sock_recvmsg(sock, &msg, size, flags);
>>
>> if (err >= 0 && addr != NULL) {
>> + if (unlikely(address.ss_family == AF_INVALID))
>> + memset(&address, 0, sizeof(address));
Or perhaps only when err == 0?
if (err >= 0 && addr != NULL) {
+ if ( (err == 0) && unlikely(address.ss_family == AF_INVALID) )
+ memset(&address, 0, sizeof(address));
In other words, in pseudo code:
When err == 0, the kernel checks to make sure the socket has not been
shutdown before calling move_addr_to_user.
If err == 0 and a shutdown has happened, then set addr to a value that
signifies that a shutdown was detected (or at least that a message was
not received). After a shutdown, I believe err will only be one of 0
or -1. If err > 0, then a shutdown has not happened.
Another approach would be to return -1 to userland and set errno to
something like EWOULDBLOCK.
Another thought: addr_len is probably smaller than sizeof(address), so
only memset whichever is smaller.
If I had a *BSD box or VM sitting around, I would look to see what
*BSD does (and perhaps copy the *BSD behavior if it were acceptable).
Eric Dumazet wrote:
> I really don't think userland should expect to read 128 null bytes if it
> asked 128 bytes.
>
> We can certainly return 2 null bytes (AF_UNSPEC)
AF_UNSPEC is good (and sufficient, IMO).
Do we need to add AF_INVALID at all? Why not just use AF_UNSPEC?
> and comply with the documentation.
What documentation? The interesting thing about this situation is I
have not seen any manpage that describes what should happen after a
concurrent shutdown.
-mpb
^ permalink raw reply
* Re: [PATCH v3] net: don't return uninitialized addresses on concurrent socket shutdown
From: Hannes Frederic Sowa @ 2013-11-16 22:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: mpb, netdev
In-Reply-To: <1384634802.8604.14.camel@edumazet-glaptop2.roam.corp.google.com>
On Sat, Nov 16, 2013 at 12:46:42PM -0800, Eric Dumazet wrote:
> On Sat, 2013-11-16 at 20:19 +0100, Hannes Frederic Sowa wrote:
> > If a blocking read waits on a socket which gets concurrently shut down we
> > return 0 as error and so indicate success to the socket functions which
> > thus copies an uninitialized stack allocated address back to the user.
> >
> > Fix this by introducing a new AF_INVALID sa_family marker and check if the
> > recvmsg function overwrote it. In case it was not overwritten, clear the
> > address with zeros (AF_UNSPEC) before returning it to the user. IMHO we
> > should only increase msg.msg_namelen (if we have to truncate the address),
> > so don't clear msg.msg_namelen.
> >
> > This patch fixes the problem for recvfrom, recvmsg and recvmmsg.
> >
> > Reported-by: mpb <mpb.mail@gmail.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
> > include/linux/socket.h | 2 ++
> > net/socket.c | 6 ++++++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/include/linux/socket.h b/include/linux/socket.h
> > index 445ef75..bdf9205 100644
> > --- a/include/linux/socket.h
> > +++ b/include/linux/socket.h
> > @@ -182,6 +182,8 @@ struct ucred {
> > #define AF_VSOCK 40 /* vSockets */
> > #define AF_MAX 41 /* For now.. */
> >
> > +#define AF_INVALID ((__kernel_sa_family_t)(~0U))
> > +
> > /* Protocol families, same as address families. */
> > #define PF_UNSPEC AF_UNSPEC
> > #define PF_UNIX AF_UNIX
> > diff --git a/net/socket.c b/net/socket.c
> > index c226ace..8361e15 100644
> > --- a/net/socket.c
> > +++ b/net/socket.c
> > @@ -1834,6 +1834,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
> > if (!sock)
> > goto out;
> >
> > + address.ss_family = AF_INVALID;
>
>
> address.ss_family = AF_UNSPEC;
That might be possible. Because I was afraid that AF_UNSPEC could re misused
in some other protocols I decided to use the (what I think) more robust
AF_INVALID.
>
> > msg.msg_control = NULL;
> > msg.msg_controllen = 0;
> > msg.msg_iovlen = 1;
> > @@ -1847,6 +1848,8 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
> > err = sock_recvmsg(sock, &msg, size, flags);
> >
> > if (err >= 0 && addr != NULL) {
> > + if (unlikely(address.ss_family == AF_INVALID))
> > + memset(&address, 0, sizeof(address));
>
> Why clearing 128 bytes, and return msg.msg_namelen null bytes to the
> user ?
>
> What useful information will the user get from this ? Is this even
> documented ?
>
>
> > err2 = move_addr_to_user(&address,
> > msg.msg_namelen, addr, addr_len);
> > if (err2 < 0)
>
> I really don't think userland should expect to read 128 null bytes if it
> asked 128 bytes.
>
> We can certainly return 2 null bytes (AF_UNSPEC) and comply with the
> documentation.
>
> if (unlikely(address.ss_family == AF_UNSPEC))
> msg.msg_namelen = sizeof(address.ss_family);
I have thought about that:
I do think it is common to call recvfrom, process the packet and sendto
back a packet with the updated values from recvfrom. We accept AF_UNSPEC
on an IPv4 UDP socket and use the addresses as it would be a AF_INET
sockaddr. We only bail out if the port is 0.
It was my intend to at least clear the addressing portions of the regular
sockaddr_* structure for the user as it could be reused as explained
earlier and be allocated uninitialized on the stack (or reused, so
sending packet to a previous destination). I think it is very uncommon to
expect a non-error value on a recvfrom/recvmsg and have AF_UNSPEC in the
sockaddr.
(I erroneously stated that we could return the full 128 zero bytes, we only
clear 128 bytes and return only max(128, msg.msg_namelen). msg_namelen gets
updated by the recvmsg handler and that only iff we have this concurrent
shutdown and blocking read issue.)
If the socket structure is cleared a following sendto would produce a -EINVAL.
Maybe I am too sensible regarding such problems and will think about that a
bit more (and check for AF_INVALID/AF_UNSPEC).
Thanks,
Hannes
^ permalink raw reply
* oops in pskb_expand_head - 3.11.6
From: Michele Baldessari @ 2013-11-16 23:16 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa
Hi all,
Two oops like the following were reported in Fedora 19 - kernel 3.11.6:
https://bugzilla.redhat.com/show_bug.cgi?id=1015905
Seems ipv6/netfilter related (?), could not find any obvious commit that
fixed it in later versions.
Environment description (from the BZ):
When a local client attempts to send an IPv6 packet larger than the MTU,
the kernel on the router panics. In normal operation this shouldn't
happen but a simple 'ping6 -s 1490 www.google.com' from a client will
trigger the panic.
If you try this from the router itself, you get 'Packet too big:
mtu=1472' but no panic suggesting this is a 'forward' issue.
How reproducible:
'ping6 -s 1490 www.google.com' from a client will reproduce every time.
Steps to Reproduce:
1. Set up a pppoe connection
2. Set up a 6rd SIT tunnel over the pppoe connection
3. Set up infrastructure to distribute delegated IPv6 addresses
4. From a client run 'ping6 -s 1490 www.google.com'
enp1s0 = lan
enp2s0 = wan
ppp0 = pppoe via enp2s0
rdhe0 = sit via ppp0
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:22:4d:9a:5d:9d brd ff:ff:ff:ff:ff:ff
inet 192.168.101.254/24 brd 192.168.101.255 scope global enp2s0 valid_lft forever preferred_lft forever
inet6 fe80::222:4dff:fe9a:5d9d/64 scope link valid_lft forever preferred_lft forever
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:22:4d:9a:5d:a1 brd ff:ff:ff:ff:ff:ff
inet 192.168.147.1/24 brd 192.168.147.255 scope global enp1s0 valid_lft forever preferred_lft forever
inet6 2001:XXXX:XXXX:13d:2::1/128 scope global valid_lft forever preferred_lft forever
inet6 fe80::222:4dff:fe9a:5da1/64 scope link valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
5: rdhe0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue state UNKNOWN
link/sit 65.XXX.XXX.14 peer 184.105.250.46 inet6 2001:XXXX:XXXX:13d::2/64 scope global valid_lft forever preferred_lft forever
inet6 fe80::4166:d30e/128 scope link valid_lft forever preferred_lft forever
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp inet 65.XXX.XXX.14 peer 207.XXX.XXX.6/32 scope global ppp0
valid_lft forever preferred_lft forever
[ 573.858967] kernel BUG at net/core/skbuff.c:1059!
[ 573.864743] invalid opcode: 0000 [#1] SMP
[ 573.869856] Modules linked in: pppoe pppox ppp_synctty ppp_async crc_ccitt ppp_generic slhc 8021q garp stp mrp llc xt_policy xt_NFLOG
nfnetlink_log nfnetlink nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_rt xt_conntrack iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4
ip6table_filter nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_TCPMSS ip6table_mangle ip6_tables e1000e(OF) x86_pkg_temp_thermal kvm_intel
w83627ehf hwmon_vid coretemp kvm crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_intel microcode snd_hda_codec r8169 mii snd_hwdep snd_seq snd_seq_device snd_pcm iTCO_wdt iTCO_vendor_support snd_page_alloc
snd_timer snd soundcore serio_raw shpchp mei_me lpc_ich mei i2c_i801 mfd_core mperf usb_storage i915 video i2c_algo_bit drm_kms_helper drm
ata_generic i2c_core pata_acpi
[ 573.906875] CPU: 3 PID: 0 Comm: swapper/3 Tainted: GF O 3.11.6-200.fc19.x86_64 #1
[ 573.909619] Hardware name: /DQ67EP, BIOS SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
[ 573.911658] task: ffff880138305b80 ti: ffff880138334000 task.ti: ffff880138334000
[ 573.913273] RIP: 0010:[<ffffffff8153def0>] [<ffffffff8153def0>] pskb_expand_head+0x260/0x2a0
[ 573.915167] RSP: 0018:ffff88013e3836a8 EFLAGS: 00010202
[ 573.916318] RAX: 0000000000000003 RBX: ffff8800376d2900 RCX: 0000000000000020
[ 573.917930] RDX: 000000000000069e RSI: 0000000000000000 RDI: ffff8800376d2900
[ 573.919444] RBP: ffff88013e3836d8 R08: 00000000000000c0 R09: ffff88013667ca00
[ 573.920965] R10: 000000000000ffff R11: 0000000000000002 R12: ffff88013838f000
[ 573.922577] R13: 0000000000000000 R14: ffff88013838f000 R15: ffff8800376d2900
[ 573.924103] FS: 0000000000000000(0000) GS:ffff88013e380000(0000) knlGS:0000000000000000
[ 573.925840] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 573.927519] CR2: 00007fb14b067000 CR3: 0000000135a93000 CR4: 00000000000407e0
[ 573.929034] Stack:
[ 573.929519] ffff8800376d2900 ffff8800376d2900 ffff88013838f000 00000000000005a0
[ 573.931323] ffff88013838f000 ffff8800376d2900 ffff88013e383720 ffffffff8153e290
[ 573.933202] ffff88013838f000 000005a035de089c 0000000000000000 ffff88013838f000
[ 573.935001] Call Trace:
[ 573.935570] <IRQ>
[ 573.936008] [<ffffffff8153e290>] __pskb_pull_tail+0x50/0x360
[ 573.937459] [<ffffffff8154d5bc>] dev_hard_start_xmit+0x2cc/0x560
[ 573.938772] [<ffffffff8156b3b0>] sch_direct_xmit+0xe0/0x1c0
[ 573.939995] [<ffffffff8154da49>] dev_queue_xmit+0x1f9/0x480
[ 573.941218] [<ffffffff81553af1>] neigh_direct_output+0x11/0x20
[ 573.942587] [<ffffffff815f2a58>] ip6_finish_output2+0x168/0x4b0
[ 573.943880] [<ffffffff815f51bd>] ip6_fragment+0x77d/0xa60
[ 573.945065] [<ffffffff815f28f0>] ? ip6_xmit+0x400/0x400
[ 573.946229] [<ffffffff815f5521>] ip6_finish_output+0x81/0xc0
[ 573.947905] [<ffffffff815f559e>] ip6_output+0x3e/0xb0
[ 573.949042] [<ffffffff815f44da>] ip6_forward+0x29a/0x800
[ 573.950212] [<ffffffff81601ba4>] ? ip6_route_input+0xa4/0xd0
[ 573.951497] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.952653] [<ffffffff815f5690>] ip6_rcv_finish+0x80/0x90
[ 573.953844] [<ffffffffa03c386e>] __ipv6_conntrack_in+0xce/0x1a0 [nf_conntrack_ipv6]
[ 573.955520] [<ffffffffa03c39c7>] ipv6_conntrack_in+0x27/0x30 [nf_conntrack_ipv6]
[ 573.957218] [<ffffffff8157a1bb>] nf_iterate+0x8b/0xa0
[ 573.958335] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.959488] [<ffffffff8157a244>] nf_hook_slow+0x74/0x130
[ 573.960653] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.961898] [<ffffffffa03ba203>] nf_ct_frag6_output+0xe3/0x100 [nf_defrag_ipv6]
[ 573.963497] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.964646] [<ffffffffa03b90ca>] ipv6_defrag+0xba/0x100 [nf_defrag_ipv6]
[ 573.966099] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.967716] [<ffffffff8157a1bb>] nf_iterate+0x8b/0xa0
[ 573.968834] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.969984] [<ffffffff8157a244>] nf_hook_slow+0x74/0x130
[ 573.971155] [<ffffffff815f5610>] ? ip6_output+0xb0/0xb0
[ 573.972411] [<ffffffff815f5e18>] ipv6_rcv+0x348/0x440
[ 573.973529] [<ffffffff8154b8e6>] __netif_receive_skb_core+0x646/0x820
[ 573.974928] [<ffffffff81019900>] ? flush_ptrace_hw_breakpoint+0x10/0x60
[ 573.976362] [<ffffffff8154bad8>] __netif_receive_skb+0x18/0x60
[ 573.977703] [<ffffffff8154bb53>] netif_receive_skb+0x33/0xa0
[ 573.978939] [<ffffffff8154c520>] napi_gro_receive+0x80/0xb0
[ 573.980166] [<ffffffffa032241f>] e1000_receive_skb+0x7f/0xe0 [e1000e]
[ 573.981645] [<ffffffffa03249ff>] e1000_clean_rx_irq_ps+0x4af/0x780 [e1000e]
[ 573.983149] [<ffffffffa032cd3d>] e1000e_poll+0x6d/0x310 [e1000e]
[ 573.984460] [<ffffffff813daf0c>] ? add_interrupt_randomness+0x15c/0x190
[ 573.985891] [<ffffffff8154beb9>] net_rx_action+0x149/0x240
[ 573.987550] [<ffffffff8106c427>] __do_softirq+0xf7/0x240
[ 573.988721] [<ffffffff8165875c>] call_softirq+0x1c/0x30
[ 573.989873] [<ffffffff81014695>] do_softirq+0x55/0x90
[ 573.990990] [<ffffffff8106c705>] irq_exit+0xb5/0xc0
[ 573.992241] [<ffffffff81659056>] do_IRQ+0x56/0xc0
[ 573.993295] [<ffffffff8164e9ed>] common_interrupt+0x6d/0x6d
[ 573.994517] <EOI>
[ 573.994954] [<ffffffff815004df>] ? cpuidle_enter_state+0x4f/0xc0
[ 573.996471] [<ffffffff81500619>] cpuidle_idle_call+0xc9/0x210
[ 573.997727] [<ffffffff8101b60e>] arch_cpu_idle+0xe/0x30
[ 573.998875] [<ffffffff810b663e>] cpu_startup_entry+0xce/0x280
[ 574.000131] [<ffffffff8103ed67>] start_secondary+0x217/0x2c0
[ 574.001370] Code: 44 00 00 be 9e 01 00 00 48 c7 c7 f9 ab 9e 81 89 55
d0 e8 44 93 b2 ff 8b 55 d0 e9 7b ff ff ff 41 81 cf 00 20 00 00 e9 f1 fd
ff ff <0f> 0b 0f 0b 44 89 fe 48 89 df e8 d1 f8 ff ff 85 c0 74 12 4c 89
[ 574.008632] RIP [<ffffffff8153def0>] pskb_expand_head+0x260/0x2a0
[ 574.010382] RSP <ffff88013e3836a8>
[ 574.011174] ---[ end trace 3d6846dc38a4d9c7 ]---
[ 574.012433] Kernel panic - not syncing: Fatal exception in interrupt
--
Michele Baldessari <michele@acksyn.org>
C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D
^ permalink raw reply
* Re: oops in pskb_expand_head - 3.11.6
From: Hannes Frederic Sowa @ 2013-11-16 23:42 UTC (permalink / raw)
To: Michele Baldessari; +Cc: netdev, jiri
In-Reply-To: <20131116231615.GA24327@marquez.int.rhx>
Hi!
On Sat, Nov 16, 2013 at 11:16:15PM +0000, Michele Baldessari wrote:
> Two oops like the following were reported in Fedora 19 - kernel 3.11.6:
> https://bugzilla.redhat.com/show_bug.cgi?id=1015905
I have not followed that issue that closely, but could you try linus tree
or net-next?
Maybe those two patches improve the situation:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9037c3579a277f3a23ba476664629fda8c35f7c4
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6aafeef03b9d9ecf255f3a80ed85ee070260e1ae
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: Eric Dumazet @ 2013-11-17 0:09 UTC (permalink / raw)
To: Or Gerlitz
Cc: Alexei Starovoitov, David Miller, Eric Dumazet, Stephen Hemminger,
netdev@vger.kernel.org, Michael S. Tsirkin, John Fastabend
In-Reply-To: <1384638027.8604.22.camel@edumazet-glaptop2.roam.corp.google.com>
On Sat, 2013-11-16 at 13:40 -0800, Eric Dumazet wrote:
> On Sat, 2013-11-16 at 23:11 +0200, Or Gerlitz wrote:
>
> > Guys (thanks Eric for the clarification over the other vxlan thread),
> > with the latest networking code (e.g 3.12 or net-next) do you expect
> > notable performance (throughput) difference between these two configs?
> >
> > 1. bridge --> vxlan --> NIC
> > 2. veth --> bridge --> vxlan --> NIC
> >
> > BTW #2 doesn't work when packets start to be large unless I manually
> > decrease the veth device pair MTU. E.g if the NIC MTU is 1500, vxlan
> > advertizes an MTU of 1450 (= 1500 - (14 + 20 + 8 + 8)) and the bridge
> > inherits that, but not the veth device. Should someone/somewhere here
> > generate an ICMP packet which will cause the stack to decreate the
> > path mtu for the neighbour created on the veth device? what about
> > para-virtualized guests which are plugged into this (or any host based
> > tunneling) scheme, e.g in this scheme
> >
> > 3. guest virtio NIC --> vhost --> tap/macvtap --> bridge --> vxlan --> NIC
> >
> > Who/how do we want the guest NIC mtu/path mtu to take into account the
> > tunneling over-head?
>
> I mentioned this problem on another thread : gso packets escape the
> normal mtu checks in ip forwarding.
>
> vi +91 net/ipv4/ip_forward.c
>
> gso_size contains the size of the segment minus all headers.
>
> Please try the following :
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index d68633452d9b..489b56935a56 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -388,4 +388,16 @@ static inline int fastopen_init_queue(struct sock *sk, int backlog)
> return 0;
> }
>
> +static inline unsigned int gso_size_with_headers(const struct sk_buff *skb)
> +{
> + unsigned int hdrlen = skb_transport_header(skb) - skb_mac_header(skb);
or more exactly :
unsigned int hdrlen = skb_transport_header(skb) - skb_network_header(skb);
> +
> + if (skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))
> + hdrlen += tcp_hdrlen(skb);
> + else
> + hdrlen += 8; // sizeof(struct udphdr)
> +
> + return skb_shinfo(skb)->gso_size + hdrlen;
> +}
^ permalink raw reply
* Re: [PATCH v3] net: don't return uninitialized addresses on concurrent socket shutdown
From: Eric Dumazet @ 2013-11-17 0:36 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: mpb, netdev
In-Reply-To: <20131116224330.GF16541@order.stressinduktion.org>
On Sat, 2013-11-16 at 23:43 +0100, Hannes Frederic Sowa wrote:
> I do think it is common to call recvfrom, process the packet and sendto
> back a packet with the updated values from recvfrom. We accept AF_UNSPEC
> on an IPv4 UDP socket and use the addresses as it would be a AF_INET
> sockaddr. We only bail out if the port is 0.
>
> It was my intend to at least clear the addressing portions of the regular
> sockaddr_* structure for the user as it could be reused as explained
> earlier and be allocated uninitialized on the stack (or reused, so
> sending packet to a previous destination). I think it is very uncommon to
> expect a non-error value on a recvfrom/recvmsg and have AF_UNSPEC in the
> sockaddr.
>
> (I erroneously stated that we could return the full 128 zero bytes, we only
> clear 128 bytes and return only max(128, msg.msg_namelen). msg_namelen gets
> updated by the recvmsg handler and that only iff we have this concurrent
> shutdown and blocking read issue.)
>
> If the socket structure is cleared a following sendto would produce a -EINVAL.
>
> Maybe I am too sensible regarding such problems and will think about that a
> bit more (and check for AF_INVALID/AF_UNSPEC).
>
I think the _default_ should be to clear it.
- msg.msg_namelen = sizeof(address);
+ msg.msg_namelen = 0;
And subsystems filling a real address would set it back to the length
they took care of.
in recvfrom() paths, the kernel _knows_ it uses an array of 128 bytes.
(struct sockaddr_storage)
^ permalink raw reply
* unregister_netdevice: waiting for lo to become free
From: Alexei Starovoitov @ 2013-11-17 2:18 UTC (permalink / raw)
To: netdev
Hi,
once every 24 hr we're hitting namespace cleanup bug:
[53432.230745] unregister_netdevice: waiting for lo to become free.
Usage count = 2
[53442.456822] unregister_netdevice: waiting for lo to become free.
Usage count = 2
[53452.646927] unregister_netdevice: waiting for lo to become free.
Usage count = 2
[53462.861009] unregister_netdevice: waiting for lo to become free.
Usage count = 2
[53468.423648] INFO: task ip:1444 blocked for more than 120 seconds.
[53468.423650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[53468.423651] ip D ffff88082fb13280 0 1444 1443 0x00000000
[53468.423653] ffff8806e0b19dd8 0000000000000002 ffff880754b0aee0
ffff8806e0b19fd8
[53468.423655] ffff8806e0b19fd8 ffff8806e0b19fd8 ffff880803d8ddc0
ffff880754b0aee0
[53468.423657] 0000000000000002 ffffffff81cbe060 ffffffff81cbe064
ffff880754b0aee0
[53468.423658] Call Trace:
[53468.423663] [<ffffffff8164a7b9>] schedule+0x29/0x70
[53468.423664] [<ffffffff8164aace>] schedule_preempt_disabled+0xe/0x10
[53468.423666] [<ffffffff81648b8f>] __mutex_lock_slowpath+0x11f/0x1e0
[53468.423668] [<ffffffff8152b6f1>] ? net_alloc_generic+0x21/0x30
[53468.423670] [<ffffffff8164851a>] mutex_lock+0x2a/0x50
[53468.423671] [<ffffffff8152be20>] copy_net_ns+0x70/0x110
[53468.423674] [<ffffffff81073261>] create_new_namespaces+0x101/0x1b0
[53468.423676] [<ffffffff810734ee>] unshare_nsproxy_namespaces+0x6e/0xb0
[53468.423678] [<ffffffff81047809>] SyS_unshare+0x189/0x2b0
It's reproducible on 3.10.xx
Not clear whether net-next still has it. May be we just didn't run it
long enough.
We've tried to narrow it down over the last month, but didn't go too far.
It can happen on any of our tests. Most of them do: create namespaces,
veth, bridges, run iperf in namespaces, kill them, disconnect
interfaces and so on.
We tried numerous netns specific stress tests, but they all seem to be ok.
It's not clear what combination is causing wrong refcnt.
We tried to add debugging into dst_ifdown() thinking that dev_hold(),
dev_put() combination is causing it somehow, but amount of logs over
24hr is too much.
Similar bug description have been reported on ubuntu forums few times
without real solution. It's not 6549dd43c043
Inside VM with one virtual cpu it hits every 12hr or so.
On physical machine every 24hr or so.
Any advice on where to look or what to try would be greatly appreciated.
Thanks
Alexei
^ permalink raw reply
* Re: [PATCH v3] net: Do not include padding in TCP GRO checksum
From: Herbert Xu @ 2013-11-17 3:17 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Alexander Duyck, davem, netdev, edumazet
In-Reply-To: <5287A52A.2060802@gmail.com>
On Sat, Nov 16, 2013 at 09:02:34AM -0800, Alexander Duyck wrote:
>
> That being the case though, why don't we set the flush flag on detecting
> a bad checksum and hand it off to tcp_gro_receive instead of returning
> NULL? It seems like it would be in our interest to flush the flow and
> then report the bad checksum instead of keeping the flow and handing off
> the bad checksum to the stack.
Because if the TCP checksum is wrong then it may belong to a
different flow.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vladislav Yasevich @ 2013-11-17 3:41 UTC (permalink / raw)
To: Stefan Priebe; +Cc: Veaceslav Falico, Vlad Yasevich, Linux Netdev List
In-Reply-To: <5287DD79.5060906@profihost.ag>
On Sat, Nov 16, 2013 at 4:02 PM, Stefan Priebe <s.priebe@profihost.ag> wrote:
> Am 14.11.2013 22:13, schrieb Vlad Yasevich:
>
>> On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
>>>
>>> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>>>>
>>>>
>>>> thos one works fine now.
>>>>
>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>>>>
>>>>
>>>> this one does not. Another note to this one. It also never worked on
>>>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>>>> 3.10. But it was the only one where gvrp on vlans had worked.
>>>
>>>
>>> bridge device in this config is neither master nor slave, if I read it
>>> correctly.
>>
>>
>> Bridge doesn't propagate rx_flags to lower-level devices. It
>> automatically set all lower devices to promisc mode.
>>
>> So, in the second case above, eth2 and eth3 have to be in promisc, but
>> nothing else does. I am not sure I understand Stefans notation though
>> wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
>> elaborate?
>
>
> Sorry . means vlan - so vmbr1.3000 is just a vlan on top of vmbr1. *brX is a
> bridge. Bond is a lacp bond ;-)
>
Ok. I got that. But where is tap attached? You are showing it
attached to the vlan,
but you can't do that unless its a macvtap. macvtaps on top of bridges is just
asking for trouble.
Thanks
-vlad
> Stefan
>
>
>>
>> Thanks
>> -vlad
>>>
>>>
>>> You might want to try my patch to see if it works (my previous email).
>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: Or Gerlitz @ 2013-11-17 6:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexei Starovoitov, David Miller, Eric Dumazet, Stephen Hemminger,
netdev@vger.kernel.org, Michael S. Tsirkin, John Fastabend
In-Reply-To: <1384638027.8604.22.camel@edumazet-glaptop2.roam.corp.google.com>
On Sat, Nov 16, 2013 at 11:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2013-11-16 at 23:11 +0200, Or Gerlitz wrote:
>
>> Guys (thanks Eric for the clarification over the other vxlan thread),
>> with the latest networking code (e.g 3.12 or net-next) do you expect
>> notable performance (throughput) difference between these two configs?
>>
>> 1. bridge --> vxlan --> NIC
>> 2. veth --> bridge --> vxlan --> NIC
>>
>> BTW #2 doesn't work when packets start to be large unless I manually
>> decrease the veth device pair MTU. E.g if the NIC MTU is 1500, vxlan
>> advertizes an MTU of 1450 (= 1500 - (14 + 20 + 8 + 8)) and the bridge
>> inherits that, but not the veth device. Should someone/somewhere here
>> generate an ICMP packet which will cause the stack to decreate the
>> path mtu for the neighbour created on the veth device? what about
>> para-virtualized guests which are plugged into this (or any host based
>> tunneling) scheme, e.g in this scheme
>>
>> 3. guest virtio NIC --> vhost --> tap/macvtap --> bridge --> vxlan --> NIC
>>
>> Who/how do we want the guest NIC mtu/path mtu to take into account the
>> tunneling over-head?
>
> I mentioned this problem on another thread : gso packets escape the
> normal mtu checks in ip forwarding.
>
> vi +91 net/ipv4/ip_forward.c
>
> gso_size contains the size of the segment minus all headers.
>
> Please try the following :
Will setup & try & let you know. However, this doesn't address non TCP
traffic, e.g pings of large size, correct?
^ permalink raw reply
* [PATCH net 2/4] bnx2x: Prevent panic during DMAE timeout
From: Yuval Mintz @ 2013-11-17 6:59 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, dmitry, Yuval Mintz
In-Reply-To: <1384671569-30105-1-git-send-email-yuvalmin@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
If chip enters a recovery flow just after the driver issues a DMAE request
the DMAE will timeout. Current code will cause a bnx2x_panic() as a result,
which means interface will no longer be usable (regardless of the recovery
results), as bnx2x_panic() is irreversible for the driver.
As this is a possible flow, the panic should be reached only when driver
is compiled with STOP_ON_ERROR.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 8 ++++++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 11 +++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index b42f89c..1d799ee 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -577,7 +577,9 @@ void bnx2x_write_dmae(struct bnx2x *bp, dma_addr_t dma_addr, u32 dst_addr,
rc = bnx2x_issue_dmae_with_comp(bp, &dmae, bnx2x_sp(bp, wb_comp));
if (rc) {
BNX2X_ERR("DMAE returned failure %d\n", rc);
+#ifdef BNX2X_STOP_ON_ERROR
bnx2x_panic();
+#endif
}
}
@@ -614,7 +616,9 @@ void bnx2x_read_dmae(struct bnx2x *bp, u32 src_addr, u32 len32)
rc = bnx2x_issue_dmae_with_comp(bp, &dmae, bnx2x_sp(bp, wb_comp));
if (rc) {
BNX2X_ERR("DMAE returned failure %d\n", rc);
+#ifdef BNX2X_STOP_ON_ERROR
bnx2x_panic();
+#endif
}
}
@@ -9352,6 +9356,10 @@ static int bnx2x_process_kill(struct bnx2x *bp, bool global)
bnx2x_process_kill_chip_reset(bp, global);
barrier();
+ /* clear errors in PGB */
+ if (!CHIP_IS_E1x(bp))
+ REG_WR(bp, PGLUE_B_REG_LATCHED_ERRORS_CLR, 0x7f);
+
/* Recover after reset: */
/* MCP */
if (global && bnx2x_reset_mcp_comp(bp, val))
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
index 5ecf267..3efbb35 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h
@@ -2864,6 +2864,17 @@
#define PGLUE_B_REG_INTERNAL_PFID_ENABLE_TARGET_READ 0x9430
#define PGLUE_B_REG_INTERNAL_PFID_ENABLE_TARGET_WRITE 0x9434
#define PGLUE_B_REG_INTERNAL_VFID_ENABLE 0x9438
+/* [W 7] Writing 1 to each bit in this register clears a corresponding error
+ * details register and enables logging new error details. Bit 0 - clears
+ * INCORRECT_RCV_DETAILS; Bit 1 - clears RX_ERR_DETAILS; Bit 2 - clears
+ * TX_ERR_WR_ADD_31_0 TX_ERR_WR_ADD_63_32 TX_ERR_WR_DETAILS
+ * TX_ERR_WR_DETAILS2 TX_ERR_RD_ADD_31_0 TX_ERR_RD_ADD_63_32
+ * TX_ERR_RD_DETAILS TX_ERR_RD_DETAILS2 TX_ERR_WR_DETAILS_ICPL; Bit 3 -
+ * clears VF_LENGTH_VIOLATION_DETAILS. Bit 4 - clears
+ * VF_GRC_SPACE_VIOLATION_DETAILS. Bit 5 - clears RX_TCPL_ERR_DETAILS. Bit 6
+ * - clears TCPL_IN_TWO_RCBS_DETAILS. */
+#define PGLUE_B_REG_LATCHED_ERRORS_CLR 0x943c
+
/* [R 9] Interrupt register #0 read */
#define PGLUE_B_REG_PGLUE_B_INT_STS 0x9298
/* [RC 9] Interrupt register #0 read clear */
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH net 0/4] bnx2x: Bug fixes patch series
From: Yuval Mintz @ 2013-11-17 6:59 UTC (permalink / raw)
To: davem, netdev; +Cc: ariele, dmitry
Hi Dave,
This series contains several fixes, relating either to SR-IOV flows
or to critical sections protected by the rtnl lock.
Please consider applying these patches to `net'.
Thanks,
Yuval Mintz
^ 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