Netdev List
 help / color / mirror / Atom feed
* Re: [PATCHv2 bluetooth-next 06/10] ndisc: add addr_len parameter to ndisc_fill_addr_option
From: Stefan Schmidt @ 2016-05-03 18:17 UTC (permalink / raw)
  To: Alexander Aring, linux-wpan
  Cc: kernel, marcel, jukka.rissanen, hannes, mcr, werner,
	linux-bluetooth, netdev, David S . Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <1461140382-4784-7-git-send-email-aar@pengutronix.de>

Hello.

On 20/04/16 10:19, Alexander Aring wrote:
> This patch makes the address length as argument for the
> ndisc_fill_addr_option function. This is necessary to handle addresses
> which don't use dev->addr_len as address length.
>
> Cc: David S. Miller<davem@davemloft.net>
> Cc: Alexey Kuznetsov<kuznet@ms2.inr.ac.ru>
> Cc: James Morris<jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI<yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy<kaber@trash.net>
> Signed-off-by: Alexander Aring<aar@pengutronix.de>
> ---
>   net/ipv6/ndisc.c | 15 ++++++++-------
>   1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 4e91d5e..176c7c4 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -150,11 +150,11 @@ struct neigh_table nd_tbl = {
>   };
>   EXPORT_SYMBOL_GPL(nd_tbl);
>   
> -static void ndisc_fill_addr_option(struct sk_buff *skb, int type, void *data)
> +static void ndisc_fill_addr_option(struct sk_buff *skb, int type, void *data,
> +				   int data_len)
>   {
>   	int pad   = ndisc_addr_option_pad(skb->dev->type);
> -	int data_len = skb->dev->addr_len;
> -	int space = ndisc_opt_addr_space(skb->dev, skb->dev->addr_len);
> +	int space = ndisc_opt_addr_space(skb->dev, data_len);
>   	u8 *opt = skb_put(skb, space);
>   
>   	opt[0] = type;
> @@ -528,7 +528,7 @@ void ndisc_send_na(struct net_device *dev, const struct in6_addr *daddr,
>   
>   	if (inc_opt)
>   		ndisc_fill_addr_option(skb, ND_OPT_TARGET_LL_ADDR,
> -				       dev->dev_addr);
> +				       dev->dev_addr, dev->addr_len);
>   
>   
>   	ndisc_send_skb(skb, daddr, src_addr);
> @@ -590,7 +590,7 @@ void ndisc_send_ns(struct net_device *dev, const struct in6_addr *solicit,
>   
>   	if (inc_opt)
>   		ndisc_fill_addr_option(skb, ND_OPT_SOURCE_LL_ADDR,
> -				       dev->dev_addr);
> +				       dev->dev_addr, dev->addr_len);
>   
>   	ndisc_send_skb(skb, daddr, saddr);
>   }
> @@ -641,7 +641,7 @@ void ndisc_send_rs(struct net_device *dev, const struct in6_addr *saddr,
>   
>   	if (send_sllao)
>   		ndisc_fill_addr_option(skb, ND_OPT_SOURCE_LL_ADDR,
> -				       dev->dev_addr);
> +				       dev->dev_addr, dev->addr_len);
>   
>   	ndisc_send_skb(skb, daddr, saddr);
>   }
> @@ -1597,7 +1597,8 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
>   	 */
>   
>   	if (ha)
> -		ndisc_fill_addr_option(buff, ND_OPT_TARGET_LL_ADDR, ha);
> +		ndisc_fill_addr_option(buff, ND_OPT_TARGET_LL_ADDR, ha,
> +				       dev->addr_len);
>   
>   	/*
>   	 *	build redirect option and copy skb over to the new packet.

Reviewed-by: Stefan Schmidt<stefan@osg.samsung.com>

regards
Stefan Schmidt

^ permalink raw reply

* Re: [PATCHv2 bluetooth-next 07/10] ipv6: introduce neighbour discovery ops
From: Stefan Schmidt @ 2016-05-03 18:17 UTC (permalink / raw)
  To: Hannes Frederic Sowa, Alexander Aring,
	linux-wpan-u79uwXL29TY76Z2rM5mHXA
  Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, marcel-kz+m5ild9QBg9hUCZPvPmw,
	jukka.rissanen-VuQAYsv1563Yd54FQh9/CA, mcr-SWp7JaYWvAQV+D8aMU/kSg,
	werner-SEdMjqphH88wryQfseakQg,
	linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA, David S . Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <fbd4c25c-2673-2848-c636-a5d21a6890d7-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>

Hello.

On 02/05/16 21:36, Hannes Frederic Sowa wrote:
> On 20.04.2016 10:19, Alexander Aring wrote:
>> This patch introduces neighbour discovery ops callback structure. The
>> structure contains at first receive and transmit handling for NS/NA and
>> userspace option field functionality.
>>
>> These callback offers 6lowpan different handling, such as 802.15.4 short
>> address handling or RFC6775 (Neighbor Discovery Optimization for IPv6 over
>> 6LoWPANs).
>>
>> Cc: David S. Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> Cc: Alexey Kuznetsov<kuznet-v/Mj1YrvjDBInbfyfbPRSQ@public.gmane.org>
>> Cc: James Morris<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
>> Cc: Hideaki YOSHIFUJI<yoshfuji-VfPWfsRibaP+Ru+s062T9g@public.gmane.org>
>> Cc: Patrick McHardy<kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
>> Signed-off-by: Alexander Aring<aar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> ---
>>   include/linux/netdevice.h |  3 ++
>>   include/net/ndisc.h       | 96 +++++++++++++++++++++++++++++++++++++++++++----
>>   net/ipv6/addrconf.c       |  1 +
>>   net/ipv6/ndisc.c          | 71 ++++++++++++++++++++++++-----------
>>   net/ipv6/route.c          |  2 +-
>>   5 files changed, 144 insertions(+), 29 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 0052c42..bc60033 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1677,6 +1677,9 @@ struct net_device {
>>   #ifdef CONFIG_NET_L3_MASTER_DEV
>>   	const struct l3mdev_ops	*l3mdev_ops;
>>   #endif
>> +#if IS_ENABLED(CONFIG_IPV6)
>> +	const struct ndisc_ops *ndisc_ops;
>> +#endif
>>   
>>   	const struct header_ops *header_ops;
>>   
>> diff --git a/include/net/ndisc.h b/include/net/ndisc.h
>> index aac868e..14ed016 100644
>> --- a/include/net/ndisc.h
>> +++ b/include/net/ndisc.h
>> @@ -110,7 +110,8 @@ struct ndisc_options {
>>   
>>   #define NDISC_OPT_SPACE(len) (((len)+2+7)&~7)
>>   
>> -struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
>> +struct ndisc_options *ndisc_parse_options(const struct net_device *dev,
>> +					  u8 *opt, int opt_len,
>>   					  struct ndisc_options *ndopts);
>>   
>>   /*
>> @@ -173,6 +174,93 @@ static inline struct neighbour *__ipv6_neigh_lookup(struct net_device *dev, cons
>>   	return n;
>>   }
>>   
>> +static inline int __ip6_ndisc_is_useropt(struct nd_opt_hdr *opt)
>> +{
>> +	return opt->nd_opt_type == ND_OPT_RDNSS ||
>> +		opt->nd_opt_type == ND_OPT_DNSSL;
>> +}
>> +
>> +#if IS_ENABLED(CONFIG_IPV6)
>> +struct ndisc_ops {
>> +	int	(*is_useropt)(struct nd_opt_hdr *opt);
>> +	void	(*send_na)(struct net_device *dev,
>> +			   const struct in6_addr *daddr,
>> +			   const struct in6_addr *solicited_addr,
>> +			   bool router, bool solicited,
>> +			   bool override, bool inc_opt);
>> +	void	(*recv_na)(struct sk_buff *skb);
>> +	void	(*send_ns)(struct net_device *dev,
>> +			   const struct in6_addr *solicit,
>> +			   const struct in6_addr *daddr,
>> +			   const struct in6_addr *saddr);
>> +	void	(*recv_ns)(struct sk_buff *skb);
>> +};
>> +
>> +static inline int ndisc_is_useropt(const struct net_device *dev,
>> +				   struct nd_opt_hdr *opt)
>> +{
>> +	if (likely(dev->ndisc_ops->is_useropt))
>> +		return dev->ndisc_ops->is_useropt(opt);
>> +	else
>> +		return 0;
>> +}
>> +
>> +static inline void ndisc_send_na(struct net_device *dev,
>> +				 const struct in6_addr *daddr,
>> +				 const struct in6_addr *solicited_addr,
>> +				 bool router, bool solicited, bool override,
>> +				 bool inc_opt)
>> +{
>> +	if (likely(dev->ndisc_ops->send_na))
>> +		dev->ndisc_ops->send_na(dev, daddr, solicited_addr, router,
>> +					solicited, override, inc_opt);
>> +}
>> +
>> +static inline void ndisc_recv_na(struct sk_buff *skb)
>> +{
>> +	if (likely(skb->dev->ndisc_ops->recv_na))
>> +		skb->dev->ndisc_ops->recv_na(skb);
>> +}
>> +
>> +static inline void ndisc_send_ns(struct net_device *dev,
>> +				 const struct in6_addr *solicit,
>> +				 const struct in6_addr *daddr,
>> +				 const struct in6_addr *saddr)
>> +{
>> +	if (likely(dev->ndisc_ops->send_ns))
>> +		dev->ndisc_ops->send_ns(dev, solicit, daddr, saddr);
>> +}
>> +
>> +static inline void ndisc_recv_ns(struct sk_buff *skb)
>> +{
>> +	if (likely(skb->dev->ndisc_ops->recv_ns))
>> +		skb->dev->ndisc_ops->recv_ns(skb);
>> +}
>> +#else
>> +static inline int ndisc_is_useropt(const struct net_device *dev,
>> +				   struct nd_opt_hdr *opt)
>> +{
>> +	return 0;
>> +}
>> +
>> +static inline void ndisc_send_na(struct net_device *dev,
>> +				 const struct in6_addr *daddr,
>> +				 const struct in6_addr *solicited_addr,
>> +				 bool router, bool solicited, bool override,
>> +				 bool inc_opt) { }
>> +
>> +static inline void ndisc_recv_na(struct sk_buff *skb) { }
>> +
>> +static inline void ndisc_send_ns(struct net_device *dev,
>> +				 const struct in6_addr *solicit,
>> +				 const struct in6_addr *daddr,
>> +				 const struct in6_addr *saddr) { }
>> +
>> +static inline void ndisc_recv_ns(struct sk_buff *skb) { }
>> +#endif
> Do those empty functions actually make sense? I wonder a bit because
> 6lowpan strictly depends on ipv6 and they should never be called without
> IPv6, no?

Agreed. 6LoWAPN is only an adaptation layer so we know that IPv6 must be 
enabled here. I would also argue for removing this ifdef and the empty 
functions.

regards
Stefan Schmidt

^ permalink raw reply

* [PATCH net-next v2] macvtap: add namespace support to the sysfs device class
From: Marc Angel @ 2016-05-03 18:30 UTC (permalink / raw)
  To: netdev; +Cc: ebiederm
In-Reply-To: <CAPSAET_u3CYvhYgyxXdomi7n5Z6c1DTCpSMv=K544U=TjmM=cw@mail.gmail.com>

When creating macvtaps that are expected to have the same ifindex
in different network namespaces, only the first one will succeed.
The others will fail with a sysfs_warn_dup warning due to them trying
to create the following sysfs link (with 'NN' the ifindex of macvtapX):

/sys/class/macvtap/tapNN -> /sys/devices/virtual/net/macvtapX/tapNN

This is reproducible by running the following commands:

ip netns add ns1
ip netns add ns2
ip link add veth0 type veth peer name veth1
ip link set veth0 netns ns1
ip link set veth1 netns ns2
ip netns exec ns1 ip l add link veth0 macvtap0 type macvtap
ip netns exec ns2 ip l add link veth1 macvtap1 type macvtap

The last command will fail with "RTNETLINK answers: File exists" (along
with the kernel warning) but retrying it will work because the ifindex
was incremented.

The 'net' device class is isolated between network namespaces so each
one has its own hierarchy of net devices.
This isn't the case for the 'macvtap' device class.
The problem occurs half-way through the netdev registration, when
`macvtap_device_event` is called-back to create the 'tapNN' macvtap
class device under the 'macvtapX' net class device.

This patch adds namespace support to the 'macvtap' device class so
that /sys/class/macvtap is no longer shared between net namespaces.

However, making the macvtap sysfs class namespace-aware has the side
effect of changing /sys/devices/virtual/net/macvtapX/tapNN  into
/sys/devices/virtual/net/macvtapX/macvtap/tapNN.

This is due to Commit 24b1442 ("Driver-core: Always create class
directories for classses that support namespaces") and the fact that
class devices supporting namespaces are really not supposed to be placed
directly under other class devices.

To avoid breaking userland, a tapNN symlink pointing to macvtap/tapNN is
created inside the macvtapX directory.

Signed-off-by: Marc Angel <marc@arista.com>
---
 drivers/net/macvtap.c | 35 +++++++++++++++++++++++++----------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..b7ebfcd 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -129,7 +129,18 @@ static DEFINE_MUTEX(minor_lock);
 static DEFINE_IDR(minor_idr);
 
 #define GOODCOPY_LEN 128
-static struct class *macvtap_class;
+static const void *macvtap_net_namespace(struct device *d)
+{
+	struct net_device *dev = to_net_dev(d->parent);
+	return dev_net(dev);
+}
+
+static struct class macvtap_class = {
+	.name = "macvtap",
+	.owner = THIS_MODULE,
+	.ns_type = &net_ns_type_operations,
+	.namespace = macvtap_net_namespace,
+};
 static struct cdev macvtap_cdev;
 
 static const struct proto_ops macvtap_socket_ops;
@@ -1274,6 +1285,7 @@ static int macvtap_device_event(struct notifier_block *unused,
 				unsigned long event, void *ptr)
 {
 	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+	const char *tap_name = kasprintf(GFP_KERNEL, "tap%d", dev->ifindex);
 	struct macvlan_dev *vlan;
 	struct device *classdev;
 	dev_t devt;
@@ -1295,16 +1307,21 @@ static int macvtap_device_event(struct notifier_block *unused,
 			return notifier_from_errno(err);
 
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
-		classdev = device_create(macvtap_class, &dev->dev, devt,
-					 dev, "tap%d", dev->ifindex);
+		classdev = device_create(&macvtap_class, &dev->dev, devt,
+					 dev, tap_name);
 		if (IS_ERR(classdev)) {
 			macvtap_free_minor(vlan);
 			return notifier_from_errno(PTR_ERR(classdev));
 		}
+		err = sysfs_create_link(&dev->dev.kobj, &classdev->kobj,
+					dev_name(classdev));
+		if (err)
+			return notifier_from_errno(err);
 		break;
 	case NETDEV_UNREGISTER:
+		sysfs_remove_link(&dev->dev.kobj, tap_name);
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
-		device_destroy(macvtap_class, devt);
+		device_destroy(&macvtap_class, devt);
 		macvtap_free_minor(vlan);
 		break;
 	}
@@ -1330,11 +1347,9 @@ static int macvtap_init(void)
 	if (err)
 		goto out2;
 
-	macvtap_class = class_create(THIS_MODULE, "macvtap");
-	if (IS_ERR(macvtap_class)) {
-		err = PTR_ERR(macvtap_class);
+	err = class_register(&macvtap_class);
+	if (err)
 		goto out3;
-	}
 
 	err = register_netdevice_notifier(&macvtap_notifier_block);
 	if (err)
@@ -1349,7 +1364,7 @@ static int macvtap_init(void)
 out5:
 	unregister_netdevice_notifier(&macvtap_notifier_block);
 out4:
-	class_unregister(macvtap_class);
+	class_unregister(&macvtap_class);
 out3:
 	cdev_del(&macvtap_cdev);
 out2:
@@ -1363,7 +1378,7 @@ static void macvtap_exit(void)
 {
 	rtnl_link_unregister(&macvtap_link_ops);
 	unregister_netdevice_notifier(&macvtap_notifier_block);
-	class_unregister(macvtap_class);
+	class_unregister(&macvtap_class);
 	cdev_del(&macvtap_cdev);
 	unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
 	idr_destroy(&minor_idr);
-- 
2.8.0

^ permalink raw reply related

* Re: [PATCH v6 00/21] Add HiSilicon RoCE driver
From: Leon Romanovsky @ 2016-05-03 18:48 UTC (permalink / raw)
  To: Lijun Ou
  Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
	jiri, ogerlitz, linux-rdma, linux-kernel, netdev, gongyangming,
	xiaokun, tangchaofei, haifeng.wei, yisen.zhuang, yankejian,
	charles.chenxin, linuxarm
In-Reply-To: <1461845396-61306-1-git-send-email-oulijun@huawei.com>

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

On Thu, Apr 28, 2016 at 08:09:35PM +0800, Lijun Ou wrote:
> The HiSilicon Network Substem is a long term evolution IP which is
> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
> Sybsystem) also has a hardware support of performing RDMA with
> RoCEE.
> The driver for HiSilicon RoCEE(RoCE Engine) is a platform driver and
> will support mulitple versions of SOCs in future. This version of driver
> is meant to support Hip06 SoC(which confirms to RoCEEv1 hardware
> specifications).

Please read Dave's comment [1], it is valuable for your code as
well.

* Please use 'bool' and "true/false"

[1] http://marc.info/?l=linux-rdma&m=146229367301442&w=2

Thanks

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH] pxa168_eth: fix mdiobus_scan() error check
From: David Miller @ 2016-05-03 19:03 UTC (permalink / raw)
  To: sergei.shtylyov; +Cc: netdev, arnd
In-Reply-To: <6024241.YxM8l6DPJo@wasted.cogentembedded.com>

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sat, 30 Apr 2016 23:35:11 +0300

> Since mdiobus_scan() returns either an error code or NULL on error, the
> driver should check  for both,  not only for NULL, otherwise a crash is
> imminent...
> 
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Applied.

^ permalink raw reply

* Re: [PATCH] macb: fix mdiobus_scan() error check
From: David Miller @ 2016-05-03 19:04 UTC (permalink / raw)
  To: sergei.shtylyov; +Cc: netdev, nicolas.ferre
In-Reply-To: <2317306.aZN9iKAKYz@wasted.cogentembedded.com>

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 01 May 2016 01:47:36 +0300

> Now mdiobus_scan() returns ERR_PTR(-ENODEV) instead of NULL if the PHY
> device ID was read as all ones. As this was not  an error before, this
> value  should be filtered out now in this driver.
> 
> Fixes: b74766a0a0fe ("phylib: don't return NULL from get_phy_device()")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
From: Johannes Berg @ 2016-05-03 19:16 UTC (permalink / raw)
  To: Martin Willi
  Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1462258398-6749-3-git-send-email-martin-jzJueiEJWxp8fCCB1iTX4w@public.gmane.org>

On Tue, 2016-05-03 at 08:53 +0200, Martin Willi wrote:
> 
> +static __net_init int hwsim_init_net(struct net *net)
> +{
> +	struct mac80211_hwsim_data *data;
> +	bool exists = true;
> +	int netgroup = 0;
> +
> +	spin_lock_bh(&hwsim_radio_lock);
> +	while (exists) {
> +		exists = false;
> +		list_for_each_entry(data, &hwsim_radios, list) {
> +			if (netgroup == data->netgroup) {
> +				exists = true;
> +				netgroup++;
> +				break;
> +			}
> +		}
> +	}
> +	spin_unlock_bh(&hwsim_radio_lock);
> +
> +	*(int *)net_generic(net, hwsim_net_id) = netgroup;


This seems somewhat awkward. Why not just take the maximum of all the
netgroup IDs + 1? We'd run out of memory and radio IDs long before
netgroup IDs even that way, and they're not actually visible anywhere
so it doesn't matter.

Actually though, *both* your approach and my suggestion don't seem
safe: consider a new netns that doesn't have any hwsim radios yet. Now
you create *another* one, but it would get the same netgroup.

IOW, you should simply use a global counter. Surprising (net)
namespaces don't have an index like that already, but I don't see one.

> +static void __net_exit hwsim_exit_net(struct net *net)
> +{
> +	struct mac80211_hwsim_data *entry, *tmp;
> +
> +	spin_lock_bh(&hwsim_radio_lock);
> +	list_for_each_entry_safe(entry, tmp, &hwsim_radios, list) {
> +		if (net_eq(wiphy_net(entry->hw->wiphy), net)) {
> +			list_del(&entry->list);
> +			INIT_WORK(&entry->destroy_work,
> destroy_radio);
> +			schedule_work(&entry->destroy_work);
> +		}
> +	}
> +	spin_unlock_bh(&hwsim_radio_lock);
> +}

This changes today's default behaviour of moving the wiphys to the
default namespace. Did you intend to destroy them based on the
netgroup, i.e. based on the namespace that created them? Actually,
maybe they should move back to the namespace that created them, if the
namespace they are in is destroyed? But that's difficult, I don't mind
this behaviour, but I'm not sure it's what we want by default for
radios created in the init_net.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [net-next PATCH v2 0/5] stmmac: dwmac-socfpga refactor+cleanup
From: David Miller @ 2016-05-03 19:22 UTC (permalink / raw)
  To: manabian; +Cc: marex, dinguyen, peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <1462136303-16825-1-git-send-email-manabian@gmail.com>

From: Joachim Eastwood <manabian@gmail.com>
Date: Sun,  1 May 2016 22:58:18 +0200

> This patch aims to remove the init/exit callbacks from the dwmac-
> socfpga driver and instead use standard PM callbacks. Doing this
> will also allow us to cleanup the driver.
> 
> Eventually the init/exit callbacks will be deprecated and removed
> from all drivers dwmac-* except for dwmac-generic. Drivers will be
> refactored to use standard PM and remove callbacks.
> 
> This patch set should not change the behavior of the driver itself,
> it only moves code around. The only exception to this is patch
> number 4 which restores the resume callback behavior which was
> changed in the "net: stmmac: socfpga: Remove re-registration of
> reset controller" patch. I belive calling phy_resume() only
> from the resume callback and not probe is the right thing to do.
> 
> Changes from v1:
>  - Rebase on net-next
> 
> One heads-up here:
> The first patch changes the prototype of a couple of
> functions used in Alexandre's "add Ethernet glue logic for
> stm32 chip" patch [1] and will cause build failures for
> dwmac-stm32.c if not fixed up!
> If Alexandre's patch set is applied first I will gladly
> rebase my patch set to account for his driver as well.
> 
> [1] https://patchwork.ozlabs.org/patch/614405/

Series applied, thanks.  stm32 will need to be respun, therefore.

^ permalink raw reply

* Re: [PATCH v2] net: mvneta: Remove superfluous SMP function call
From: David Miller @ 2016-05-03 19:28 UTC (permalink / raw)
  To: anna-maria; +Cc: linux-kernel, rt, thomas.petazzoni, netdev
In-Reply-To: <1462179771-55875-1-git-send-email-anna-maria@linutronix.de>

From: Anna-Maria Gleixner <anna-maria@linutronix.de>
Date: Mon,  2 May 2016 11:02:51 +0200

> Since commit 3b9d6da67e11 ("cpu/hotplug: Fix rollback during error-out
> in __cpu_disable()") it is ensured that callbacks of CPU_ONLINE and
> CPU_DOWN_PREPARE are processed on the hotplugged CPU. Due to this SMP
> function calls are no longer required.
> 
> Replace smp_call_function_single() with a direct call to
> mvneta_percpu_enable() or mvneta_percpu_disable(). The functions do
> not require to be called with interrupts disabled, therefore the
> smp_call_function_single() calling convention is not preserved.
> 
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>

Applied, thanks.

^ permalink raw reply

* Re: Cannot use NFS with linux-next 20160429
From: Fabio Estevam @ 2016-05-03 19:37 UTC (permalink / raw)
  To: Chuck Lever
  Cc: Trond Myklebust, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux NFS Mailing List
In-Reply-To: <13CA7D80-3F3D-4D92-9E52-1434BD8047DE-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

Hi Chuck,

On Sun, May 1, 2016 at 4:52 PM, Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> Hi Fabio-
>
>> On Apr 29, 2016, at 7:18 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Hi,
>>
>> NFS is not working on a imx6q-sabresd board running linux-next 20160429:
>>
>> [   15.753317]   #0: wm8962-audio
>> [   15.759437] Root-NFS: no NFS server address
>
> At a glance, that looks like the NFSROOT mount options are
> invalid? First, confirm what is specified on the kernel
> cmdline.

Yes, the kernel command line is correct.

>
> I'm not aware of any recent changes to NFSROOT. Often
> these NFSROOT problems turn out to be related to churn in
> the underlying Ethernet drivers or the generic code that
> handles mounting the root filesystem at boot time.

Today's next shows some different info:

[    7.606456]   #0: wm8962-audio
[    7.672659] VFS: Mounted root (nfs filesystem) readonly on device 0:14.
[    7.680860] devtmpfs: mounted
[    7.685664] Freeing unused kernel memory: 1024K (c0c00000 - c0d00000)
[    7.871481]
[    7.873004] =================================
[    7.877381] [ INFO: inconsistent lock state ]
[    7.881760] 4.6.0-rc6-next-20160503-00002-g51d9962 #351 Not tainted
[    7.888043] ---------------------------------
[    7.892419] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[    7.898449] kworker/0:1H/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
[    7.904040]  (&syncp->seq#5){+.?...}, at: [<c0752328>] tcp_ack+0x134/0x129c
[    7.911166] {IN-SOFTIRQ-W} state was registered at:
[    7.916061]   [<c016cc68>] lock_acquire+0x78/0x98
[    7.920816]   [<c074ccbc>] tcp_snd_una_update+0x64/0xa8
[    7.926092]   [<c0752328>] tcp_ack+0x134/0x129c
[    7.930668]   [<c0755de8>] tcp_rcv_state_process+0x814/0xfc8
[    7.936375]   [<c075e800>] tcp_v4_do_rcv+0x64/0x1c8
[    7.941305]   [<c07616c8>] tcp_v4_rcv+0xf00/0xfbc
[    7.946057]   [<c07374cc>] ip_local_deliver_finish+0xd4/0x550
[    7.951859]   [<c0737bc4>] ip_local_deliver+0xcc/0xdc
[    7.956957]   [<c0736d78>] ip_rcv_finish+0xc4/0x744
[    7.961881]   [<c073809c>] ip_rcv+0x4c8/0x7a8
[    7.966284]   [<c06fa448>] __netif_receive_skb_core+0x514/0x8ec
[    7.972251]   [<c06ff854>] __netif_receive_skb+0x2c/0x8c
[    7.977614]   [<c06ffb50>] netif_receive_skb_internal+0x7c/0x1f0
[    7.983666]   [<c0700e38>] napi_gro_receive+0x88/0xdc
[    7.988764]   [<c058fb4c>] fec_enet_rx_napi+0x390/0x9c8
[    7.994036]   [<c0700724>] net_rx_action+0x148/0x344
[    7.999046]   [<c012996c>] __do_softirq+0x130/0x2bc
[    8.003976]   [<c0129e40>] irq_exit+0xc4/0x138
[    8.008466]   [<c0177920>] __handle_domain_irq+0x74/0xe4
[    8.013838]   [<c01015d8>] gic_handle_irq+0x4c/0x9c
[    8.018763]   [<c010c4b8>] __irq_svc+0x58/0x78
[    8.023251]   [<c08f7db8>] _raw_spin_unlock_irq+0x30/0x34
[    8.028710]   [<c014a03c>] finish_task_switch+0xcc/0x274
[    8.034072]   [<c08f2728>] __schedule+0x23c/0x6f8
[    8.038823]   [<c08f2d0c>] schedule+0x3c/0xa0
[    8.043224]   [<c08f2f74>] schedule_preempt_disabled+0x10/0x14
[    8.049103]   [<c01663b0>] cpu_startup_entry+0x1f4/0x24c
[    8.054468]   [<c08f070c>] rest_init+0x12c/0x16c
[    8.059130]   [<c0c00cbc>] start_kernel+0x340/0x3b0
[    8.064059]   [<1000807c>] 0x1000807c
[    8.067767] irq event stamp: 3601
[    8.071099] hardirqs last  enabled at (3601): [<c08f7d74>]
_raw_spin_unlock_irqrestore+0x38/0x4c
[    8.079936] hardirqs last disabled at (3600): [<c08f7728>]
_raw_spin_lock_irqsave+0x24/0x54
[    8.088336] softirqs last  enabled at (3598): [<c06e9754>]
__release_sock+0x3c/0x124
[    8.096128] softirqs last disabled at (3596): [<c06e985c>]
release_sock+0x20/0xa4
[    8.103654]
[    8.103654] other info that might help us debug this:
[    8.110202]  Possible unsafe locking scenario:
[    8.110202]
[    8.116140]        CPU0
[    8.118601]        ----
[    8.121062]   lock(&syncp->seq#5);
[    8.124547]   <Interrupt>
[    8.127182]     lock(&syncp->seq#5);
[    8.130838]
[    8.130838]  *** DEADLOCK ***
[    8.130838]
[    8.136785] 3 locks held by kworker/0:1H/179:
[    8.141157]  #0:  ("rpciod"){.+.+.+}, at: [<c013e478>]
process_one_work+0x128/0x410
[    8.148965]  #1:  ((&task->u.tk_work)){+.+.+.}, at: [<c013e478>]
process_one_work+0x128/0x410
[    8.157630]  #2:  (sk_lock-AF_INET-RPC){+.+...}, at: [<c074af70>]
tcp_sendmsg+0x24/0xb5c
[    8.165859]
[    8.165859] stack backtrace:
[    8.170247] CPU: 0 PID: 179 Comm: kworker/0:1H Not tainted
4.6.0-rc6-next-20160503-00002-g51d9962 #351
[    8.179572] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[    8.186137] Workqueue: rpciod rpc_async_schedule
[    8.190791] Backtrace:
[    8.193307] [<c010b6f8>] (dump_backtrace) from [<c010b894>]
(show_stack+0x18/0x1c)
[    8.200894]  r6:60000193 r5:ffffffff r4:00000000 r3:eebdc800
[    8.206692] [<c010b87c>] (show_stack) from [<c03dfbf4>]
(dump_stack+0xb0/0xe8)
[    8.213961] [<c03dfb44>] (dump_stack) from [<c01c72d4>]
(print_usage_bug+0x268/0x2dc)
[    8.221809]  r8:00000004 r7:eebdcd00 r6:eebdc800 r5:c0ae4bbc
r4:c0ec6054 r3:eebdc800
[    8.229712] [<c01c706c>] (print_usage_bug) from [<c016ace0>]
(mark_lock+0x29c/0x6b0)
[    8.237472]  r10:c016a1c8 r8:00000004 r7:eebdc800 r6:00001054
r5:eebdcd00 r4:00000006
[    8.245456] [<c016aa44>] (mark_lock) from [<c016b644>]
(__lock_acquire+0x550/0x17c8)
[    8.253216]  r10:c0d21d9c r9:000002be r8:c0e97784 r7:eebdc800
r6:c153a09c r5:eebdcd00
[    8.261188]  r4:00000003 r3:00000001
[    8.264837] [<c016b0f4>] (__lock_acquire) from [<c016cc68>]
(lock_acquire+0x78/0x98)
[    8.272598]  r10:00000001 r9:c0752328 r8:2d738f6b r7:00000001
r6:c0752328 r5:60000113
[    8.280568]  r4:00000000
[    8.283155] [<c016cbf0>] (lock_acquire) from [<c074ccbc>]
(tcp_snd_una_update+0x64/0xa8)
[    8.291261]  r7:00000000 r6:ee6b9500 r5:ee6b9500 r4:ee6b99cc
[    8.297050] [<c074cc58>] (tcp_snd_una_update) from [<c0752328>]
(tcp_ack+0x134/0x129c)
[    8.304984]  r10:ee6b9570 r9:ee42f9c0 r8:2d738f6b r7:c0d02100
r6:00000002 r5:ee6b9500
[    8.312956]  r4:00000002
[    8.315542] [<c07521f4>] (tcp_ack) from [<c0754c08>]
(tcp_rcv_established+0x140/0x774)
[    8.323477]  r10:ee6b9570 r9:ee42f9c0 r8:c0d6bfb3 r7:c155a080
r6:ee6e9a62 r5:ee42f9c0
[    8.331448]  r4:ee6b9500
[    8.334039] [<c0754ac8>] (tcp_rcv_established) from [<c075e8fc>]
(tcp_v4_do_rcv+0x160/0x1c8)
[    8.342494]  r8:c0d6bfb3 r7:c155a080 r6:eea79600 r5:ee6b9500 r4:ee42f9c0
[    8.349348] [<c075e79c>] (tcp_v4_do_rcv) from [<c06e97ac>]
(__release_sock+0x94/0x124)
[    8.357281]  r6:00000000 r5:ee6b9500 r4:00000000 r3:c075e79c
[    8.363065] [<c06e9718>] (__release_sock) from [<c06e9870>]
(release_sock+0x34/0xa4)
[    8.370825]  r10:ee6b9500 r9:ee6c1ce4 r8:00000000 r7:00000080
r6:c074b1f0 r5:ee6b9570
[    8.378797]  r4:ee6b9500 r3:ee42f9c0
[    8.382448] [<c06e983c>] (release_sock) from [<c074b1f0>]
(tcp_sendmsg+0x2a4/0xb5c)
[    8.390122]  r6:00000080 r5:ee6b9500 r4:ee6c2000 r3:00000015
[    8.395922] [<c074af4c>] (tcp_sendmsg) from [<c077a824>]
(inet_sendmsg+0x128/0x200)
[    8.403596]  r10:c0d6c136 r9:ee6a4000 r8:ee6c1ce4 r7:00000080
r6:00000000 r5:c0d6c136
[    8.411565]  r4:ee6b9500
[    8.414161] [<c077a6fc>] (inet_sendmsg) from [<c06e41ec>]
(sock_sendmsg+0x1c/0x2c)
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 net-next 1/1] qed: Apply tunnel configurations after PF start
From: David Miller @ 2016-05-03 19:48 UTC (permalink / raw)
  To: manish.chopra; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <1462184164-22650-1-git-send-email-manish.chopra@qlogic.com>

From: Manish Chopra <manish.chopra@qlogic.com>
Date: Mon, 2 May 2016 06:16:04 -0400

> Configure and enable various tunnels on the
> adapter after PF start.
> 
> This change was missed as a part of
> 'commit 464f664501816ef5fbbc00b8de96f4ae5a1c9325
> ("qed: Add infrastructure support for tunneling")'
> 
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
> Signed-off-by: Yuval Mintz <yuval.mintz@qlogic.com>

Applied.

^ permalink raw reply

* Re: [PATCH 1/3] brcm80211: correct speed testing
From: David Miller @ 2016-05-03 19:49 UTC (permalink / raw)
  To: oneukum; +Cc: linux-usb, netdev
In-Reply-To: <1462187174-17180-1-git-send-email-oneukum@suse.com>

From: Oliver Neukum <oneukum@suse.com>
Date: Mon,  2 May 2016 13:06:12 +0200

> Allow for SS+ USB
> 
> Signed-off-by: Oliver Neukum <ONeukum@suse.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/3] usbnet: correct speed testing
From: David Miller @ 2016-05-03 19:49 UTC (permalink / raw)
  To: oneukum; +Cc: linux-usb, netdev
In-Reply-To: <1462187174-17180-2-git-send-email-oneukum@suse.com>

From: Oliver Neukum <oneukum@suse.com>
Date: Mon,  2 May 2016 13:06:13 +0200

> Allow for SS+ USB
> 
> Signed-off-by: Oliver Neukum <ONeukum@suse.com>

Applied.

^ permalink raw reply

* Re: [PATCH 3/3] rtl8152: correct speed testing
From: David Miller @ 2016-05-03 19:49 UTC (permalink / raw)
  To: oneukum-IBi9RG/b67k
  Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1462187174-17180-3-git-send-email-oneukum-IBi9RG/b67k@public.gmane.org>

From: Oliver Neukum <oneukum-IBi9RG/b67k@public.gmane.org>
Date: Mon,  2 May 2016 13:06:14 +0200

> Allow for SS+ USB
> 
> Signed-off-by: Oliver Neukum <ONeukum-IBi9RG/b67k@public.gmane.org>

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

^ permalink raw reply

* Re: [PATCH net-next 0/3] tipc: redesign socket-level flow control
From: David Miller @ 2016-05-03 19:51 UTC (permalink / raw)
  To: jon.maloy
  Cc: netdev, paul.gortmaker, parthasarathy.bhuvaragan, richard.alpe,
	ying.xue, maloy, tipc-discussion
In-Reply-To: <1462198956-30181-1-git-send-email-jon.maloy@ericsson.com>

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon,  2 May 2016 10:22:33 -0400

> The socket-level flow control in TIPC has long been due for a major
> overhaul. This series fixes this.

Series applied, thanks Jon.

^ permalink raw reply

* Re: [net PATCH 0/2] Fixes for tunnel checksum and segmentation offloads
From: David Miller @ 2016-05-03 20:01 UTC (permalink / raw)
  To: aduyck; +Cc: netdev, ogerlitz, alexander.duyck
In-Reply-To: <20160502161621.11701.9271.stgit@ahduyck-xeon-server>

From: Alexander Duyck <aduyck@mirantis.com>
Date: Mon, 02 May 2016 09:25:04 -0700

> This patch series is a subset of patches I had submitted for net-next.  I
> plan to drop these two patches from the v3 of "Fix Tunnel features and
> enable GSO partial for several drivers" and I am instead submitting them
> for net since these are truly fixes and likely will need to be backported
> to stable branches.
> 
> This series addresses 2 specific issues.  The first is that we could
> request TSO on a v4 inner header while not supporting checksum offload of
> the outer IPv6 header.  The second is that we could request an IPv6 inner
> checksum offload without validating that we could actually support an inner
> IPv6 checksum offload.

Series applied, thanks.

^ permalink raw reply

* Re: [net-next PATCH v3 0/8] Fix Tunnel features and enable GSO partial for several drivers
From: David Miller @ 2016-05-03 20:01 UTC (permalink / raw)
  To: aduyck; +Cc: talal, netdev, michael.chan, alexander.duyck, galp, ogerlitz,
	eranbe
In-Reply-To: <20160502162828.11809.92444.stgit@ahduyck-xeon-server>

From: Alexander Duyck <aduyck@mirantis.com>
Date: Mon, 02 May 2016 09:38:06 -0700

> v3: Moved 2 patches into series for net as they were generic fixes.
>     Added patch to disable GSO partial if frame is less than 2x size of MSS

I'll therefore apply this series after my next net --> net-next merge.

Thanks.

^ permalink raw reply

* Re: [PATCH net-next] net: add __sock_wfree() helper
From: David Miller @ 2016-05-03 20:02 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1462211787.5535.269.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 May 2016 10:56:27 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> Hosts sending lot of ACK packets exhibit high sock_wfree() cost
> because of cache line miss to test SOCK_USE_WRITE_QUEUE
> 
> We could move this flag close to sk_wmem_alloc but it is better
> to perform the atomic_sub_and_test() on a clean cache line,
> as it avoid one extra bus transaction.
> 
> skb_orphan_partial() can also have a fast track for packets that either
> are TCP acks, or already went through another skb_orphan_partial()
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net v2 0/2] RDS: TCP: sychronization during connection startup
From: David Miller @ 2016-05-03 20:05 UTC (permalink / raw)
  To: sowmini.varadhan; +Cc: netdev, rds-devel, santosh.shilimkar
In-Reply-To: <cover.1462212462.git.sowmini.varadhan@oracle.com>

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Mon,  2 May 2016 11:24:50 -0700

> This patch series ensures that the passive (accept) side of the
> TCP connection used for RDS-TCP is correctly synchronized with
> any concurrent active (connect) attempts for a given pair of peers.
> 
> Patch 1 in the series makes sure that the t_sock in struct 
> rds_tcp_connection is only reset after any threads in rds_tcp_xmit
> have completed (otherwise a null-ptr deref may be encountered). 
> Patch 2 synchronizes rds_tcp_accept_one() with the rds_tcp*connect()
> path.
> 
> v2: review comments from Santosh Shilimkar, other spelling corrections

Series applied, thanks.

^ permalink raw reply

* Re: [PATCH net] net: macb: Probe MDIO bus before registering netdev
From: David Miller @ 2016-05-03 20:06 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, nicolas.ferre
In-Reply-To: <1462239525-22723-1-git-send-email-f.fainelli@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon,  2 May 2016 18:38:45 -0700

> The current sequence makes us register for a network device prior to
> registering and probing the MDIO bus which could lead to some unwanted
> consequences, like a thread of execution calling into ndo_open before
> register_netdev() returns, while the MDIO bus is not ready yet.
> 
> Rework the sequence to register for the MDIO bus, and therefore attach
> to a PHY prior to calling register_netdev(), which implies reworking the
> error path a bit.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Applied, thanks Florian.

^ permalink raw reply

* Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd
From: David Miller @ 2016-05-03 20:07 UTC (permalink / raw)
  To: marcel-kz+m5ild9QBg9hUCZPvPmw
  Cc: hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
	aar-bIcnvbaLZ9MEGnE8C9+IrQ, linux-wpan-u79uwXL29TY76Z2rM5mHXA,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
	jukka.rissanen-VuQAYsv1563Yd54FQh9/CA,
	stefan-JPH+aEBZ4P+UEJcrhfAQsw, mcr-SWp7JaYWvAQV+D8aMU/kSg,
	werner-SEdMjqphH88wryQfseakQg,
	linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA, kuznet-v/Mj1YrvjDBInbfyfbPRSQ,
	jmorris-gx6/JNMH7DfYtjvyW6yDsg, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
	kaber-dcUjhNyLwpNeoWH0uzbU5w
In-Reply-To: <58926844-0338-4D63-A5B6-DB0EBE903A0E-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>

From: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Date: Mon, 2 May 2016 16:17:41 -0700

>> My proposal would be that the IPv6 patches go via net-next to reduce
>> merge conflicts with maybe upcoming changes. If they are split up, they
>> seem very much self contained and easy to review. The rest seems to be
>> also very much self contained and can go in via bluetooth-next, then.
>> What do you think?
>
> I am actually fine with having this all go via net-next. We only
> have driver patches pending in bluetooth-next for the next merge
> window. Which means I can just pull net-next back into
> bluetooth-next at any time.

Ok, just resubmit the series explicitly targetting net-next then.

Thanks.

^ permalink raw reply

* [PATCH] mdio_bus: don't return NULL from mdiobus_scan()
From: Sergei Shtylyov @ 2016-05-03 20:14 UTC (permalink / raw)
  To: netdev, f.fainelli

I've finally noticed that mdiobus_scan() also returns either NULL or error
value on failure.  Return ERR_PTR(-ENODEV) instead of NULL since this is
the  error value  already filtered out by the callers that want to ignore
the  MDIO address scan failure...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
The patch is against DaveM's 'net-next.git' repo.

 drivers/net/phy/mdio_bus.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: net-next/drivers/net/phy/mdio_bus.c
===================================================================
--- net-next.orig/drivers/net/phy/mdio_bus.c
+++ net-next/drivers/net/phy/mdio_bus.c
@@ -435,7 +435,7 @@ struct phy_device *mdiobus_scan(struct m
 	err = phy_device_register(phydev);
 	if (err) {
 		phy_device_free(phydev);
-		return NULL;
+		return ERR_PTR(-ENODEV);
 	}
 
 	return phydev;

^ permalink raw reply

* [PATCH net] bridge: fix igmp / mld query parsing
From: Linus Lüssing @ 2016-05-03 20:18 UTC (permalink / raw)
  To: netdev; +Cc: Simon Wunderlich, bridge, linux-kernel, David S . Miller

With the newly introduced helper functions the skb pulling is hidden
in the checksumming function - and undone before returning to the
caller.

The IGMP and MLD query parsing functions in the bridge still
assumed that the skb is pointing to the beginning of the IGMP/MLD
message while it is now kept at the beginning of the IPv4/6 header.

If there is a querier somewhere else, then this either causes
the multicast snooping to stay disabled even though it could be
enabled. Or, if we have the querier enabled too, then this can
create unnecessary IGMP / MLD query messages on the link.

Fixing this by taking the offset between IP and IGMP/MLD header into
account, too.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
---
 net/bridge/br_multicast.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 03661d9..7105cdf 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1271,6 +1271,7 @@ static int br_ip4_multicast_query(struct net_bridge *br,
 	unsigned long max_delay;
 	unsigned long now = jiffies;
 	__be32 group;
+	int offset = skb_transport_offset(skb);
 	int err = 0;
 
 	spin_lock(&br->multicast_lock);
@@ -1280,14 +1281,14 @@ static int br_ip4_multicast_query(struct net_bridge *br,
 
 	group = ih->group;
 
-	if (skb->len == sizeof(*ih)) {
+	if (skb->len == offset + sizeof(*ih)) {
 		max_delay = ih->code * (HZ / IGMP_TIMER_SCALE);
 
 		if (!max_delay) {
 			max_delay = 10 * HZ;
 			group = 0;
 		}
-	} else if (skb->len >= sizeof(*ih3)) {
+	} else if (skb->len >= offset + sizeof(*ih3)) {
 		ih3 = igmpv3_query_hdr(skb);
 		if (ih3->nsrcs)
 			goto out;
@@ -1350,6 +1351,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
 	unsigned long now = jiffies;
 	const struct in6_addr *group = NULL;
 	bool is_general_query;
+	int offset = skb_transport_offset(skb);
 	int err = 0;
 
 	spin_lock(&br->multicast_lock);
@@ -1357,8 +1359,8 @@ static int br_ip6_multicast_query(struct net_bridge *br,
 	    (port && port->state == BR_STATE_DISABLED))
 		goto out;
 
-	if (skb->len == sizeof(*mld)) {
-		if (!pskb_may_pull(skb, sizeof(*mld))) {
+	if (skb->len == offset + sizeof(*mld)) {
+		if (!pskb_may_pull(skb, offset + sizeof(*mld))) {
 			err = -EINVAL;
 			goto out;
 		}
@@ -1367,7 +1369,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
 		if (max_delay)
 			group = &mld->mld_mca;
 	} else {
-		if (!pskb_may_pull(skb, sizeof(*mld2q))) {
+		if (!pskb_may_pull(skb, offset + sizeof(*mld2q))) {
 			err = -EINVAL;
 			goto out;
 		}
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH net-next v2] ipv6: add new struct ipcm6_cookie
From: David Miller @ 2016-05-03 20:20 UTC (permalink / raw)
  To: weiwan; +Cc: netdev
In-Reply-To: <1462250407-19496-1-git-send-email-tracywwnj@gmail.com>

From: Wei Wang <weiwan@google.com>
Date: Mon,  2 May 2016 21:40:07 -0700

> From: Wei Wang <weiwan@google.com>
> 
> In the sendmsg function of UDP, raw, ICMP and l2tp sockets, we use local
> variables like hlimits, tclass, opt and dontfrag and pass them to corresponding
> functions like ip6_make_skb, ip6_append_data and xxx_push_pending_frames.
> This is not a good practice and makes it hard to add new parameters.
> This fix introduces a new struct ipcm6_cookie similar to ipcm_cookie in
> ipv4 and include the above mentioned variables. And we only pass the
> pointer to this structure to corresponding functions. This makes it easier
> to add new parameters in the future and makes the function cleaner.
> 
> Signed-off-by: Wei Wang <weiwan@google.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] tcp: guarantee forward progress in tcp_sendmsg()
From: David Miller @ 2016-05-03 20:20 UTC (permalink / raw)
  To: eric.dumazet; +Cc: edumazet, netdev, soheil, ast, marcelo.leitner
In-Reply-To: <1462250965.5535.286.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 02 May 2016 21:49:25 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> Under high rx pressure, it is possible tcp_sendmsg() never has a
> chance to allocate an skb and loop forever as sk_flush_backlog()
> would always return true.
> 
> Fix this by calling sk_flush_backlog() only if one skb had been
> allocated and filled before last backlog check.
> 
> Fixes: d41a69f1d390 ("tcp: make tcp_sendmsg() aware of socket backlog")
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ 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