Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 14:33 UTC (permalink / raw)
  To: Antoine Tenart
  Cc: sebastian.hesselbarth, alexandre.belloni, thomas.petazzoni, zmxu,
	jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20140923140113.GC18924@kwain>

On Tuesday 23 September 2014 16:01:13 Antoine Tenart wrote:
> 
> On Tue, Sep 23, 2014 at 02:38:39PM +0200, Arnd Bergmann wrote:
> > On Tuesday 23 September 2014 14:15:30 Antoine Tenart wrote:
> > > +Optional properties:
> > > +- port-id: should be '0','1' or '2'.
> > > +- phy-addr: MDIO address of the PHY.
> > > +- local-mac-address: see ethernet.txt file in the same directory.
> > > +
> > > 
> > 
> > I believe new bindings should not use "phy-addr" properties, but
> > instead use a phy-handle property pointing to a phy device instead.
> 
> That's the MDIO address of the PHY. It's a bit difficult to use a phy
> device as the driver uses the libphy. And that would break the platform
> using it.
> 
> Or maybe you have something in mind?

I don't understand what you mean. Doesn't libphy imply using a phy_device?
What I meant was that you should be able to just call the standard
of_phy_connect() and other interfaces to deal with phylib.

	Arnd

^ permalink raw reply

* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Seth Forshee @ 2014-09-23 14:31 UTC (permalink / raw)
  To: Michael Tokarev
  Cc: Arend van Spriel, brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <542183A6.4070207@msgid.tls.msk.ru>

On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote:
> 23.09.2014 18:25, Michael Tokarev wrote:
> > 23.09.2014 17:50, Arend van Spriel wrote:
> >> On 09/23/14 15:44, Seth Forshee wrote:
> []
> >>> It's been quite some time since I used them, but I think brcmsmac_tx is
> >>> quite noisy so you may only want to enable that if you already suspect a
> >>> tx problem. I always find it useful to enable the mac80211 and
> >>> mac80211_msg events too when debugging wireless, and I often enable
> >>> cfg80211 events as well (none of these are especially verbose).
> 
> mac80211_msg does not exist, it looks like.  fwiw.

Did you check your kernel's config? You need to have
CONFIG_MAC80211_MESSAGE_TRACING enabled.

Seth

^ permalink raw reply

* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Antoine Tenart @ 2014-09-23 14:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: thomas.petazzoni, zmxu, devicetree, netdev, Antoine Tenart,
	linux-kernel, alexandre.belloni, jszhang, linux-arm-kernel,
	sebastian.hesselbarth
In-Reply-To: <20140923140113.GC18924@kwain>

On Tue, Sep 23, 2014 at 04:01:13PM +0200, Antoine Tenart wrote:
> Arnd,
> 
> On Tue, Sep 23, 2014 at 02:38:39PM +0200, Arnd Bergmann wrote:
> > On Tuesday 23 September 2014 14:15:30 Antoine Tenart wrote:
> > > +Optional properties:
> > > +- port-id: should be '0','1' or '2'.
> > > +- phy-addr: MDIO address of the PHY.
> > > +- local-mac-address: see ethernet.txt file in the same directory.
> > > +
> > > 
> > 
> > I believe new bindings should not use "phy-addr" properties, but
> > instead use a phy-handle property pointing to a phy device instead.
> 

So I had a look on other Ethernet bindings. Would you agree with
something like the following?

	eth0: ethernet@f7b90000 {
		...
		#address-cells = <1>;
		#size-cells = <0>;
		phy-handle = <&ethphy0>;

		ethphy0: ethernet-phy@0 {
			reg = <0>;
		};
	};

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-09-23 14:28 UTC (permalink / raw)
  To: Arend van Spriel, Seth Forshee; +Cc: brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <542182BE.2000606@msgid.tls.msk.ru>

23.09.2014 18:25, Michael Tokarev wrote:
> 23.09.2014 17:50, Arend van Spriel wrote:
>> On 09/23/14 15:44, Seth Forshee wrote:
[]
>>> It's been quite some time since I used them, but I think brcmsmac_tx is
>>> quite noisy so you may only want to enable that if you already suspect a
>>> tx problem. I always find it useful to enable the mac80211 and
>>> mac80211_msg events too when debugging wireless, and I often enable
>>> cfg80211 events as well (none of these are especially verbose).

mac80211_msg does not exist, it looks like.  fwiw.

/mjt

^ permalink raw reply

* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-09-23 14:25 UTC (permalink / raw)
  To: Arend van Spriel, Seth Forshee; +Cc: brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <54217AA5.2060803@broadcom.com>

23.09.2014 17:50, Arend van Spriel wrote:
> On 09/23/14 15:44, Seth Forshee wrote:
[]
>> Well, there are a few different trace events defined for brcmsmac. This
>> would enable the full set:
>>
>>   $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg
>>
>> It's been quite some time since I used them, but I think brcmsmac_tx is
>> quite noisy so you may only want to enable that if you already suspect a
>> tx problem. I always find it useful to enable the mac80211 and
>> mac80211_msg events too when debugging wireless, and I often enable
>> cfg80211 events as well (none of these are especially verbose).
> 
> Ah, I read back the email from Sep 21 and it says:
> 
> trace-cmd record brcmsmac:* &
> 
> I am surprised the capture contains something as -e is missing. Good to know there are different tracers for the driver.
> 
>> Of course all of this depends on having the right config options
>> selected. Looks like the relevant options are CONFIG_BRCM_TRACING and
>> CONFIG_MAC80211_MESSAGE_TRACING.

So, what should I enable?  I guess there's a suspection of tx path
problem (since according to tcpdump, the other side sends packets
our way, but our side does not receive them), so -e brcmsmac_tx
shold be okay to enable (and should be easy to filter out if
needed, too, I guess).  And using -e, now too, like this:

 trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg -e mac80211 -e mac80211 -e cfg80211

http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409232.dat.gz is
the result from the following:

 modprobe brcmsmac (networkmanager is running)
 trace-cmd as above &
 wget http://ip-add-ress/random-file -O /dev/null

I waited for wget to stall (it d'loaded 240Kb) and hit
Ctrl+C.

The trace file isn't really that huge.

Thank you!

/mjt

^ permalink raw reply

* LTP recv/recvmsg tests failing on 3.17
From: Chuck Ebbert @ 2014-09-23 14:11 UTC (permalink / raw)
  To: Willem de Bruijn; +Cc: netdev

LTP tests recv01, recvfrom01 and recvmsg01 are reporting failure on
their "invalid flags" tests on 3.17. They pass a value of -1 for flags
and expect to get EINVAL back, but now they get EAGAIN. It looks like
this is due to:

commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Aug 4 22:11:49 2014 -0400

    net-timestamp: TCP timestamping

which adds this hunk to net/ipv4/tcp.c:

@@ -1617,6 +1630,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
        struct sk_buff *skb;
        u32 urg_hole = 0;
 
+       if (unlikely(flags & MSG_ERRQUEUE))
+               return ip_recv_error(sk, msg, len, addr_len);
+
        if (sk_can_busy_loop(sk) && skb_queue_empty(&sk->sk_receive_queue) &&
            (sk->sk_state == TCP_ESTABLISHED))
                sk_busy_loop(sk, nonblock);

Before this change, the first flag tested was MSG_OOB, which eventually
causes EINVAL to be returned. Now this flag gets tested first, and
ip_recv_err() returns EAGAIN.

LTP setting every flag and expecting behavior to remain unchanged is
probably wrong, but is EAGAIN correct here? I can't find any spec for
this.

^ permalink raw reply

* Re: [PATCH] ath: change logging functions to return void
From: Vladimir Kondratiev @ 2014-09-23 14:05 UTC (permalink / raw)
  To: Joe Perches
  Cc: Kalle Valo, John W. Linville, ath10k, linux-wireless, netdev,
	linux-kernel, wil6210
In-Reply-To: <1411407334.2952.46.camel@joe-AO725>

On Monday, September 22, 2014 10:35:34 AM Joe Perches wrote:
> Other miscellanea:
> 
> o add __printf verification to wil6210 logging functions
>   No format/argument mismatches found
> 
> Signed-off-by: Joe Perches <joe@perches.com>
> 

For wil6210:

Acked-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>

^ permalink raw reply

* Re: [PATCH v4 0/9] ARM: Berlin: Ethernet support
From: Antoine Tenart @ 2014-09-23 14:01 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel, Antoine Tenart, sebastian.hesselbarth,
	thomas.petazzoni, zmxu, devicetree, netdev, linux-kernel,
	alexandre.belloni, jszhang
In-Reply-To: <3200502.7xjfrZcKCM@wuerfel>

On Tue, Sep 23, 2014 at 02:41:47PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 14:15:27 Antoine Tenart wrote:
> > 
> > This series introduce support for the Ethernet controller on Berlin SoCs,
> > using the existing pxa168 Ethernet driver. In order to do this, DT
> > support is added to the driver alongside some other modifications and
> > fixes.
> > 
> 
> Looks great overall, I've commented on two issues I've found, but only
> the phy-addr one really needs to be addressed. Once that is out of the
> way, please add
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks!

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Antoine Tenart @ 2014-09-23 14:01 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Antoine Tenart, sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w,
	alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
	thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
	zmxu-eYqpPyKDWXRBDgjK7y7TUQ, jszhang-eYqpPyKDWXRBDgjK7y7TUQ,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <51745791.Wuu5QiQB2e@wuerfel>

Arnd,

On Tue, Sep 23, 2014 at 02:38:39PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 14:15:30 Antoine Tenart wrote:
> > +Optional properties:
> > +- port-id: should be '0','1' or '2'.
> > +- phy-addr: MDIO address of the PHY.
> > +- local-mac-address: see ethernet.txt file in the same directory.
> > +
> > 
> 
> I believe new bindings should not use "phy-addr" properties, but
> instead use a phy-handle property pointing to a phy device instead.

That's the MDIO address of the PHY. It's a bit difficult to use a phy
device as the driver uses the libphy. And that would break the platform
using it.

Or maybe you have something in mind?

> 
> The port-id property description could be a little more verbose.
> What do those numbers actually mean?

I'll add some description. That's the Ethernet port number. I reused a
property (port-id) already used by other drivers.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-09-23 13:50 UTC (permalink / raw)
  To: Seth Forshee
  Cc: Michael Tokarev, brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140923134419.GA19016@ubuntu-hedt>

On 09/23/14 15:44, Seth Forshee wrote:
> On Tue, Sep 23, 2014 at 02:47:45PM +0200, Arend van Spriel wrote:
>> On 09/23/14 12:04, Michael Tokarev wrote:
>>> 21.09.2014 19:30, Michael Tokarev wrote:
>>>> Namely, after resume, the card does not work. ARP works, ping and
>>>> DNS sometimes/somewhat work, inital TCP connection establisment
>>>> works, but eg http download does not work, it stalls almost
>>>> immediately.
>>>
>>> It does not work at all anymore again.  Not only after resume but also
>>> after could power up, it stalls right at start of wget for example.
>>>
>>>> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this
>>>> is a trace collected after resuming from suspend-to-disk
>>>
>>> And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz
>>> is another trace, after insmod brcmutils&   brcmsmac, starting trace-cmd record
>>> (with network-manager running in the background), and running a wget on
>>> http://ip-add-ress-of-the-access-point/somefile (which immediately stalls,
>>> showing minimal progress once in a while only).
>>
>> Well. This log and the one from a few days ago only show me
>> interrupt status changes, which does not tell me a lot. I do see
>> that the hardware signals transmit completions, but it is far less
>> informative then I hoped it would be. Maybe I am missing some debug
>> configuration here?
>>
>> Seth, would you know?
>
> Well, there are a few different trace events defined for brcmsmac. This
> would enable the full set:
>
>   $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg
>
> It's been quite some time since I used them, but I think brcmsmac_tx is
> quite noisy so you may only want to enable that if you already suspect a
> tx problem. I always find it useful to enable the mac80211 and
> mac80211_msg events too when debugging wireless, and I often enable
> cfg80211 events as well (none of these are especially verbose).

Ah, I read back the email from Sep 21 and it says:

trace-cmd record brcmsmac:* &

I am surprised the capture contains something as -e is missing. Good to 
know there are different tracers for the driver.

Regards,
Arend

> Of course all of this depends on having the right config options
> selected. Looks like the relevant options are CONFIG_BRCM_TRACING and
> CONFIG_MAC80211_MESSAGE_TRACING.
>
> Seth
>

--
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: [PATCH v4 7/9] net: pxa168_eth: allow Berlin SoCs to use the pxa168_eth driver
From: Antoine Tenart @ 2014-09-23 13:50 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Antoine Tenart,
	sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w,
	thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
	zmxu-eYqpPyKDWXRBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
	jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <4458671.9hKSvmlZNz@wuerfel>

Arnd,

On Tue, Sep 23, 2014 at 02:40:01PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 14:15:34 Antoine Tenart wrote:
> > diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
> > index 1b4fc7c639e6..48b9466d1781 100644
> > --- a/drivers/net/ethernet/marvell/Kconfig
> > +++ b/drivers/net/ethernet/marvell/Kconfig
> > @@ -64,7 +64,7 @@ config MVPP2
> >  
> >  config PXA168_ETH
> >         tristate "Marvell pxa168 ethernet support"
> > -       depends on CPU_PXA168
> > +       depends on CPU_PXA168 || ARCH_BERLIN
> >         select PHYLIB
> >         ---help---
> >           This driver supports the pxa168 Ethernet ports.
> > 
> 
> Myabe you can also add '|| COMPILE_TEST' here, to allow building it

We can add this.

> on other architectures. Check if you need 'depends on OF' though.

I don't think that's needed, the driver still supports non-dt cases.
I'll check.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Seth Forshee @ 2014-09-23 13:44 UTC (permalink / raw)
  To: Arend van Spriel
  Cc: Michael Tokarev, brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54216BF1.3060500-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

On Tue, Sep 23, 2014 at 02:47:45PM +0200, Arend van Spriel wrote:
> On 09/23/14 12:04, Michael Tokarev wrote:
> >21.09.2014 19:30, Michael Tokarev wrote:
> >>Namely, after resume, the card does not work. ARP works, ping and
> >>DNS sometimes/somewhat work, inital TCP connection establisment
> >>works, but eg http download does not work, it stalls almost
> >>immediately.
> >
> >It does not work at all anymore again.  Not only after resume but also
> >after could power up, it stalls right at start of wget for example.
> >
> >>http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this
> >>is a trace collected after resuming from suspend-to-disk
> >
> >And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz
> >is another trace, after insmod brcmutils&  brcmsmac, starting trace-cmd record
> >(with network-manager running in the background), and running a wget on
> >http://ip-add-ress-of-the-access-point/somefile (which immediately stalls,
> >showing minimal progress once in a while only).
> 
> Well. This log and the one from a few days ago only show me
> interrupt status changes, which does not tell me a lot. I do see
> that the hardware signals transmit completions, but it is far less
> informative then I hoped it would be. Maybe I am missing some debug
> configuration here?
> 
> Seth, would you know?

Well, there are a few different trace events defined for brcmsmac. This
would enable the full set:

 $ trace-cmd record -e brcmsmac -e brcmsmac_tx -e brcmsmac_msg

It's been quite some time since I used them, but I think brcmsmac_tx is
quite noisy so you may only want to enable that if you already suspect a
tx problem. I always find it useful to enable the mac80211 and
mac80211_msg events too when debugging wireless, and I often enable
cfg80211 events as well (none of these are especially verbose).

Of course all of this depends on having the right config options
selected. Looks like the relevant options are CONFIG_BRCM_TRACING and
CONFIG_MAC80211_MESSAGE_TRACING.

Seth

--
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

* [RFC PATCH net-next v2 4/5] iptunnels: advertise link netns via netlink
From: Nicolas Dichtel @ 2014-09-23 13:20 UTC (permalink / raw)
  To: netdev, containers, linux-kernel, linux-api
  Cc: davem, ebiederm, stephen, akpm, luto, Nicolas Dichtel
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com>

Implement rtnl_link_ops->get_link_net() callback so that IFLA_LINK_NETNSID is
added to rtnetlink messages.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 include/net/ip_tunnels.h | 1 +
 net/ipv4/ip_gre.c        | 2 ++
 net/ipv4/ip_tunnel.c     | 8 ++++++++
 net/ipv4/ip_vti.c        | 1 +
 net/ipv4/ipip.c          | 1 +
 net/ipv6/sit.c           | 1 +
 6 files changed, 14 insertions(+)

diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 7f538ba6e267..c92a99b5b77e 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -119,6 +119,7 @@ struct ip_tunnel_net {
 int ip_tunnel_init(struct net_device *dev);
 void ip_tunnel_uninit(struct net_device *dev);
 void  ip_tunnel_dellink(struct net_device *dev, struct list_head *head);
+struct net *ip_tunnel_get_link_net(const struct net_device *dev);
 int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
 		       struct rtnl_link_ops *ops, char *devname);
 
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 829aff8bf723..05157427d8f0 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -825,6 +825,7 @@ static struct rtnl_link_ops ipgre_link_ops __read_mostly = {
 	.dellink	= ip_tunnel_dellink,
 	.get_size	= ipgre_get_size,
 	.fill_info	= ipgre_fill_info,
+	.get_link_net	= ip_tunnel_get_link_net,
 };
 
 static struct rtnl_link_ops ipgre_tap_ops __read_mostly = {
@@ -839,6 +840,7 @@ static struct rtnl_link_ops ipgre_tap_ops __read_mostly = {
 	.dellink	= ip_tunnel_dellink,
 	.get_size	= ipgre_get_size,
 	.fill_info	= ipgre_fill_info,
+	.get_link_net	= ip_tunnel_get_link_net,
 };
 
 static int __net_init ipgre_tap_init_net(struct net *net)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index e3a3dc91e49c..da5a2b6fed81 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -954,6 +954,14 @@ void ip_tunnel_dellink(struct net_device *dev, struct list_head *head)
 }
 EXPORT_SYMBOL_GPL(ip_tunnel_dellink);
 
+struct net *ip_tunnel_get_link_net(const struct net_device *dev)
+{
+	struct ip_tunnel *tunnel = netdev_priv(dev);
+
+	return tunnel->net;
+}
+EXPORT_SYMBOL(ip_tunnel_get_link_net);
+
 int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
 				  struct rtnl_link_ops *ops, char *devname)
 {
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index e453cb724a95..93862411669c 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -530,6 +530,7 @@ static struct rtnl_link_ops vti_link_ops __read_mostly = {
 	.changelink	= vti_changelink,
 	.get_size	= vti_get_size,
 	.fill_info	= vti_fill_info,
+	.get_link_net	= ip_tunnel_get_link_net,
 };
 
 static int __init vti_init(void)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index bfec31df8b21..fd423e65d6df 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -496,6 +496,7 @@ static struct rtnl_link_ops ipip_link_ops __read_mostly = {
 	.dellink	= ip_tunnel_dellink,
 	.get_size	= ipip_get_size,
 	.fill_info	= ipip_fill_info,
+	.get_link_net	= ip_tunnel_get_link_net,
 };
 
 static struct xfrm_tunnel ipip_handler __read_mostly = {
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index db75809ab843..5c227cc13170 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1761,6 +1761,7 @@ static struct rtnl_link_ops sit_link_ops __read_mostly = {
 	.get_size	= ipip6_get_size,
 	.fill_info	= ipip6_fill_info,
 	.dellink	= ipip6_dellink,
+	.get_link_net	= ip_tunnel_get_link_net,
 };
 
 static struct xfrm_tunnel sit_handler __read_mostly = {
-- 
2.1.0

^ permalink raw reply related

* [RFC PATCH net-next v2 1/5] netns: allocate netns ids
From: Nicolas Dichtel @ 2014-09-23 13:20 UTC (permalink / raw)
  To: netdev, containers, linux-kernel, linux-api
  Cc: davem, ebiederm, stephen, akpm, luto, Nicolas Dichtel
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com>

With this patch, an id is allocated for each netns. Id database is stored in the
user namespace. It's allowed to get an id of a peer netns only if they share the
same user ns.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 include/linux/user_namespace.h |  4 ++++
 include/net/net_namespace.h    | 11 +++++++++++
 kernel/user_namespace.c        |  6 ++++++
 net/core/net_namespace.c       | 20 +++++++++++++++++++-
 4 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index e95372654f09..9d122b540422 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -5,6 +5,7 @@
 #include <linux/nsproxy.h>
 #include <linux/sched.h>
 #include <linux/err.h>
+#include <linux/idr.h>
 
 #define UID_GID_MAP_MAX_EXTENTS 5
 
@@ -33,6 +34,9 @@ struct user_namespace {
 	struct key		*persistent_keyring_register;
 	struct rw_semaphore	persistent_keyring_register_sem;
 #endif
+#ifdef CONFIG_NET_NS
+	struct idr		netns_ids;
+#endif
 };
 
 extern struct user_namespace init_user_ns;
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 361d26077196..92b5f94e2842 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -59,6 +59,7 @@ struct net {
 	struct list_head	exit_list;	/* Use only net_mutex */
 
 	struct user_namespace   *user_ns;	/* Owning user namespace */
+	int			netnsid;
 
 	unsigned int		proc_inum;
 
@@ -289,6 +290,16 @@ static inline struct net *read_pnet(struct net * const *pnet)
 #define __net_initconst	__initconst
 #endif
 
+static inline int peernet2id(struct net *net, struct net *peer)
+{
+	if (net->user_ns != peer->user_ns)
+		return -EPERM;
+
+	return peer->netnsid;
+}
+
+struct net *get_net_from_netnsid(struct net *net, int id);
+
 struct pernet_operations {
 	struct list_head list;
 	int (*init)(struct net *net);
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index aa312b0dc3ec..30316a2eed49 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -104,6 +104,9 @@ int create_user_ns(struct cred *new)
 #ifdef CONFIG_PERSISTENT_KEYRINGS
 	init_rwsem(&ns->persistent_keyring_register_sem);
 #endif
+#ifdef CONFIG_NET_NS
+	idr_init(&ns->netns_ids);
+#endif
 	return 0;
 }
 
@@ -133,6 +136,9 @@ void free_user_ns(struct user_namespace *ns)
 
 	do {
 		parent = ns->parent;
+#ifdef CONFIG_NET_NS
+		idr_destroy(&ns->netns_ids);
+#endif
 #ifdef CONFIG_PERSISTENT_KEYRINGS
 		key_put(ns->persistent_keyring_register);
 #endif
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 7f155175bba8..f44378de7831 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -144,6 +144,19 @@ static void ops_free_list(const struct pernet_operations *ops,
 	}
 }
 
+struct net *get_net_from_netnsid(struct net *net, int id)
+{
+	struct net *peer;
+
+	rcu_read_lock();
+	peer = idr_find(&net->user_ns->netns_ids, id);
+	if (peer)
+		get_net(peer);
+	rcu_read_unlock();
+
+	return peer;
+}
+
 /*
  * setup_net runs the initializers for the network namespace object.
  */
@@ -151,13 +164,16 @@ static __net_init int setup_net(struct net *net, struct user_namespace *user_ns)
 {
 	/* Must be called with net_mutex held */
 	const struct pernet_operations *ops, *saved_ops;
-	int error = 0;
+	int error = 0, id;
 	LIST_HEAD(net_exit_list);
 
 	atomic_set(&net->count, 1);
 	atomic_set(&net->passive, 1);
 	net->dev_base_seq = 1;
 	net->user_ns = user_ns;
+	id = idr_alloc_cyclic(&user_ns->netns_ids, net, 1, 0, GFP_KERNEL);
+	if (id > 0)
+		net->netnsid = id;
 
 #ifdef NETNS_REFCNT_DEBUG
 	atomic_set(&net->use_count, 0);
@@ -288,6 +304,8 @@ static void cleanup_net(struct work_struct *work)
 	list_for_each_entry(net, &net_kill_list, cleanup_list) {
 		list_del_rcu(&net->list);
 		list_add_tail(&net->exit_list, &net_exit_list);
+		if (net->netnsid)
+			idr_remove(&net->user_ns->netns_ids, net->netnsid);
 	}
 	rtnl_unlock();
 
-- 
2.1.0

^ permalink raw reply related

* [RFC PATCH net-next v2 3/5] rtnl: add link netns id to interface messages
From: Nicolas Dichtel @ 2014-09-23 13:20 UTC (permalink / raw)
  To: netdev, containers, linux-kernel, linux-api
  Cc: davem, ebiederm, stephen, akpm, luto, Nicolas Dichtel
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com>

This patch adds a new attribute (IFLA_LINK_NETNSID) which contains the 'link'
netns id when this netns is different from the netns where the interface
stands (for example for x-net interfaces like ip tunnels). When there is no id,
because user ns of link netns and interface netns is not the same, we put 0
into this attribute (id 0 is not valid) to indicate to userland that the link
netns is different from the interface netns. Hence, userland knows that some
information like IFLA_LINK are not interpretable.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 include/net/rtnetlink.h      |  2 ++
 include/uapi/linux/if_link.h |  1 +
 net/core/rtnetlink.c         | 22 ++++++++++++++++++++++
 3 files changed, 25 insertions(+)

diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
index e21b9f9653c0..6c6d5393fc34 100644
--- a/include/net/rtnetlink.h
+++ b/include/net/rtnetlink.h
@@ -46,6 +46,7 @@ static inline int rtnl_msg_family(const struct nlmsghdr *nlh)
  *			    to create when creating a new device.
  *	@get_num_rx_queues: Function to determine number of receive queues
  *			    to create when creating a new device.
+ *	@get_link_net: Function to get the i/o netns of the device
  */
 struct rtnl_link_ops {
 	struct list_head	list;
@@ -93,6 +94,7 @@ struct rtnl_link_ops {
 	int			(*fill_slave_info)(struct sk_buff *skb,
 						   const struct net_device *dev,
 						   const struct net_device *slave_dev);
+	struct net		*(*get_link_net)(const struct net_device *dev);
 };
 
 int __rtnl_link_register(struct rtnl_link_ops *ops);
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index c80f95f6ee78..21dd2bcb295f 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -145,6 +145,7 @@ enum {
 	IFLA_CARRIER,
 	IFLA_PHYS_PORT_ID,
 	IFLA_CARRIER_CHANGES,
+	IFLA_LINK_NETNSID,
 	__IFLA_MAX
 };
 
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a6882686ca3a..99ed83c62685 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -862,6 +862,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
 	       + nla_total_size(1) /* IFLA_OPERSTATE */
 	       + nla_total_size(1) /* IFLA_LINKMODE */
 	       + nla_total_size(4) /* IFLA_CARRIER_CHANGES */
+	       + nla_total_size(4) /* IFLA_LINK_NETNSID */
 	       + nla_total_size(ext_filter_mask
 			        & RTEXT_FILTER_VF ? 4 : 0) /* IFLA_NUM_VF */
 	       + rtnl_vfinfo_size(dev, ext_filter_mask) /* IFLA_VFINFO_LIST */
@@ -1134,6 +1135,27 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
 			goto nla_put_failure;
 	}
 
+	if (dev->rtnl_link_ops &&
+	    dev->rtnl_link_ops->get_link_net) {
+		struct net *link_net = dev->rtnl_link_ops->get_link_net(dev);
+
+		if (!net_eq(dev_net(dev), link_net)) {
+			int id = peernet2id(dev_net(dev), link_net);
+
+			/* If the link netns is not in the same user ns, put id
+			 * 0 in IFLA_LINK_NETNSID to indicate to userland that
+			 * the link netns is not the current netns, but that it
+			 * don't have access to it.
+			 */
+			if (id == -EPERM)
+				id = 0;
+
+			if (id >= 0 &&
+			    nla_put_u32(skb, IFLA_LINK_NETNSID, id))
+				goto nla_put_failure;
+		}
+	}
+
 	if (!(af_spec = nla_nest_start(skb, IFLA_AF_SPEC)))
 		goto nla_put_failure;
 
-- 
2.1.0

^ permalink raw reply related

* [RFC PATCH net-next v2 2/5] netns: add genl cmd to get the id of a netns
From: Nicolas Dichtel @ 2014-09-23 13:20 UTC (permalink / raw)
  To: netdev, containers, linux-kernel, linux-api
  Cc: davem, ebiederm, stephen, akpm, luto, Nicolas Dichtel
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel@6wind.com>

This patch allows a user to get an id of a peer netns. It will be usefull for
userland to be able to associate a netns file descriptor with a netns id.

Note: to be able to got an id, both netns should be in the same user ns.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 MAINTAINERS                 |  1 +
 include/net/net_namespace.h |  1 +
 include/uapi/linux/Kbuild   |  1 +
 include/uapi/linux/netns.h  | 29 +++++++++++++
 net/core/net_namespace.c    | 99 +++++++++++++++++++++++++++++++++++++++++++++
 net/netlink/genetlink.c     |  4 ++
 6 files changed, 135 insertions(+)
 create mode 100644 include/uapi/linux/netns.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b4e23acc6441..dbf691c68473 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6278,6 +6278,7 @@ F:	include/linux/netdevice.h
 F:	include/uapi/linux/in.h
 F:	include/uapi/linux/net.h
 F:	include/uapi/linux/netdevice.h
+F:	include/uapi/linux/netns.h
 F:	tools/net/
 F:	tools/testing/selftests/net/
 F:	lib/random32.c
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 92b5f94e2842..1b65f5ccacf5 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -299,6 +299,7 @@ static inline int peernet2id(struct net *net, struct net *peer)
 }
 
 struct net *get_net_from_netnsid(struct net *net, int id);
+int netns_genl_register(void);
 
 struct pernet_operations {
 	struct list_head list;
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index fb3f7b675229..840f049c48fa 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -275,6 +275,7 @@ header-y += netfilter_decnet.h
 header-y += netfilter_ipv4.h
 header-y += netfilter_ipv6.h
 header-y += netlink.h
+header-y += netns.h
 header-y += netrom.h
 header-y += nfc.h
 header-y += nfs.h
diff --git a/include/uapi/linux/netns.h b/include/uapi/linux/netns.h
new file mode 100644
index 000000000000..72537e31d7d2
--- /dev/null
+++ b/include/uapi/linux/netns.h
@@ -0,0 +1,29 @@
+#ifndef _UAPI_LINUX_NETNS_H_
+#define _UAPI_LINUX_NETNS_H_
+
+/* Generic netlink messages */
+
+#define NETNS_GENL_NAME			"netns"
+#define NETNS_GENL_VERSION		0x1
+
+/* Commands */
+enum {
+	NETNS_CMD_UNSPEC,
+	NETNS_CMD_GET,
+	__NETNS_CMD_MAX,
+};
+
+#define NETNS_CMD_MAX		(__NETNS_CMD_MAX - 1)
+
+/* Attributes */
+enum {
+	NETNSA_NONE,
+	NETNSA_NSINDEX,
+	NETNSA_PID,
+	NETNSA_FD,
+	__NETNSA_MAX,
+};
+
+#define NETNSA_MAX		(__NETNSA_MAX - 1)
+
+#endif /* _UAPI_LINUX_NETNS_H_ */
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index f44378de7831..a60f2bbf4302 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -15,6 +15,8 @@
 #include <linux/file.h>
 #include <linux/export.h>
 #include <linux/user_namespace.h>
+#include <linux/netns.h>
+#include <net/genetlink.h>
 #include <net/net_namespace.h>
 #include <net/netns/generic.h>
 
@@ -417,6 +419,103 @@ static struct pernet_operations __net_initdata net_ns_ops = {
 	.exit = net_ns_net_exit,
 };
 
+static struct genl_family netns_nl_family = {
+	.id		= GENL_ID_GENERATE,
+	.name		= NETNS_GENL_NAME,
+	.version	= NETNS_GENL_VERSION,
+	.hdrsize	= 0,
+	.maxattr	= NETNSA_MAX,
+	.netnsok	= true,
+};
+
+static struct nla_policy netns_nl_policy[NETNSA_MAX + 1] = {
+	[NETNSA_NONE]		= { .type = NLA_UNSPEC, },
+	[NETNSA_NSINDEX]	= { .type = NLA_U32, },
+	[NETNSA_PID]		= { .type = NLA_U32 },
+	[NETNSA_FD]		= { .type = NLA_U32 },
+};
+
+static int netns_nl_get_size(void)
+{
+	return nla_total_size(sizeof(u32)) /* NETNSA_NSINDEX */
+	       ;
+}
+
+static int netns_nl_fill(struct sk_buff *skb, u32 portid, u32 seq, int flags,
+			 int cmd, struct net *net, struct net *peer)
+{
+	void *hdr;
+	int id;
+
+	hdr = genlmsg_put(skb, portid, seq, &netns_nl_family, flags, cmd);
+	if (!hdr)
+		return -EMSGSIZE;
+
+	id = peernet2id(net, peer);
+	if (id < 0)
+		return id;
+	if (nla_put_u32(skb, NETNSA_NSINDEX, id))
+		goto nla_put_failure;
+
+	return genlmsg_end(skb, hdr);
+
+nla_put_failure:
+	genlmsg_cancel(skb, hdr);
+	return -EMSGSIZE;
+}
+
+static int netns_nl_cmd_getid(struct sk_buff *skb, struct genl_info *info)
+{
+	struct net *net = genl_info_net(info);
+	struct net *peer;
+	struct sk_buff *msg;
+	int err = -ENOBUFS;
+
+	if (info->attrs[NETNSA_PID])
+		peer = get_net_ns_by_pid(nla_get_u32(info->attrs[NETNSA_PID]));
+	else if (info->attrs[NETNSA_FD])
+		peer = get_net_ns_by_fd(nla_get_u32(info->attrs[NETNSA_FD]));
+	else
+		return -EINVAL;
+
+	if (IS_ERR(peer))
+		return PTR_ERR(peer);
+
+	msg = genlmsg_new(netns_nl_get_size(), GFP_KERNEL);
+	if (!msg) {
+		err = -ENOMEM;
+		goto out;
+	}
+
+	err = netns_nl_fill(msg, info->snd_portid, info->snd_seq,
+			    NLM_F_ACK, NETNS_CMD_GETID, net, peer);
+	if (err < 0)
+		goto err_out;
+
+	err = genlmsg_unicast(net, msg, info->snd_portid);
+	goto out;
+
+err_out:
+	nlmsg_free(msg);
+out:
+	put_net(peer);
+	return err;
+}
+
+static struct genl_ops netns_nl_ops[] = {
+	{
+		.cmd = NETNS_CMD_GETID,
+		.policy = netns_nl_policy,
+		.doit = netns_nl_cmd_getid,
+		.flags = GENL_ADMIN_PERM,
+	},
+};
+
+int netns_genl_register(void)
+{
+	return genl_register_family_with_ops(&netns_nl_family, netns_nl_ops);
+}
+
 static int __init net_ns_init(void)
 {
 	struct net_generic *ng;
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 76393f2f4b22..c6f39e40c9f3 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -1029,6 +1029,10 @@ static int __init genl_init(void)
 	if (err)
 		goto problem;
 
+	err = netns_genl_register();
+	if (err < 0)
+		goto problem;
+
 	return 0;
 
 problem:
-- 
2.1.0

^ permalink raw reply related

* [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns
From: Nicolas Dichtel @ 2014-09-23 13:20 UTC (permalink / raw)
  To: netdev, containers, linux-kernel, linux-api
  Cc: davem, ebiederm, stephen, akpm, luto

The goal of this serie is to be able to multicast netlink messages with an
attribute that identify a peer netns.
This is needed by the userland to interpret some informations contained in
netlink messages (like IFLA_LINK value, but also some other attributes in case
of x-netns netdevice (see also
http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).

Ids are stored in the parent user namespace. These ids are valid only inside
this user namespace. The user can retrieve these ids via a new netlink messages,
but only if peer netns are in the same user namespace.

Patch 1/5 and 2/5 introduce the netlink API mechanism to exports these ids to
the userland.
Patch 3/5 and 4/5 shows an example of how to use these ids in rtnetlink
messages. And patch 5/5 shows that the netlink messages can be symetric between
a GET and a SET.

iproute2 patches are available, I can send them on demand.

Here is a small screenshot to show how it can be used by userland:
$ ip netns add foo
$ ip netns del foo
$ ip netns
$ touch /var/run/netns/init_net
$ mount --bind /proc/1/ns/net /var/run/netns/init_net
$ ip netns add foo
$ ip netns
foo (id: 3)
init_net (id: 1)
$ ip netns exec foo ip netns
foo (id: 3)
init_net (id: 1)
$ ip netns exec foo ip link add ipip1 link-netnsid 1 type ipip remote 10.16.0.121 local 10.16.0.249
$ ip netns exec foo ip l ls ipip1
6: ipip1@NONE: <POINTOPOINT,NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default 
    link/ipip 10.16.0.249 peer 10.16.0.121 link-netnsid 1

The parameter link-netnsid shows us where the interface sends and receives
packets (and thus we know where encapsulated addresses are set).

RFCv1 -> RFCv2:
  remove useless ()
  ids are now stored in the user ns. It's possible to get an id for a peer netns
  only if the current netns and the peer netns have the same user ns parent.

 MAINTAINERS                    |   1 +
 include/linux/user_namespace.h |   4 ++
 include/net/ip_tunnels.h       |   1 +
 include/net/net_namespace.h    |  12 +++++
 include/net/rtnetlink.h        |   2 +
 include/uapi/linux/Kbuild      |   1 +
 include/uapi/linux/if_link.h   |   1 +
 include/uapi/linux/netns.h     |  29 ++++++++++
 kernel/user_namespace.c        |   6 +++
 net/core/net_namespace.c       | 119 ++++++++++++++++++++++++++++++++++++++++-
 net/core/rtnetlink.c           |  47 ++++++++++++++--
 net/ipv4/ip_gre.c              |   2 +
 net/ipv4/ip_tunnel.c           |   8 +++
 net/ipv4/ip_vti.c              |   1 +
 net/ipv4/ipip.c                |   1 +
 net/ipv6/sit.c                 |   1 +
 net/netlink/genetlink.c        |   4 ++
 17 files changed, 236 insertions(+), 4 deletions(-)

Comments are welcome.

Regards,
Nicolas

^ permalink raw reply

* [RFC PATCH net-next v2 5/5] rtnl: allow to create device with IFLA_LINK_NETNSID set
From: Nicolas Dichtel @ 2014-09-23 13:20 UTC (permalink / raw)
  To: netdev-u79uwXL29TY76Z2rM5mHXA,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-api-u79uwXL29TY76Z2rM5mHXA
  Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, luto-kltTT9wpgjJwATOyAt5JVQ,
	stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, Nicolas Dichtel
In-Reply-To: <1411478430-4989-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>

This patch adds the ability to create a netdevice in a specified netns and
then move it into the final netns. In fact, it allows to have a symetry between
get and set rtnl messages.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
---
 net/core/rtnetlink.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 99ed83c62685..34b894ae79b4 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1220,6 +1220,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
 	[IFLA_NUM_RX_QUEUES]	= { .type = NLA_U32 },
 	[IFLA_PHYS_PORT_ID]	= { .type = NLA_BINARY, .len = MAX_PHYS_PORT_ID_LEN },
 	[IFLA_CARRIER_CHANGES]	= { .type = NLA_U32 },  /* ignored */
+	[IFLA_LINK_NETNSID]	= { .type = NLA_U32 },
 };
 
 static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
@@ -1992,7 +1993,7 @@ replay:
 		struct nlattr *slave_attr[m_ops ? m_ops->slave_maxtype + 1 : 0];
 		struct nlattr **data = NULL;
 		struct nlattr **slave_data = NULL;
-		struct net *dest_net;
+		struct net *dest_net, *link_net = NULL;
 
 		if (ops) {
 			if (ops->maxtype && linkinfo[IFLA_INFO_DATA]) {
@@ -2098,7 +2099,18 @@ replay:
 		if (IS_ERR(dest_net))
 			return PTR_ERR(dest_net);
 
-		dev = rtnl_create_link(dest_net, ifname, name_assign_type, ops, tb);
+		if (tb[IFLA_LINK_NETNSID]) {
+			int id = nla_get_u32(tb[IFLA_LINK_NETNSID]);
+
+			link_net = get_net_from_netnsid(dest_net, id);
+			if (link_net == NULL) {
+				err =  -EINVAL;
+				goto out;
+			}
+		}
+
+		dev = rtnl_create_link(link_net ? : dest_net, ifname,
+				       name_assign_type, ops, tb);
 		if (IS_ERR(dev)) {
 			err = PTR_ERR(dev);
 			goto out;
@@ -2126,9 +2138,16 @@ replay:
 			}
 		}
 		err = rtnl_configure_link(dev, ifm);
-		if (err < 0)
+		if (err < 0) {
 			unregister_netdevice(dev);
+			goto out;
+		}
+
+		if (link_net)
+			err = dev_change_net_namespace(dev, net, ifname);
 out:
+		if (link_net)
+			put_net(link_net);
 		put_net(dest_net);
 		return err;
 	}
-- 
2.1.0

^ permalink raw reply related

* [PATCH] net: bcmgenet: Fix compile warning
From: Tobias Klauser @ 2014-09-23 13:19 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: David S. Miller, Geert Uytterhoeven, netdev

bcmgenet_wol_resume() is only used in bcmgenet_resume(), which is only
defined when CONFIG_PM_SLEEP is enabled. This leads to the following
compile warning when building with !CONFIG_PM_SLEEP:

drivers/net/ethernet/broadcom/genet/bcmgenet.c:1967:12: warning: ‘bcmgenet_wol_resume’ defined but not used [-Wunused-function]

Since bcmgenet_resume() is the only user of bcmgenet_wol_resume(), fix
this by directly inlining the function there.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
 drivers/net/ethernet/broadcom/genet/bcmgenet.c | 23 +++++++----------------
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 313c400..e852d20 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1964,19 +1964,6 @@ static void bcmgenet_set_hw_addr(struct bcmgenet_priv *priv,
 	bcmgenet_umac_writel(priv, (addr[4] << 8) | addr[5], UMAC_MAC1);
 }
 
-static int bcmgenet_wol_resume(struct bcmgenet_priv *priv)
-{
-	/* From WOL-enabled suspend, switch to regular clock */
-	if (priv->wolopts)
-		clk_disable_unprepare(priv->clk_wol);
-
-	phy_init_hw(priv->phydev);
-	/* Speed settings must be restored */
-	bcmgenet_mii_config(priv->dev);
-
-	return 0;
-}
-
 /* Returns a reusable dma control register value */
 static u32 bcmgenet_dma_disable(struct bcmgenet_priv *priv)
 {
@@ -2681,9 +2668,13 @@ static int bcmgenet_resume(struct device *d)
 	if (ret)
 		goto out_clk_disable;
 
-	ret = bcmgenet_wol_resume(priv);
-	if (ret)
-		goto out_clk_disable;
+	/* From WOL-enabled suspend, switch to regular clock */
+	if (priv->wolopts)
+		clk_disable_unprepare(priv->clk_wol);
+
+	phy_init_hw(priv->phydev);
+	/* Speed settings must be restored */
+	bcmgenet_mii_config(priv->dev);
 
 	/* disable ethernet MAC while updating its registers */
 	umac_enable_set(priv, CMD_TX_EN | CMD_RX_EN, false);
-- 
2.0.1

^ permalink raw reply related

* [PATCH net] net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode
From: Or Gerlitz @ 2014-09-23 13:05 UTC (permalink / raw)
  To: David S. Miller
  Cc: netdev, Amir Vadai, Jack Morgenstein, Matan Barak, Or Gerlitz

From: Matan Barak <matanb@mellanox.com>

When the HCA is configured in SRIOV IB mode (that is, at least one of
the ports is IB) and the probe_vf module param isn't specified,
mlx4_init_one() failed because of the following condition:

if (ib_ports && (num_vfs_argc > 1 || probe_vfs_argc > 1)) {
	 .....
}

The root cause for that is a mistake in the initialization of num_vfs_argc
and probe_vfs_argc. When num_vfs / probe_vf aren't given, their argument
count counterpart should be 0, fix that.

Fixes: dd41cc3bb90e ('net/mlx4: Adapt num_vfs/probed_vf params for single port VF')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---

Hi Dave, 

This bug was introduced in 3.16, can you please push this patch along 
with commit a91c772fa0275 "net/mlx4: Correctly configure single ported 
VFs from the host" to 3.16-stable

Or.

 drivers/net/ethernet/mellanox/mlx4/main.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 7e2d5d5..871e3a5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -78,13 +78,13 @@ MODULE_PARM_DESC(msi_x, "attempt to use MSI-X if nonzero");
 #endif /* CONFIG_PCI_MSI */
 
 static uint8_t num_vfs[3] = {0, 0, 0};
-static int num_vfs_argc = 3;
+static int num_vfs_argc;
 module_param_array(num_vfs, byte , &num_vfs_argc, 0444);
 MODULE_PARM_DESC(num_vfs, "enable #num_vfs functions if num_vfs > 0\n"
 			  "num_vfs=port1,port2,port1+2");
 
 static uint8_t probe_vf[3] = {0, 0, 0};
-static int probe_vfs_argc = 3;
+static int probe_vfs_argc;
 module_param_array(probe_vf, byte, &probe_vfs_argc, 0444);
 MODULE_PARM_DESC(probe_vf, "number of vfs to probe by pf driver (num_vfs > 0)\n"
 			   "probe_vf=port1,port2,port1+2");
-- 
1.7.1

^ permalink raw reply related

* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-09-23 12:47 UTC (permalink / raw)
  To: Michael Tokarev; +Cc: brcm80211-dev-list, linux-wireless, netdev, Seth Forshee
In-Reply-To: <542145B1.4030202@msgid.tls.msk.ru>

On 09/23/14 12:04, Michael Tokarev wrote:
> 21.09.2014 19:30, Michael Tokarev wrote:
>> Namely, after resume, the card does not work. ARP works, ping and
>> DNS sometimes/somewhat work, inital TCP connection establisment
>> works, but eg http download does not work, it stalls almost
>> immediately.
>
> It does not work at all anymore again.  Not only after resume but also
> after could power up, it stalls right at start of wget for example.
>
>> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140921.dat.gz -- this
>> is a trace collected after resuming from suspend-to-disk
>
> And here -- http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-20140923.dat.gz
> is another trace, after insmod brcmutils&  brcmsmac, starting trace-cmd record
> (with network-manager running in the background), and running a wget on
> http://ip-add-ress-of-the-access-point/somefile (which immediately stalls,
> showing minimal progress once in a while only).

Well. This log and the one from a few days ago only show me interrupt 
status changes, which does not tell me a lot. I do see that the hardware 
signals transmit completions, but it is far less informative then I 
hoped it would be. Maybe I am missing some debug configuration here?

Seth, would you know?

Regards,
Arend

> Hopefully this will help to find the problem.  And for the record, I'm
> _again_ without the wifi network.  But unlike of the previous situation,
> I can at least buy some other, better supported wifi adapter now, because
> this laptop does not have a bios lock (is 6235ANHMW any good?)
>
> Thanks,
>
> /mjt

^ permalink raw reply

* Re: [PATCH v4 0/9] ARM: Berlin: Ethernet support
From: Arnd Bergmann @ 2014-09-23 12:41 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Antoine Tenart, sebastian.hesselbarth, thomas.petazzoni, zmxu,
	devicetree, netdev, linux-kernel, alexandre.belloni, jszhang
In-Reply-To: <1411474536-22626-1-git-send-email-antoine.tenart@free-electrons.com>

On Tuesday 23 September 2014 14:15:27 Antoine Tenart wrote:
> 
> This series introduce support for the Ethernet controller on Berlin SoCs,
> using the existing pxa168 Ethernet driver. In order to do this, DT
> support is added to the driver alongside some other modifications and
> fixes.
> 

Looks great overall, I've commented on two issues I've found, but only
the phy-addr one really needs to be addressed. Once that is out of the
way, please add

Acked-by: Arnd Bergmann <arnd@arndb.de>

^ permalink raw reply

* Re: [PATCH v4 7/9] net: pxa168_eth: allow Berlin SoCs to use the pxa168_eth driver
From: Arnd Bergmann @ 2014-09-23 12:40 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Antoine Tenart, sebastian.hesselbarth, thomas.petazzoni, zmxu,
	devicetree, netdev, linux-kernel, alexandre.belloni, jszhang
In-Reply-To: <1411474536-22626-8-git-send-email-antoine.tenart@free-electrons.com>

On Tuesday 23 September 2014 14:15:34 Antoine Tenart wrote:
> diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
> index 1b4fc7c639e6..48b9466d1781 100644
> --- a/drivers/net/ethernet/marvell/Kconfig
> +++ b/drivers/net/ethernet/marvell/Kconfig
> @@ -64,7 +64,7 @@ config MVPP2
>  
>  config PXA168_ETH
>         tristate "Marvell pxa168 ethernet support"
> -       depends on CPU_PXA168
> +       depends on CPU_PXA168 || ARCH_BERLIN
>         select PHYLIB
>         ---help---
>           This driver supports the pxa168 Ethernet ports.
> 

Myabe you can also add '|| COMPILE_TEST' here, to allow building it
on other architectures. Check if you need 'depends on OF' though.

	Arnd

^ permalink raw reply

* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 12:38 UTC (permalink / raw)
  To: Antoine Tenart
  Cc: sebastian.hesselbarth, alexandre.belloni, thomas.petazzoni, zmxu,
	jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1411474536-22626-4-git-send-email-antoine.tenart@free-electrons.com>

On Tuesday 23 September 2014 14:15:30 Antoine Tenart wrote:
> +Optional properties:
> +- port-id: should be '0','1' or '2'.
> +- phy-addr: MDIO address of the PHY.
> +- local-mac-address: see ethernet.txt file in the same directory.
> +
> 

I believe new bindings should not use "phy-addr" properties, but
instead use a phy-handle property pointing to a phy device instead.

The port-id property description could be a little more verbose.
What do those numbers actually mean?

	Arnd

^ permalink raw reply

* [PATCH v4 9/9] ARM: dts: berlin: enable the Ethernet port on the BG2Q DMP
From: Antoine Tenart @ 2014-09-23 12:15 UTC (permalink / raw)
  To: sebastian.hesselbarth
  Cc: Antoine Tenart, alexandre.belloni, thomas.petazzoni, zmxu,
	jszhang, netdev, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <1411474536-22626-1-git-send-email-antoine.tenart@free-electrons.com>

This patch enables the Ethernet port on the Marvell Berlin2Q DMP board.

Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
 arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index a357ce02a64e..ea1f99b8eed6 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -45,3 +45,7 @@
 &uart0 {
 	status = "okay";
 };
+
+&eth0 {
+	status = "okay";
+};
-- 
1.9.1

^ permalink raw reply related


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