Netdev List
 help / color / mirror / Atom feed
* [PATCH][net-next] ipv6: rework the lock in addrconf_permanent_addr
From: roy.qing.li @ 2016-03-17  3:39 UTC (permalink / raw)
  To: netdev

From: Li RongQing <roy.qing.li@gmail.com>

1. nothing of idev is changed, so read lock is enough
2. ifp is changed, so used ifp->lock or cmpxchg to protect it

Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
 net/ipv6/addrconf.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8c0dab2..08a9ee9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3178,14 +3178,21 @@ static void addrconf_gre_config(struct net_device *dev)
 static void l3mdev_check_host_rt(struct inet6_dev *idev,
 				  struct inet6_ifaddr *ifp)
 {
+	struct rt6_info *rt = NULL;
+
+	spin_lock(&ifp->lock);
 	if (ifp->rt) {
 		u32 tb_id = l3mdev_fib_table(idev->dev) ? : RT6_TABLE_LOCAL;
 
 		if (tb_id != ifp->rt->rt6i_table->tb6_id) {
-			ip6_del_rt(ifp->rt);
+			rt = ifp->rt;
 			ifp->rt = NULL;
 		}
 	}
+	spin_unlock(&ifp->lock);
+
+	if (rt)
+		ip6_del_rt(rt);
 }
 #else
 static void l3mdev_check_host_rt(struct inet6_dev *idev,
@@ -3197,6 +3204,8 @@ static void l3mdev_check_host_rt(struct inet6_dev *idev,
 static int fixup_permanent_addr(struct inet6_dev *idev,
 				struct inet6_ifaddr *ifp)
 {
+	struct rt6_info *prev;
+
 	l3mdev_check_host_rt(idev, ifp);
 
 	if (!ifp->rt) {
@@ -3206,7 +3215,12 @@ static int fixup_permanent_addr(struct inet6_dev *idev,
 		if (unlikely(IS_ERR(rt)))
 			return PTR_ERR(rt);
 
-		ifp->rt = rt;
+		prev = cmpxchg(&ifp->rt, NULL, rt);
+
+		/*if cmpxchg failed*/
+		if (prev) {
+			ip6_rt_put(rt);
+		}
 	}
 
 	if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
@@ -3228,21 +3242,21 @@ static void addrconf_permanent_addr(struct net_device *dev)
 	if (!idev)
 		return;
 
-	write_lock_bh(&idev->lock);
+	read_lock_bh(&idev->lock);
 
 	list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
 		if ((ifp->flags & IFA_F_PERMANENT) &&
 		    fixup_permanent_addr(idev, ifp) < 0) {
-			write_unlock_bh(&idev->lock);
+			read_unlock_bh(&idev->lock);
 			ipv6_del_addr(ifp);
-			write_lock_bh(&idev->lock);
+			read_lock_bh(&idev->lock);
 
 			net_info_ratelimited("%s: Failed to add prefix route for address %pI6c; dropping\n",
 					     idev->dev->name, &ifp->addr);
 		}
 	}
 
-	write_unlock_bh(&idev->lock);
+	read_unlock_bh(&idev->lock);
 }
 
 static int addrconf_notify(struct notifier_block *this, unsigned long event,
-- 
2.1.4

^ permalink raw reply related

* Re: [PATCH net-next v2 0/4] vxlan: implement Generic Protocol Extension (GPE)
From: David Miller @ 2016-03-17  3:35 UTC (permalink / raw)
  To: jbenc; +Cc: netdev, tom, jesse
In-Reply-To: <cover.1458146189.git.jbenc@redhat.com>

From: Jiri Benc <jbenc@redhat.com>
Date: Wed, 16 Mar 2016 17:51:08 +0100

> This patchset implements VXLAN-GPE.

Sorry, this is too late for net-next, please resubmit after the
current merge window.

^ permalink raw reply

* Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink
From: David Miller @ 2016-03-17  3:35 UTC (permalink / raw)
  To: samuel.gauthier; +Cc: pshelar, netdev, dev
In-Reply-To: <1458140872-22438-1-git-send-email-samuel.gauthier@6wind.com>

From: Samuel Gauthier <samuel.gauthier@6wind.com>
Date: Wed, 16 Mar 2016 16:07:50 +0100

> This patchset adds a netlink api to refresh an existing flow in
> openvswitch.

This is too late for net-next, please resubmit this after the
merge window.

Thanks.

^ permalink raw reply

* Re: [PATCH net-next 0/6] bridge: support sending rntl info when we set attributes through sysfs/ioctl
From: David Miller @ 2016-03-17  3:35 UTC (permalink / raw)
  To: lucien.xin; +Cc: netdev, hannes, nikolay
In-Reply-To: <cover.1458134414.git.lucien.xin@gmail.com>

From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 16 Mar 2016 21:34:43 +0800

> This patchset is used to support sending rntl info to user in some places,
> and ensure that whenever those attributes change internally or from sysfs,
> that a netlink notification is sent out to listeners.

This is too late for net-next, please wait until after the merge window.

Thanks.

^ permalink raw reply

* Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: Eric Dumazet @ 2016-03-17  3:34 UTC (permalink / raw)
  To: David Miller; +Cc: weiwan, edumazet, netdev
In-Reply-To: <20160316.223803.240230703927987310.davem@davemloft.net>

On Wed, 2016-03-16 at 22:38 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 16 Mar 2016 17:22:07 -0700
> 
> > One of the issue is that IPV6_MTU getsockopt() will not check the dst,
> > but simply use __sk_dst_get() : It will then report old mtu.
> 
> That's a bug.
> 
> ipv4 does it right with a proper sk_dst_get() and so should
> ipv6.

Using rcu + __sk_dst_get() (in IPv6) is absolutely equivalent to
sk_dst_get() + dst_release() (in IPv4), modulo atomic ops on dst
refcnt...

Presumably IPv6 implementation using rcu is slightly better if this
getsockopt() is badly needed, but apparently nobody cares.

sk_dst_check() is a different beast.

The problem is that dst_mtu(dst) is not able to perform a route lookup
by itself.

Do we really want to use ip6_sk_dst_lookup_flow() and its associated
setup for this IP6_MTU thing, and maybe other points we might use an
obsolete dst ?

Looking at the complexity of udpv6_sendmsg() and rawv6_sendmsg() I
really wonder if it is worth extracting the route logic.

^ permalink raw reply

* 8:25 arriving 9:07, if I catch it....
From: Dave Taht @ 2016-03-17  3:24 UTC (permalink / raw)
  To: netdev@vger.kernel.org

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi

^ permalink raw reply

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
From: Joe Stringer @ 2016-03-17  3:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: ovs dev, netdev, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Joe Stringer, Paolo Abeni, David S. Miller, Pablo Neira Ayuso
In-Reply-To: <1458132481-318209-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>

On 17 March 2016 at 01:47, Arnd Bergmann <arnd@arndb.de> wrote:
> The openvswitch code has gained support for calling into the
> nf-nat-ipv4/ipv6 modules, however those can be loadable modules
> in a configuration in which openvswitch is built-in, leading
> to link errors:
>
> net/built-in.o: In function `__ovs_ct_lookup':
> :(.text+0x2cc2c8): undefined reference to `nf_nat_icmp_reply_translation'
> :(.text+0x2cc66c): undefined reference to `nf_nat_icmpv6_reply_translation'
>
> The dependency on (!NF_NAT || NF_NAT) was meant to prevent
> this, but NF_NAT is set to 'y' if any of the symbols selecting
> it are built-in, but the link error happens when any of them
> are modular.
>
> A second issue is that even if CONFIG_NF_NAT_IPV6 is built-in,
> CONFIG_NF_NAT_IPV4 might be completely disabled. This is unlikely
> to be useful in practice, but the driver currently only handles
> IPv6 being optional.
>
> This patch improves the Kconfig dependency so that openvswitch
> cannot be built-in if either of the two other symbols are set
> to 'm', and it replaces the incorrect #ifdef in ovs_ct_nat_execute()
> with two "if (IS_ENABLED())" checks that should catch all corner
> cases also make the code more readable.
>
> The same #ifdef exists ovs_ct_nat_to_attr(), where it does not
> cause a link error, but for consistency I'm changing it the same
> way.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")

Thanks for the fix, LGTM.

Acked-by: Joe Stringer <joe@ovn.org>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* Re: [PATCH] openvswitch: call only into reachable nf-nat code
From: Joe Stringer @ 2016-03-17  2:54 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: ovs dev, netdev, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paolo Abeni,
	David S. Miller, Pablo Neira Ayuso
In-Reply-To: <2159518.ilphXU8bxQ@wuerfel>

On 17 March 2016 at 02:56, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 16 March 2016 14:25:36 Pablo Neira Ayuso wrote:
>> Not related with this patch, just a side note/recommendation.
>>
>> I understand this code just got into tree, and that this needs a bit
>> work/iterations but this thing above is ugly, I wonder if there is a
>> better way to avoid this.
>>
>> Probably with some modularization of the openvswitch code this will
>> look better, I mean:
>>
>> 1) adding Kconfig switches to enable conntrack and NAT support to
>>    net/openvswitch/Kconfig.
>>
>> 2) Move the NAT code to the corresponding openvswitch/nat.c file.
>>
>> Just my two cents.
>
> Yes, I think that would be good too. I also found that the driver
> used to look like that but it was changed as part of f88f69dd17f1
> ("openvswitch: Remove conntrack Kconfig option.").

I don't see how it helps to separate the conntrack, nat pieces into
different Kconfig switches unless you're splitting their code
completely out of the openvswitch module.

Prior to f88f69dd17f1, OPENVSWITCH Kconfig option had no dependency on
NF_CONNTRACK. OPENVSWITCH_CONNTRACK was a switch to build those pieces
into the OPENVSWITCH module (ie,
"openvswitch-$(CONFIG_OPENVSWITCH_CONNTRACK) += conntrack.o"). If you
configured NF_CONNTRACK=m, OPENVSWITCH=y, OPENVSWITCH_CONNTRACK=y then
it would break in the same kind of way as the bug that Arnd is
reporting. So, that patch was introduced to shift the dependency up to
the OPENVSWITCH kconfig option. At that point, there was no strong
benefit to keeping the conntrack separately configurable, so that was
removed. Further splitting the code out in some way (eg new modules)
seemed way overkill to tidy up some ugly-looking dependency logic.

Maybe someone with better Kconfig-fu than me can point out a better way.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: David Miller @ 2016-03-17  2:38 UTC (permalink / raw)
  To: eric.dumazet; +Cc: weiwan, edumazet, netdev
In-Reply-To: <1458174127.7353.11.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Mar 2016 17:22:07 -0700

> One of the issue is that IPV6_MTU getsockopt() will not check the dst,
> but simply use __sk_dst_get() : It will then report old mtu.

That's a bug.

ipv4 does it right with a proper sk_dst_get() and so should
ipv6.

^ permalink raw reply

* Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"
From: Alexey Kardashevskiy @ 2016-03-17  1:40 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: Eli Cohen, Huy Nguyen, Doug Ledford, Eugenia Emantayev,
	Hal Rosenstock, Sean Hefty, Yishai Hadas, Linux Kernel,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux Netdev List, Paul Mackerras, Carol L Soto, Yevgeny Petrilin,
	Brian J King
In-Reply-To: <CAJ3xEMgorN4r-Ls66rc3VwUBi=uhb==ih2=43ujrbPC=ts8E5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 03/16/2016 08:45 PM, Or Gerlitz wrote:
> On Wed, Mar 16, 2016 at 10:34 AM, Alexey Kardashevskiy <aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org> wrote:
>
>> Oh. ok. It also looks like even with the reverted patch, mlx4 VF does not
>> work in a guest:
>
> So where is the breakage point for you? does 4.4 works? if not, what?

Ah, my bad. It is unrelated to the kernel version.

I tried passing a PF to a guest while its VFs are already passed to another 
guest and see how exactly it blows up (AER/EEH were thrown but the host 
recovered => good) but this left the device in a weird state when I could 
not use VF in a guest anymore but it seemed to keep working on the host.

It seems like the actual adapter does not reset completely when the machine 
is rebooted, I had unplug/replug power cables to fix this.


-- 
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH V3 net-next] ixgbe: Avoid unaligned access in ixgbe_atr() for LLC packets
From: Alexander Duyck @ 2016-03-17  1:31 UTC (permalink / raw)
  To: Sowmini Varadhan
  Cc: Jeff Kirsher, intel-wired-lan, Netdev, Brandeburg, Jesse,
	shannon nelson, Carolyn Wyborny, Skidmore, Donald C,
	Bruce W Allan, John Ronciak, Mitch Williams
In-Reply-To: <20160316230157.GK21307@oracle.com>

On Wed, Mar 16, 2016 at 4:01 PM, Sowmini Varadhan
<sowmini.varadhan@oracle.com> wrote:
> On (03/16/16 15:58), Jeff Kirsher wrote:
>>
>> This does not apply since Alex Duyck beat you to the fix.  Here is the
>> patch he submitted on 3/15 which corrects the issue.  So I am dropping
>> your patch from the queue.
>>
>
> That's weird because Alexander was reviewing my fix on the various
> lists yesterday, so he could have just told me about this.
>
> But, whatever.

Sowmini,

Just for the record I didn't submit it on March 15 I submitted it on
January 26th as per the log in patchwork,
http://patchwork.ozlabs.org/patch/573058/.

Sorry I didn't realize the patch was not against the next-queue.  Back
when I made that fix I was focused on the IPv6 portion of it so that
piece of it had slipped my mind.  If it is any consolation at least my
patch is 7+ weeks ahead in the queue so hopefully the fix will make it
into net-next as soon as the merge window opens.

- Alex

^ permalink raw reply

* [PATCH net] esp: Fix crash observed during device unregistration and decryption
From: Subash Abhinov Kasiviswanathan @ 2016-03-17  0:25 UTC (permalink / raw)
  To: netdev; +Cc: 'Herbert Xu', 'Steffen Klassert'

A crash is observed when a decrypted packet is processed in receive path.
get_rps_cpus() tries to dereference the skb->dev fields but it appears
that the device is freed from the poison pattern.

[<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
[<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
[<ffffffc000af6094>] netif_rx+0x74/0x94
[<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
[<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
[<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
[<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
[<ffffffc0000b7324>] worker_thread+0x2f8/0x418
[<ffffffc0000bb40c>] kthread+0xe0/0xec

-013|get_rps_cpu(
     |    dev = 0xFFFFFFC08B688000,
     |    skb = 0xFFFFFFC0C76AAC00 -> (
     |      dev = 0xFFFFFFC08B688000 -> (
     |        name =
"......................................................
     |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
0xAAAAAAAAAAA

Following are the sequence of events observed -

- Encrypted packet in receive path from netdevice is queued
- Encrypted packet queued for decryption (asynchronous)
- Netdevice brought down and freed
- Packet is decrypted and returned through callback in esp_input_done
- Packet is queued again for process in network stack using netif_rx

Since the device appears to have been freed, the dereference of skb->dev in
get_rps_cpus() leads to an unhandled page fault exception.

Fix this by holding on to device reference when queueing packets
asynchronously and releasing the reference on call back return.

Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
 net/ipv4/esp4.c | 2 ++
 net/ipv6/esp6.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 4779374..d482a96 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -380,6 +380,7 @@ static void esp_input_done(struct crypto_async_request
*base, int err)
 {
 	struct sk_buff *skb = base->data;
 
+	dev_put(skb->dev);
 	xfrm_input_resume(skb, esp_input_done2(skb, err));
 }
 
@@ -454,6 +455,7 @@ static int esp_input(struct xfrm_state *x, struct sk_buff
*skb)
 
 	esph = (struct ip_esp_hdr *)skb->data;
 
+	dev_hold(skb->dev);
 	aead_request_set_callback(req, 0, esp_input_done, skb);
 
 	/* For ESN we move the header forward by 4 bytes to
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 060a60b..12c491a 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -334,6 +334,7 @@ static void esp_input_done(struct crypto_async_request
*base, int err)
 {
 	struct sk_buff *skb = base->data;
 
+	dev_put(skb->dev);
 	xfrm_input_resume(skb, esp_input_done2(skb, err));
 }
 
@@ -408,6 +409,7 @@ static int esp6_input(struct xfrm_state *x, struct sk_buff
*skb)
 
 	esph = (struct ip_esp_hdr *)skb->data;
 
+	dev_hold(skb->dev);
 	aead_request_set_callback(req, 0, esp_input_done, skb);
 
 	/* For ESN we move the header forward by 4 bytes to
-- 

^ permalink raw reply related

* Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: Eric Dumazet @ 2016-03-17  0:22 UTC (permalink / raw)
  To: David Miller; +Cc: weiwan, edumazet, netdev
In-Reply-To: <20160316.195341.68257764618999441.davem@davemloft.net>

On Wed, 2016-03-16 at 19:53 -0400, David Miller wrote:
> From: Wei Wang <weiwan@google.com>
> Date: Mon, 14 Mar 2016 13:59:47 -0700
> 
> > From: Wei Wang <weiwan@google.com>
> > 
> > When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> > the new mtu value is not properly updated in the dst_entry associated
> > with the socket.
> > This leads to the issue that the mtu value returned by getsockopt(sockfd,
> > IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
> > The fix is to update sk->sk_dst_cache and other corresponding fields
> > when a new routing cache is allocated for the new pmtu in UDP connected
> > socket case.
> > 
> > Signed-off-by: Wei Wang <weiwan@google.com>
> 
> Wait a second:
> 
> >  		if (nrt6) {
> >  			rt6_do_update_pmtu(nrt6, mtu);
> > -
> > -			/* ip6_ins_rt(nrt6) will bump the
> > -			 * rt6->rt6i_node->fn_sernum
> > -			 * which will fail the next rt6_check() and
> > -			 * invalidate the sk->sk_dst_cache.
> > -			 */
> > +			if (sk)
> > +				ip6_dst_store(sk, &nrt6->dst, daddr, saddr);
> >  			ip6_ins_rt(nrt6);
> >  		}
> >  	}
> 
> I still haven't seen a satisfactory answer as to why the as-designed
> invalidation mechanism using fn_sernum is not working.
> 
> If that's broken, then a lot of other things won't work properly
> either.
> 
> I've read the ip6_ins_rt() code path several times, and it always
> increments the serial number, and therefore the next dst->check() call
> (which every cached route usage should invoke) should invalide
> this socket's route and lookup the new one.
> 
> Why does this not work?


One of the issue is that IPV6_MTU getsockopt() will not check the dst,
but simply use __sk_dst_get() : It will then report old mtu.

Not sure we want to use the full check and then if dst appears to be
obsolete, do another route lookup ?

^ permalink raw reply

* Re: [PATCH net-next] ethtool: Set cmd field in ETHTOOL_GLINKSETTINGS response to wrong nwords
From: David Miller @ 2016-03-17  0:16 UTC (permalink / raw)
  To: ben; +Cc: netdev
In-Reply-To: <1458171392.31907.39.camel@decadent.org.uk>

From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 16 Mar 2016 23:36:32 +0000

> On Wed, 2016-03-16 at 19:26 -0400, David Miller wrote:
>> From: Ben Hutchings <ben@decadent.org.uk>
>> Date: Mon, 14 Mar 2016 01:05:38 +0000
>> 
>> > When the ETHTOOL_GLINKSETTINGS implementation finds that userland is
>> > using the wrong number of words of link mode bitmaps (or is trying to
>> > find out the right numbers) it sets the cmd field to 0 in the response
>> > structure.
>> > 
>> > This is inconsistent with the implementation of every other ethtool
>> > command, so let's remove that inconsistency before it gets into a
>> > stable release.
>> > 
>> > Fixes: 3f1ac7a700d03 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
>> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> 
>> Applied and queued up for -stable, thanks Ben.
> 
> This doesn't need fixing in any stable release.

My bad I thought it was needed for 4.5-final.

^ permalink raw reply

* Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)
From: Bert Lindner @ 2016-03-16 23:56 UTC (permalink / raw)
  To: Marc Zyngier, Andreas Färber, Robin Murphy
  Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	netdev-u79uwXL29TY76Z2rM5mHXA, Giuseppe Cavallaro
In-Reply-To: <56E99B0C.2070609-5wv7dgnIgG8@public.gmane.org>

On 2016-03-16 18:42, Marc Zyngier wrote:
> On 16/03/16 15:10, Bert Lindner wrote:
>> On 2016-03-16 14:10, Andreas Färber wrote:
>>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>>>> On 16/03/16 11:39, Marc Zyngier wrote:
>>>>> On 16/03/16 11:19, Bert Lindner wrote:
>>>>>> Hopefully this is the correct place and way to report this.
>>>
>>> The main discussion is on netdev list actually, CC'ed.
>>>
>>>>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
>>>>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
>>>>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
>>>>>>
>>>>>> root@lime2-079f:~# ip a l eth0
>>>>>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
>>>>>> default qlen 1000
>>>>>>         link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
>>>>>>
>>>>>>      Difference reported in dmesg:
>>>>>>
>>>>>> 4.5.0-rc7:
>>>>>> [    9.379279] NET: Registered protocol family 10
>>>>>> [   10.217148]  RX IPC Checksum Offload disabled
>>>>>> [   10.217195]  No MAC Management Counters available
>>>>>> [   10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>>>> [   15.206250] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
>>>>>> 1Gbps/Full - flow control off
>>>>>> [   15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>>>>
>>>>>> 4.5.0:
>>>>>> [    9.767125] NET: Registered protocol family 10
>>>>>> [   10.357405] libphy: PHY stmmac-0:ffffffff not found
>>>>>> [   10.362382] eth0: Could not attach to PHY
>>>>>> [   10.366557] stmmac_open: Cannot attach to PHY (error: -19)
>>>>>>
>>>>>> .config is identical for both, also after make oldconfig, apart from
>>>>>> comment with version number. DTB file is also identical between the two
>>>>>> versions.
>>>>>>
>>>>>> Kernels are compiled on the board itself. /proc/version string:
>>>>>> Linux version 4.5.0-rc7 (root@lime2-079f) (gcc version 4.9.1
>>>>>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
>>>>>> Linux version 4.5.0 (root@lime2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
>>>>>> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
>>>>>>
>>>>>> Please let me know if more info is needed, if I should post complete
>>>>>> .config, test compile with a particular config or patch, etc. Part of
>>>>>> .config below.
>>>>>
>>>>> Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
>>>>> regression") and report whether or not this changes anything? This seems
>>>>> to be the only stmac patch between -rc7 and release...
>>>>
>>>> Sounds like the same thing as the giant ongoing discussion thread here:
>>>>
>>>> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
>>>
>>> v4 fixes for 4.5 are here:
>>>
>>> https://patchwork.ozlabs.org/patch/598195/ (revert)
>>> https://patchwork.ozlabs.org/patch/598196/
>>>
>>> v2 fixes for linux-next here:
>>>
>>> https://patchwork.ozlabs.org/patch/598331/ (revert)
>>> https://patchwork.ozlabs.org/patch/598332/
>>>
>>> Please let Peppe know whether they work for you guys.
>>
>> Hi guys - I can confirm 4.5.0 minus 88f8b1b works for me:
>>
>> root@lime2-079f:~# cat /proc/version
>> Linux version 4.5.0-minus-88f8b1b (root@lime2-079f) (gcc version 4.9.1
>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #2 SMP Wed Mar 16 12:50:03 UTC 2016
>>
>>   From dmesg output:
>> [    9.731730] NET: Registered protocol family 10
>> [   10.516893]  RX IPC Checksum Offload disabled
>> [   10.516948]  No MAC Management Counters available
>> [   10.517374] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [   15.505548] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
>> 1Gbps/Full - flow control off
>> [   15.505660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> .. and connected over ethernet.
>
> Good to know, thanks. Could you also give the potential fix a go (as
> mentioned by Andreas)? Just to make sure that whatever gets merged next
> will actually fix the issue.

Yes sure, it took a while because I had to travel. Confirmed, the 
v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:

root@lime2-079f:~# cat /proc/version
Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version 
4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016

dmesg:
[    8.245273] NET: Registered protocol family 10
[    9.297406]  RX IPC Checksum Offload disabled
[    9.297460]  No MAC Management Counters available
[    9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   16.285658] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 
1Gbps/Full - flow control rx/tx
[   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

The board is connected to my laptop rather than to a switch, so that 
might be where the flow control message comes from (not sure). Anyway 
ethernet works.

I'm less familiar with linux-next - not sure what base to test against, 
I understand it is being redefined almost daily.

Thanks!

	-Bert

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply

* Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: David Miller @ 2016-03-16 23:53 UTC (permalink / raw)
  To: weiwan; +Cc: edumazet, netdev
In-Reply-To: <1457989187-92851-1-git-send-email-tracywwnj@gmail.com>

From: Wei Wang <weiwan@google.com>
Date: Mon, 14 Mar 2016 13:59:47 -0700

> From: Wei Wang <weiwan@google.com>
> 
> When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> the new mtu value is not properly updated in the dst_entry associated
> with the socket.
> This leads to the issue that the mtu value returned by getsockopt(sockfd,
> IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
> The fix is to update sk->sk_dst_cache and other corresponding fields
> when a new routing cache is allocated for the new pmtu in UDP connected
> socket case.
> 
> Signed-off-by: Wei Wang <weiwan@google.com>

Wait a second:

>  		if (nrt6) {
>  			rt6_do_update_pmtu(nrt6, mtu);
> -
> -			/* ip6_ins_rt(nrt6) will bump the
> -			 * rt6->rt6i_node->fn_sernum
> -			 * which will fail the next rt6_check() and
> -			 * invalidate the sk->sk_dst_cache.
> -			 */
> +			if (sk)
> +				ip6_dst_store(sk, &nrt6->dst, daddr, saddr);
>  			ip6_ins_rt(nrt6);
>  		}
>  	}

I still haven't seen a satisfactory answer as to why the as-designed
invalidation mechanism using fn_sernum is not working.

If that's broken, then a lot of other things won't work properly
either.

I've read the ip6_ins_rt() code path several times, and it always
increments the serial number, and therefore the next dst->check() call
(which every cached route usage should invoke) should invalide
this socket's route and lookup the new one.

Why does this not work?

^ permalink raw reply

* Re: [PATCH net v2] ppp: ensure file->private_data can't be overridden
From: David Miller @ 2016-03-16 23:39 UTC (permalink / raw)
  To: g.nault; +Cc: netdev, paulus, alan
In-Reply-To: <7866074a3c03ea15640aa72ef2553987862bc8b6.1457986520.git.g.nault@alphalink.fr>

From: Guillaume Nault <g.nault@alphalink.fr>
Date: Mon, 14 Mar 2016 21:17:16 +0100

> Locking ppp_mutex must be done before dereferencing file->private_data,
> otherwise it could be modified before ppp_unattached_ioctl() takes the
> lock. This could lead ppp_unattached_ioctl() to override ->private_data,
> thus leaking reference to the ppp_file previously pointed to.
> 
> v2: lock all ppp_ioctl() instead of just checking private_data in
>     ppp_unattached_ioctl(), to avoid ambiguous behaviour.
> 
> Fixes: f3ff8a4d80e8 ("ppp: push BKL down into the driver")
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>

Applied and queued up for -stable, thanks!

^ permalink raw reply

* Re: [PATCH net-next] ethtool: Set cmd field in ETHTOOL_GLINKSETTINGS response to wrong nwords
From: Ben Hutchings @ 2016-03-16 23:36 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20160316.192638.370528273688631022.davem@davemloft.net>

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

On Wed, 2016-03-16 at 19:26 -0400, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Mon, 14 Mar 2016 01:05:38 +0000
> 
> > When the ETHTOOL_GLINKSETTINGS implementation finds that userland is
> > using the wrong number of words of link mode bitmaps (or is trying to
> > find out the right numbers) it sets the cmd field to 0 in the response
> > structure.
> > 
> > This is inconsistent with the implementation of every other ethtool
> > command, so let's remove that inconsistency before it gets into a
> > stable release.
> > 
> > Fixes: 3f1ac7a700d03 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> 
> Applied and queued up for -stable, thanks Ben.

This doesn't need fixing in any stable release.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH v3 0/9] arc_emac: fixes the emac issues and cleanup emac drivers
From: David Miller @ 2016-03-16 23:28 UTC (permalink / raw)
  To: wxt
  Cc: heiko, robh+dt, linux-rockchip, keescook, leozwang,
	sergei.shtylyov, netdev, devicetree, mturquette, al.kochet, linux,
	sboyd, galak, linux-kernel, ijc+devicetree, trivial, pawel.moll,
	mark.rutland, linux-clk, linux-arm-kernel, zhengxing
In-Reply-To: <1457942520-12859-1-git-send-email-wxt@rock-chips.com>


Series applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] ethtool: Set cmd field in ETHTOOL_GLINKSETTINGS response to wrong nwords
From: David Miller @ 2016-03-16 23:26 UTC (permalink / raw)
  To: ben; +Cc: netdev
In-Reply-To: <20160314010537.GD21187@decadent.org.uk>

From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 14 Mar 2016 01:05:38 +0000

> When the ETHTOOL_GLINKSETTINGS implementation finds that userland is
> using the wrong number of words of link mode bitmaps (or is trying to
> find out the right numbers) it sets the cmd field to 0 in the response
> structure.
> 
> This is inconsistent with the implementation of every other ethtool
> command, so let's remove that inconsistency before it gets into a
> stable release.
> 
> Fixes: 3f1ac7a700d03 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Applied and queued up for -stable, thanks Ben.

^ permalink raw reply

* Re: [PATCH] phy: mdio-thunder: Fix some Kconfig typos
From: David Daney @ 2016-03-16 23:26 UTC (permalink / raw)
  To: Andreas Färber
  Cc: netdev, linux-arm-kernel, David Daney, Florian Fainelli,
	open list
In-Reply-To: <1458170617-31784-1-git-send-email-afaerber@suse.de>

On 03/16/2016 04:23 PM, Andreas Färber wrote:
> Drop two extra occurrences of "on" in option title and help text.
>
> Fixes: 379d7ac7ca31 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.")
> Cc: David Daney <david.daney@cavium.com>
> Signed-off-by: Andreas Färber <afaerber@suse.de>

FWIW:

Acked-by: David Daney <david.daney@cavium.com>

> ---
>   drivers/net/phy/Kconfig | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 075a4cc175b1..6dad9a9c356c 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -197,13 +197,13 @@ config MDIO_OCTEON
>   	  drivers on some systems.
>
>   config MDIO_THUNDER
> -	tristate "Support for MDIO buses on on ThunderX SOCs"
> +	tristate "Support for MDIO buses on ThunderX SOCs"
>   	depends on 64BIT
>   	depends on PCI
>   	select MDIO_CAVIUM
>   	help
>   	  This driver supports the MDIO interfaces found on Cavium
> -	  ThunderX SoCs when the MDIO bus device appears on as a PCI
> +	  ThunderX SoCs when the MDIO bus device appears as a PCI
>   	  device.
>
>
>

^ permalink raw reply

* Re: [PATCH] sh_eth: do not call netif_start_queue() from sh_eth_dev_init()
From: David Miller @ 2016-03-16 23:25 UTC (permalink / raw)
  To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <2129265.GisCEHHzPr@wasted.cogentembedded.com>

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Mon, 14 Mar 2016 01:09:53 +0300

> Iff  sh_eth_phy_start() call fails in sh_eth_open(), the netif_start_queue()
> call done by sh_eth_dev_init()  is not undone.  In order to deal with that,
> stop calling netif_start_queue()  from there, so that it can be called only
> when the device is fully opened and sh_eth_dev_init() only deals with the
> hardware initialization, symmetrically to sh_eth_dev_exit()...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Applied.

^ permalink raw reply

* Re: [PATCH v2 3/3] phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.
From: Andreas Färber @ 2016-03-16 23:24 UTC (permalink / raw)
  To: David Daney
  Cc: Mark Rutland, Florian Fainelli, Robert Richter, Pawel Moll,
	Ian Campbell, netdev, David Daney, linux-kernel, Rob Herring,
	David Daney, Kumar Gala, Sunil Goutham, Radha Mohan Chintakuntla,
	David S. Miller, linux-arm-kernel
In-Reply-To: <56E9E43A.6000304@caviumnetworks.com>

Am 16.03.2016 um 23:54 schrieb David Daney:
> On 03/16/2016 03:50 PM, Andreas Färber wrote:
>> Am 11.03.2016 um 18:53 schrieb David Daney:
>>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>>> index 40faec9..075a4cc 100644
>>> --- a/drivers/net/phy/Kconfig
>>> +++ b/drivers/net/phy/Kconfig
>>> @@ -196,6 +196,17 @@ config MDIO_OCTEON
>>>         buses. It is required by the Octeon and ThunderX ethernet device
>>>         drivers on some systems.
>>>
>>> +config MDIO_THUNDER
>>> +    tristate "Support for MDIO buses on on ThunderX SOCs"
>>
>> Double "on", spotted in next-20160316.
>>
>>> +    depends on 64BIT
>>> +    depends on PCI
>>> +    select MDIO_CAVIUM
>>> +    help
>>> +      This driver supports the MDIO interfaces found on Cavium
>>> +      ThunderX SoCs when the MDIO bus device appears on as a PCI
>>> +      device.
>>
>> While at it, this sentence sounds weird. Did you mean s/as/is/? Or is
>> there another verb missing in there?
> 
> Should be "... appears as a PCI device."
> 
> davem already merged the patch, so this would have to be fixed as a
> follow-on patch.
> 
> Since you found this, do you want to send the patch?

Done.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

^ permalink raw reply

* Re: [PATCH net-next] bnx2x: don't wait for Tx completion on recovery
From: David Miller @ 2016-03-16 23:23 UTC (permalink / raw)
  To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <1457896908-13476-1-git-send-email-Yuval.Mintz@qlogic.com>

From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Sun, 13 Mar 2016 21:21:48 +0200

> When driver has hit a parity event, HW can no longer write to host memory.
> As a result, Tx completions cannot be written to the host SB memory, and
> waiting for Tx completions eventually timeout.
> As driver is willing to delay as much as 1-2 seconds per Tx queue for its
> draining and this delay is sequential, the time to recover might greatly 
> lengthen needlessly in case the recovery is done under multi-connection
> traffic.
> 
> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink
From: Jesse Gross @ 2016-03-16 23:23 UTC (permalink / raw)
  To: Samuel Gauthier; +Cc: ovs dev, Linux Kernel Network Developers, David S. Miller
In-Reply-To: <1458140872-22438-1-git-send-email-samuel.gauthier-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>

On Wed, Mar 16, 2016 at 8:07 AM, Samuel Gauthier
<samuel.gauthier@6wind.com> wrote:
> This patchset adds a netlink api to refresh an existing flow in
> openvswitch.
>
> When a packet is sent in the openvswitch kernel datapath and no
> flow is found, the packet is sent to the ovs-vswitchd daemon,
> which will process the packet, and ask the kernel to create a new
> flow. The next packets for this flow will be processed by the
> kernel datapath. If a flow is not used for a (configurable)
> period of time, ovs-vswitchd removes the flow from the kernel.
>
> As a result, it can be tricky to test the kernel datapath against
> packets, as the first packets of each flow will have to go
> through the ovs-vswitchd daemon. For instance, to do a zeroloss
> performance test, you establish the flows, and then you have to
> perform your zeroloss test before the flow is removed by
> ovs-vswitchd.
>
> It is possible to configure a flow timeout in ovs-vswitchd (using
> other_config:max-idle option), but it changes the behavior for
> all the flows, which is not always what you want.

It seems to me that it would be preferable to implement the necessary
behavior in userspace to handle this directly. The logic that is
removing the flow is in userspace, so rather than asking the kernel to
lie about the current state of things, we can just modify the logic to
handle this case.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox