Netdev List
 help / color / mirror / Atom feed
* [PATCHv2 perf/core 0/2] libbpf: Synchronize implementations
From: Joe Stringer @ 2016-11-16 17:43 UTC (permalink / raw)
  To: linux-kernel; +Cc: netdev, wangnan0, ast, daniel, acme

Update tools/lib/bpf to provide more functionality and improve interoperation
with other tools that generate and use eBPF code:
* The kernel uapi headers are a bit newer than the version in the tools/
  directory; synchronize those.
* samples/bpf/libbpf* has a bit more functionality than tools/lib/bpf, so
  extend tools/lib/bpf/bpf* with these functions to bring them into parity.

I've got a separate series to update samples/bpf/* to rely on these libraries,
but there's a conflict with davem's tree at the moment so I suppose that the
way forward is to get these patches through first, then take the samples
through net-next at a later time.

---
v2: Don't shift non-bpf code into libbpf.
    Drop the patch to synchronize ELF definitions with tc.
v1: https://www.mail-archive.com/netdev@vger.kernel.org/msg135088.html
    First post.

Joe Stringer (2):
  tools lib bpf: Sync {tools,}/include/uapi/linux/bpf.h
  tools lib bpf: Sync with samples/bpf/libbpf

 tools/include/uapi/linux/bpf.h |  51 +++++++++++
 tools/lib/bpf/bpf.c            | 107 +++++++++++++++++-----
 tools/lib/bpf/bpf.h            | 202 +++++++++++++++++++++++++++++++++++++++--
 tools/lib/bpf/libbpf.c         |   3 +-
 4 files changed, 330 insertions(+), 33 deletions(-)

-- 
2.9.3

^ permalink raw reply

* Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump
From: Hannes Frederic Sowa @ 2016-11-16 17:35 UTC (permalink / raw)
  To: Ido Schimmel
  Cc: Jiri Pirko, netdev, davem, idosch, eladr, yotamg, nogahf, arkadis,
	ogerlitz, roopa, dsa, nikolay, andy, vivien.didelot, andrew,
	f.fainelli, alexander.h.duyck, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161116151829.h6kapbjes7xxxcyi@splinter.mtl.com>

On 16.11.2016 16:18, Ido Schimmel wrote:
> Hi Hannes,
> 
> On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote:
>> On 16.11.2016 15:09, Jiri Pirko wrote:
>>> From: Ido Schimmel <idosch@mellanox.com>
>>>
>>> Commit b90eb7549499 ("fib: introduce FIB notification infrastructure")
>>> introduced a new notification chain to notify listeners (f.e., switchdev
>>> drivers) about addition and deletion of routes.
>>>
>>> However, upon registration to the chain the FIB tables can already be
>>> populated, which means potential listeners will have an incomplete view
>>> of the tables.
>>>
>>> Solve that by adding an API to request a FIB dump. The dump itself it
>>> done using RCU in order not to starve consumers that need RTNL to make
>>> progress.
>>>
>>> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>
>> Have you looked at potential inconsistencies resulting of RCU walking
>> the table and having concurrent inserts?
> 
> Yes. I did try to think about situations in which this approach will
> fail, but I could only find problems with concurrent removals, which I
> addressed in 5/8. In case of concurrent insertions, even if you missed
> the node, you would still get the ENTRY_ADD event to your listener.

Theoretically a node could still be installed while the deletion event
fired before registering the notifier. E.g. a synchronize_net before
dumping could help here?

I don't know how you prepare the data structures for inserting in into
the hardware, but if ordering matters, the notifier for a delete event
can be called before the dump installed the fib entry? E.g. you also
don't check what events are already queued in the delayed work queue so
far. I hope I understand the patches correctly?

Thanks,
Hannes

^ permalink raw reply

* Re: [PATCH ipsec-next 6/8] xfrm: policy: only use rcu in xfrm_sk_policy_lookup
From: Florian Westphal @ 2016-11-16 17:30 UTC (permalink / raw)
  To: Nicolas Dichtel; +Cc: Florian Westphal, netdev, Steffen Klassert
In-Reply-To: <0e235471-cb63-2376-c42d-5872e78e4c98@6wind.com>

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 11/08/2016 à 15:17, Florian Westphal a écrit :
> > Don't acquire the readlock anymore and rely on rcu alone.
> > 
> > In case writer on other CPU changed policy at the wrong moment (after we
> > obtained sk policy pointer but before we could obtain the reference)
> > just repeat the lookup.
> > 
> > Signed-off-by: Florian Westphal <fw@strlen.de>
> Since this patch, our IKEv1 Transport tests (using charon) fail to establish the
> connection. If I revert it, the IKE negociation is ok again.
> charon logs are enclosed.
> 
> I didn't had time to investigate now, but any idea is welcomed ;-)

I'm an idiot.  Thanks for figuring out the faulty commit!

This should fix it (if we succeed grabbing the refcount, then if (err && !xfrm_pol_hold_rcu
evaluates to false and we hit last else branch and set pol to ERR_PTR(0)...

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index fd6986634e6f..5bf7e1bfeac7 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1268,12 +1268,14 @@ static struct xfrm_policy *xfrm_sk_policy_lookup(const struct sock *sk, int dir,
                        err = security_xfrm_policy_lookup(pol->security,
                                                      fl->flowi_secid,
                                                      policy_to_flow_dir(dir));
-                       if (!err && !xfrm_pol_hold_rcu(pol))
-                               goto again;
-                       else if (err == -ESRCH)
+                       if (!err) {
+                               if (!xfrm_pol_hold_rcu(pol))
+                                       goto again;
+                       } else if (err == -ESRCH) {
                                pol = NULL;
-                       else
+                       } else {
                                pol = ERR_PTR(err);
+                       }
                } else

^ permalink raw reply related

* Re: [PATCH net v2] net: nsid cannot be allocated for a dead netns
From: Cong Wang @ 2016-11-16 17:29 UTC (permalink / raw)
  To: Nicolas Dichtel
  Cc: Andrey Wagin, David Miller, Linux Kernel Network Developers
In-Reply-To: <1479289775-1715-1-git-send-email-nicolas.dichtel@6wind.com>

On Wed, Nov 16, 2016 at 1:49 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index f61c0e02a413..63f65387f4e1 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -159,6 +159,9 @@ static int alloc_netid(struct net *net, struct net *peer, int reqid)
>                 max = reqid + 1;
>         }
>
> +       if (!atomic_read(&net->count) || !atomic_read(&peer->count))
> +               return -EINVAL;
> +
>         return idr_alloc(&net->netns_ids, peer, min, max, GFP_ATOMIC);
>  }


There is already a check in peernet2id_alloc(), so why not just the following?

diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index f61c0e0..7001da9 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -219,6 +219,8 @@ int peernet2id_alloc(struct net *net, struct net *peer)
        bool alloc;
        int id;

+       if (atomic_read(&net->count) == 0)
+               return NETNSA_NSID_NOT_ASSIGNED;
        spin_lock_irqsave(&net->nsid_lock, flags);
        alloc = atomic_read(&peer->count) == 0 ? false : true;
        id = __peernet2id_alloc(net, peer, &alloc);

^ permalink raw reply related

* Re: [PATCH] net: dsa: fix fixed-link-phy device leaks
From: Johan Hovold @ 2016-11-16 17:11 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Johan Hovold, Andrew Lunn, Vivien Didelot, David S. Miller,
	netdev, linux-kernel
In-Reply-To: <42af57ed-df84-f628-659d-c982d30da7d5@gmail.com>

On Wed, Nov 16, 2016 at 09:06:26AM -0800, Florian Fainelli wrote:
> On 11/16/2016 06:47 AM, Johan Hovold wrote:
> > Make sure to drop the reference taken by of_phy_find_device() when
> > registering and deregistering the fixed-link PHY-device.
> > 
> > Note that we need to put both references held at deregistration.
> > 
> > Fixes: 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port
> > speeds/duplex")
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > 
> > Hi,
> > 
> > This is one has been compile tested only, but fixes a couple of leaks
> > similar to one that was found in the cpsw driver for which I just posted
> > a patch.
> > 
> > It turns out all drivers but DSA fail to deregister the fixed-link PHYs
> > registered by of_phy_register_fixed_link(). Due to the way this
> > interface was designed, deregistering such a PHY is a bit cumbersome and
> > looks like it would benefit from a common helper.
> > 
> > However, perhaps the interface should instead be changed so that the PHY
> > device is returned so that drivers do not need to use
> > of_phy_find_device() when they need to access properties of the fixed
> > link (e.g. as in dsu_cpu_dsa_setup below).
> > 
> > Thoughts?
> > 
> > Thanks,
> > Johan
> > 
> > 
> >  net/dsa/dsa.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> > index a6902c1e2f28..798a6a776a5f 100644
> > --- a/net/dsa/dsa.c
> > +++ b/net/dsa/dsa.c
> > @@ -233,6 +233,8 @@ int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct device *dev,
> >  		genphy_read_status(phydev);
> >  		if (ds->ops->adjust_link)
> >  			ds->ops->adjust_link(ds, port, phydev);
> > +
> > +		phy_device_free(phydev);	/* of_phy_find_device */
> >  	}
> >  
> >  	return 0;
> > @@ -509,8 +511,12 @@ void dsa_cpu_dsa_destroy(struct device_node *port_dn)
> >  	if (of_phy_is_fixed_link(port_dn)) {
> >  		phydev = of_phy_find_device(port_dn);
> >  		if (phydev) {
> > -			phy_device_free(phydev);
> >  			fixed_phy_unregister(phydev);
> > +			/* Put references taken by of_phy_find_device() and
> > +			 * of_phy_register_fixed_link().
> > +			 */
> > +			phy_device_free(phydev);
> > +			phy_device_free(phydev);
> 
> Double free, this looks bogus here. Actually would not this mean a
> triple free since you already free in dsa_cpu_dsa_setup() which is
> paired with dsa_cpu_dsa_destroy()?

The naming of phy_device_free() is unfortunate when it's really a put():

void phy_device_free(struct phy_device *phydev)
{
	put_device(&phydev->mdio.dev);
}

which may need to be called multiple times, specifically after a call to
of_phy_find_device() which takes another reference.

With this patch the refcounts are properly balanced.

Johan

^ permalink raw reply

* [PATCH net-next] udp: enable busy polling for all sockets
From: Eric Dumazet @ 2016-11-16 17:10 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Willem de Bruijn

From: Eric Dumazet <edumazet@google.com>

UDP busy polling is restricted to connected UDP sockets.

This is because sk_busy_loop() only takes care of one NAPI context.

There are cases where it could be extended.

1) Some hosts receive traffic on a single NIC, with one RX queue.

2) Some applications use SO_REUSEPORT and associated BPF filter
   to split the incoming traffic on one UDP socket per RX
queue/thread/cpu

3) Some UDP sockets are used to send/receive traffic for one flow, but
they do not bother with connect()


This patch records the napi_id of first received skb, giving more
reach to busy polling.

Tested:

lpaa23:~# echo 70 >/proc/sys/net/core/busy_read
lpaa24:~# echo 70 >/proc/sys/net/core/busy_read

lpaa23:~# for f in `seq 1 10`; do ./super_netperf 1 -H lpaa24 -t UDP_RR -l 5; done

Before patch :
   27867   28870   37324   41060   41215
   36764   36838   44455   41282   43843
After patch :
   73920   73213   70147   74845   71697
   68315   68028   75219   70082   73707

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
---
 include/net/busy_poll.h |   28 +++++++++++++++++++---------
 net/ipv4/udp.c          |    2 ++
 net/ipv6/udp.c          |    2 ++
 3 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
index 2fbeb1313c0f4f78ac82ddf6c18d1016a901f99a..34c57a0ec040a58f09b12e3878f534433dc30015 100644
--- a/include/net/busy_poll.h
+++ b/include/net/busy_poll.h
@@ -81,11 +81,6 @@ static inline void skb_mark_napi_id(struct sk_buff *skb,
 	skb->napi_id = napi->napi_id;
 }
 
-/* used in the protocol hanlder to propagate the napi_id to the socket */
-static inline void sk_mark_napi_id(struct sock *sk, struct sk_buff *skb)
-{
-	sk->sk_napi_id = skb->napi_id;
-}
 
 #else /* CONFIG_NET_RX_BUSY_POLL */
 static inline unsigned long net_busy_loop_on(void)
@@ -108,10 +103,6 @@ static inline void skb_mark_napi_id(struct sk_buff *skb,
 {
 }
 
-static inline void sk_mark_napi_id(struct sock *sk, struct sk_buff *skb)
-{
-}
-
 static inline bool busy_loop_timeout(unsigned long end_time)
 {
 	return true;
@@ -123,4 +114,23 @@ static inline bool sk_busy_loop(struct sock *sk, int nonblock)
 }
 
 #endif /* CONFIG_NET_RX_BUSY_POLL */
+
+/* used in the protocol hanlder to propagate the napi_id to the socket */
+static inline void sk_mark_napi_id(struct sock *sk, const struct sk_buff *skb)
+{
+#ifdef CONFIG_NET_RX_BUSY_POLL
+	sk->sk_napi_id = skb->napi_id;
+#endif
+}
+
+/* variant used for unconnected sockets */
+static inline void sk_mark_napi_id_once(struct sock *sk,
+					const struct sk_buff *skb)
+{
+#ifdef CONFIG_NET_RX_BUSY_POLL
+	if (!sk->sk_napi_id)
+		sk->sk_napi_id = skb->napi_id;
+#endif
+}
+
 #endif /* _LINUX_NET_BUSY_POLL_H */
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 9ae7c63a8b131f56a3c05e00a8f7d106a0362c54..e1fc0116e8d59d8185670c6e55d1219bde55610d 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1569,6 +1569,8 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 		sock_rps_save_rxhash(sk, skb);
 		sk_mark_napi_id(sk, skb);
 		sk_incoming_cpu_update(sk);
+	} else {
+		sk_mark_napi_id_once(sk, skb);
 	}
 
 	rc = __udp_enqueue_schedule_skb(sk, skb);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 86a8cacd333b64f40acc7350a45213cb422a9c1a..4f99417d9b401f2a65c7828e7d6b86d1d6161794 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -519,6 +519,8 @@ static int __udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
 		sock_rps_save_rxhash(sk, skb);
 		sk_mark_napi_id(sk, skb);
 		sk_incoming_cpu_update(sk);
+	} else {
+		sk_mark_napi_id_once(sk, skb);
 	}
 
 	rc = __udp_enqueue_schedule_skb(sk, skb);

^ permalink raw reply related

* Re: [PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Alex @ 2016-11-16 17:10 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: f.fainelli, netdev, linux-kernel, davem, Gokhan Cosgul
In-Reply-To: <20161116165437.GK23231@lunn.ch>



On 11/16/2016 08:54 AM, Andrew Lunn wrote:
> On Wed, Nov 16, 2016 at 08:44:30AM -0800, Alex wrote:
>>
>>
>> On 11/16/2016 05:50 AM, Andrew Lunn wrote:
>>> On Wed, Nov 16, 2016 at 01:02:33AM -0800, Alexandru Gagniuc wrote:
>>>> With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
>>>> VSC8601 can handle this internally. While the VSC8601 can set more
>>>> fine-grained delays, the standard skew settings work out of the box.
>>>> The same heuristic is used to determine when this skew should be enabled
>>>> as in vsc824x_config_init().
>>>>
>>>> +/* This adds a skew for both TX and RX clocks, so the skew should only be
>>>> + * applied to "rgmii-id" interfaces. It may not work as expected
>>>> + * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
>>>
>>> Hi Alexandru
>>>
>>> You should be able to make "rgmii" work as expected. If that is the
>>> phy mode, disable the skew.
>>
>> And that's exactly the implemented behavior. See
>> vsc8601_config_init() below.
>
> I don't think so. vsc8601_config_init() will not cause the skew to be
> cleared if the phy-mode is "rgmii" and something else like the
> bootloader could of set the skew. So saying that "rgmii" might not
> work as expected is true. But with a minor change, you can make it
> work as expected.

That's not within the scope of this change. The scope is to make 
rgmii-id work. Any additional changes would be untested.

Alex

^ permalink raw reply

* Re: [PATCH] net: dsa: fix fixed-link-phy device leaks
From: Florian Fainelli @ 2016-11-16 17:06 UTC (permalink / raw)
  To: Johan Hovold, Andrew Lunn
  Cc: Vivien Didelot, David S. Miller, netdev, linux-kernel
In-Reply-To: <1479307664-32428-1-git-send-email-johan@kernel.org>

On 11/16/2016 06:47 AM, Johan Hovold wrote:
> Make sure to drop the reference taken by of_phy_find_device() when
> registering and deregistering the fixed-link PHY-device.
> 
> Note that we need to put both references held at deregistration.
> 
> Fixes: 39b0c705195e ("net: dsa: Allow configuration of CPU & DSA port
> speeds/duplex")
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> 
> Hi,
> 
> This is one has been compile tested only, but fixes a couple of leaks
> similar to one that was found in the cpsw driver for which I just posted
> a patch.
> 
> It turns out all drivers but DSA fail to deregister the fixed-link PHYs
> registered by of_phy_register_fixed_link(). Due to the way this
> interface was designed, deregistering such a PHY is a bit cumbersome and
> looks like it would benefit from a common helper.
> 
> However, perhaps the interface should instead be changed so that the PHY
> device is returned so that drivers do not need to use
> of_phy_find_device() when they need to access properties of the fixed
> link (e.g. as in dsu_cpu_dsa_setup below).
> 
> Thoughts?
> 
> Thanks,
> Johan
> 
> 
>  net/dsa/dsa.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index a6902c1e2f28..798a6a776a5f 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -233,6 +233,8 @@ int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct device *dev,
>  		genphy_read_status(phydev);
>  		if (ds->ops->adjust_link)
>  			ds->ops->adjust_link(ds, port, phydev);
> +
> +		phy_device_free(phydev);	/* of_phy_find_device */
>  	}
>  
>  	return 0;
> @@ -509,8 +511,12 @@ void dsa_cpu_dsa_destroy(struct device_node *port_dn)
>  	if (of_phy_is_fixed_link(port_dn)) {
>  		phydev = of_phy_find_device(port_dn);
>  		if (phydev) {
> -			phy_device_free(phydev);
>  			fixed_phy_unregister(phydev);
> +			/* Put references taken by of_phy_find_device() and
> +			 * of_phy_register_fixed_link().
> +			 */
> +			phy_device_free(phydev);
> +			phy_device_free(phydev);

Double free, this looks bogus here. Actually would not this mean a
triple free since you already free in dsa_cpu_dsa_setup() which is
paired with dsa_cpu_dsa_destroy()?
-- 
Florian

^ permalink raw reply

* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Anand Moon @ 2016-11-16 17:06 UTC (permalink / raw)
  To: Jerome Brunet
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree, Florian Fainelli,
	Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
	Kevin Hilman, Linux Kernel, Andre Roth,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
	Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <1479220154-25851-2-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

 Hi Jerome.

On 15 November 2016 at 19:59, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> On some platforms, energy efficient ethernet with rtl8211 devices is
> causing issue, like throughput drop or broken link.
>
> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
> cause is not fully understood yet, disabling EEE advertisement prevent auto
> negotiation from enabling EEE.
>
> This patch provides options to disable 1000T and 100TX EEE advertisement
> individually for the realtek phys supporting this feature.
>
> Reported-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Cc: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
> Cc: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Tested-by: Andre Roth <neolynx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/net/phy/realtek.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index aadd6e9f54ad..77235fd5faaf 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -15,6 +15,12 @@
>   */
>  #include <linux/phy.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
> +
> +struct rtl8211x_phy_priv {
> +       bool eee_1000t_disable;
> +       bool eee_100tx_disable;
> +};
>
>  #define RTL821x_PHYSR          0x11
>  #define RTL821x_PHYSR_DUPLEX   0x2000
> @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct phy_device *phydev)
>         return err;
>  }
>
> +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
> +{
> +       struct rtl8211x_phy_priv *priv = phydev->priv;
> +       u16 val;
> +
> +       if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
> +               val = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> +                                           MDIO_MMD_AN);
> +
> +               if (priv->eee_1000t_disable)
> +                       val &= ~MDIO_AN_EEE_ADV_1000T;
> +               if (priv->eee_100tx_disable)
> +                       val &= ~MDIO_AN_EEE_ADV_100TX;
> +
> +               phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> +                                      MDIO_MMD_AN, val);
> +       }
> +}
> +
> +static int rtl8211x_config_init(struct phy_device *phydev)
> +{
> +       int ret;
> +
> +       ret = genphy_config_init(phydev);
> +       if (ret < 0)
> +               return ret;
> +
> +       rtl8211x_clear_eee_adv(phydev);
> +
> +       return 0;
> +}
> +
>  static int rtl8211f_config_init(struct phy_device *phydev)
>  {
>         int ret;
>         u16 reg;
>
> -       ret = genphy_config_init(phydev);
> +       ret = rtl8211x_config_init(phydev);
>         if (ret < 0)
>                 return ret;
>
> @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct phy_device *phydev)
>         return 0;
>  }
>
> +static int rtl8211x_phy_probe(struct phy_device *phydev)
> +{
> +       struct device *dev = &phydev->mdio.dev;
> +       struct device_node *of_node = dev->of_node;
> +       struct rtl8211x_phy_priv *priv;
> +
> +       priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +       if (!priv)
> +               return -ENOMEM;
> +
> +       priv->eee_1000t_disable =
> +               of_property_read_bool(of_node, "realtek,disable-eee-1000t");
> +       priv->eee_100tx_disable =
> +               of_property_read_bool(of_node, "realtek,disable-eee-100tx");
> +
> +       phydev->priv = priv;
> +
> +       return 0;
> +}
> +
>  static struct phy_driver realtek_drvs[] = {
>         {
>                 .phy_id         = 0x00008201,
> @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
>                 .phy_id_mask    = 0x001fffff,
>                 .features       = PHY_GBIT_FEATURES,
>                 .flags          = PHY_HAS_INTERRUPT,
> +               .probe          = &rtl8211x_phy_probe,
>                 .config_aneg    = genphy_config_aneg,
> +               .config_init    = &rtl8211x_config_init,
>                 .read_status    = genphy_read_status,
>                 .ack_interrupt  = rtl821x_ack_interrupt,
>                 .config_intr    = rtl8211e_config_intr,
> @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
>                 .phy_id_mask    = 0x001fffff,
>                 .features       = PHY_GBIT_FEATURES,
>                 .flags          = PHY_HAS_INTERRUPT,
> +               .probe          = &rtl8211x_phy_probe,
>                 .config_aneg    = &genphy_config_aneg,
> +               .config_init    = &rtl8211x_config_init,
>                 .read_status    = &genphy_read_status,
>                 .ack_interrupt  = &rtl821x_ack_interrupt,
>                 .config_intr    = &rtl8211e_config_intr,
> @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
>                 .phy_id_mask    = 0x001fffff,
>                 .features       = PHY_GBIT_FEATURES,
>                 .flags          = PHY_HAS_INTERRUPT,
> +               .probe          = &rtl8211x_phy_probe,
>                 .config_aneg    = &genphy_config_aneg,
>                 .config_init    = &rtl8211f_config_init,
>                 .read_status    = &genphy_read_status,
> --
> 2.7.4
>

How about adding callback functionality for .soft_reset to handle BMCR
where we update the Auto-Negotiation for the phy,
as per the datasheet of the rtl8211f.

-Best Regard
Anand Moon

>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
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: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Florian Fainelli @ 2016-11-16 17:01 UTC (permalink / raw)
  To: Jerome Brunet, Andrew Lunn
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Carlo Caione, Kevin Hilman, Giuseppe Cavallaro, Alexandre TORGUE,
	Martin Blumenstingl, Andre Roth, Neil Armstrong,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479310731.17538.53.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

On 11/16/2016 07:38 AM, Jerome Brunet wrote:
> On Wed, 2016-11-16 at 16:06 +0100, Andrew Lunn wrote:
>> On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
>>>
>>> On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
>>>>
>>>>>
>>>>>
>>>>> There two kind of PHYs supporting eee, the one advertising eee
>>>>> by
>>>>> default (like realtek) and the one not advertising it (like
>>>>> micrel).
>>>
>>> This is just the default register value.
>>>
>>>>
>>>>
>>>> I don't know too much about EEE. So maybe a dumb question. Does
>>>> the
>>>> MAC need to be involved? Or is it just the PHY?
>>>>
>>>> If the MAC needs to be involved, the PHY should not be
>>>> advertising
>>>> EEE
>>>> unless the MAC asks for it by calling phy_init_eee(). If this is
>>>> true,
>>>> maybe we need to change the realtek driver, and others in that
>>>> class.
>>>
>>> As far I understand, the advertised capabilities are exchanged
>>> during
>>> the auto-negotiation.
>>>
>>> At this stage, if the advertisement is disabled (regarless of the
>>> actual support) on either side of the link, there will be no low
>>> power
>>> idle state on the Tx nor the Rx path.
>>>
>>> If the advertisement is enabled on both side but we don't call
>>> phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>>
>> What i was trying to find out is, if the MAC needs to support EEE as
>> well as the PHY, what happens when the MAC does not support EEE, but
>> the PHYs do negotiate EEE? Does it break?
> 
> Interesting question. In a regular case, I suppose it should be fine.
> As you would have LPI only on the Rx path this should be transparent to
> the MAC. That's my understanding. Maybe people knowing EEE better than
> me could confirm (or not) ? Peppe? Alexandre?

EEE is a MAC and PHY feature, and both need to agree on what is enabled,
especially in the transmit path because the way packets may be
transmitted with or without EEE can be done differently at the HW level
(faster/slower return to idle, different clock source).

> 
> I just checked with the OdroidC2, I disabled eee support by forcing
> "dma_cap.eee = 0" in stmmac_get_hw_features. As expected, no tx_LPI
> interrupts but plenty of rx_LPI interrupts.
> 
> What was not expected is test failing like before.
> So in our case, having LPI on the Rx path is fine for receiving data,
> but not for sending.

OK, which really sounds like a potential interoperability problem, or
just the Realtek PHY with EEE enabled acting funky (irrespective of
being attached to stmmac).
-- 
Florian
--
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: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump
From: Hannes Frederic Sowa @ 2016-11-16 16:56 UTC (permalink / raw)
  To: David Miller
  Cc: jiri, netdev, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz,
	roopa, dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
	alexander.h.duyck, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161116.112735.19078311822311561.davem@davemloft.net>

On 16.11.2016 17:27, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 16 Nov 2016 15:51:01 +0100
> 
>> I don't see a way around doing a journal like in filesystems somehow,
> 
> We really just need a sequence counter incremented for each insert/remove,
> and restart the dump from the beginning if it changes mid-dump.

I thought about this at first, too, but became afraid if we could end up
looping endlessly because of routing changes happen constantly while
trying to upload the fib into the hardware.

^ permalink raw reply

* Re: [PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Andrew Lunn @ 2016-11-16 16:54 UTC (permalink / raw)
  To: Alex; +Cc: f.fainelli, netdev, linux-kernel, davem, Gokhan Cosgul
In-Reply-To: <f05f5f5d-a010-def2-314a-09a859f9eda3@adaptrum.com>

On Wed, Nov 16, 2016 at 08:44:30AM -0800, Alex wrote:
> 
> 
> On 11/16/2016 05:50 AM, Andrew Lunn wrote:
> >On Wed, Nov 16, 2016 at 01:02:33AM -0800, Alexandru Gagniuc wrote:
> >>With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
> >>VSC8601 can handle this internally. While the VSC8601 can set more
> >>fine-grained delays, the standard skew settings work out of the box.
> >>The same heuristic is used to determine when this skew should be enabled
> >>as in vsc824x_config_init().
> >>
> >>+/* This adds a skew for both TX and RX clocks, so the skew should only be
> >>+ * applied to "rgmii-id" interfaces. It may not work as expected
> >>+ * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
> >
> >Hi Alexandru
> >
> >You should be able to make "rgmii" work as expected. If that is the
> >phy mode, disable the skew.
> 
> And that's exactly the implemented behavior. See
> vsc8601_config_init() below.

I don't think so. vsc8601_config_init() will not cause the skew to be
cleared if the phy-mode is "rgmii" and something else like the
bootloader could of set the skew. So saying that "rgmii" might not
work as expected is true. But with a minor change, you can make it
work as expected.

	Andrew

^ permalink raw reply

* Re: [PATCH v2] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Alex @ 2016-11-16 16:44 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: f.fainelli, netdev, linux-kernel, davem, Gokhan Cosgul
In-Reply-To: <20161116135053.GF19962@lunn.ch>



On 11/16/2016 05:50 AM, Andrew Lunn wrote:
> On Wed, Nov 16, 2016 at 01:02:33AM -0800, Alexandru Gagniuc wrote:
>> With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
>> VSC8601 can handle this internally. While the VSC8601 can set more
>> fine-grained delays, the standard skew settings work out of the box.
>> The same heuristic is used to determine when this skew should be enabled
>> as in vsc824x_config_init().
>>
>> +/* This adds a skew for both TX and RX clocks, so the skew should only be
>> + * applied to "rgmii-id" interfaces. It may not work as expected
>> + * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
>
> Hi Alexandru
>
> You should be able to make "rgmii" work as expected. If that is the
> phy mode, disable the skew.

And that's exactly the implemented behavior. See vsc8601_config_init() 
below.

Alex

^ permalink raw reply

* Re: [PATCH ipsec-next 6/8] xfrm: policy: only use rcu in xfrm_sk_policy_lookup
From: Nicolas Dichtel @ 2016-11-16 16:43 UTC (permalink / raw)
  To: Florian Westphal, netdev, Steffen Klassert
In-Reply-To: <1470921479-25592-7-git-send-email-fw@strlen.de>

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

Le 11/08/2016 à 15:17, Florian Westphal a écrit :
> Don't acquire the readlock anymore and rely on rcu alone.
> 
> In case writer on other CPU changed policy at the wrong moment (after we
> obtained sk policy pointer but before we could obtain the reference)
> just repeat the lookup.
> 
> Signed-off-by: Florian Westphal <fw@strlen.de>
Since this patch, our IKEv1 Transport tests (using charon) fail to establish the
connection. If I revert it, the IKE negociation is ok again.
charon logs are enclosed.

I didn't had time to investigate now, but any idea is welcomed ;-)

Regards,
Nicolas

[-- Attachment #2: charon.txt --]
[-- Type: text/plain, Size: 2343 bytes --]

/var/log/syslog:Nov 16 16:28:47 router charon: 04[CFG] received stroke: add connection 'mytunnel-17'
/var/log/syslog:Nov 16 16:28:47 router charon: 04[CFG] added configuration 'mytunnel-17'
/var/log/syslog:Nov 16 16:28:47 router charon: 08[CFG] received stroke: route 'mytunnel-17'
/var/log/syslog:Nov 16 16:28:52 router charon: 13[KNL] creating acquire job for policy 10.125.0.1/32[gre] === 10.125.0.2/32[gre] with reqid {1}
/var/log/syslog:Nov 16 16:28:52 router charon: 13[IKE] initiating Aggressive Mode IKE_SA mytunnel-17[1] to 10.125.0.2
/var/log/syslog:Nov 16 16:28:52 router charon: 13[ENC] generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
/var/log/syslog:Nov 16 16:28:52 router charon: 13[NET] sending packet: from 10.125.0.1[500] to 10.125.0.2[500] (548 bytes)
/var/log/syslog:Nov 16 16:28:56 router charon: 07[IKE] sending retransmit 1 of request message ID 0, seq 1
/var/log/syslog:Nov 16 16:28:56 router charon: 07[NET] sending packet: from 10.125.0.1[500] to 10.125.0.2[500] (548 bytes)
/var/log/syslog:Nov 16 16:29:04 router charon: 08[IKE] sending retransmit 2 of request message ID 0, seq 1
/var/log/syslog:Nov 16 16:29:04 router charon: 08[NET] sending packet: from 10.125.0.1[500] to 10.125.0.2[500] (548 bytes)
/var/log/syslog:Nov 16 16:29:17 router charon: 09[IKE] sending retransmit 3 of request message ID 0, seq 1
/var/log/syslog:Nov 16 16:29:17 router charon: 09[NET] sending packet: from 10.125.0.1[500] to 10.125.0.2[500] (548 bytes)
/var/log/syslog:Nov 16 16:29:40 router charon: 11[IKE] sending retransmit 4 of request message ID 0, seq 1
/var/log/syslog:Nov 16 16:29:40 router charon: 11[NET] sending packet: from 10.125.0.1[500] to 10.125.0.2[500] (548 bytes)
/var/log/syslog:Nov 16 16:30:22 router charon: 05[IKE] sending retransmit 5 of request message ID 0, seq 1
/var/log/syslog:Nov 16 16:30:22 router charon: 05[NET] sending packet: from 10.125.0.1[500] to 10.125.0.2[500] (548 bytes)
/var/log/syslog:Nov 16 16:31:37 router charon: 15[KNL] creating delete job for CHILD_SA ESP/0x00000000/10.125.0.2
/var/log/syslog:Nov 16 16:31:37 router charon: 13[JOB] CHILD_SA ESP/0x00000000/10.125.0.2 not found for delete
/var/log/syslog:Nov 16 16:31:38 router charon: 09[IKE] giving up after 5 retransmits
/var/log/syslog:Nov 16 16:31:38 router charon: 09[IKE] establishing IKE_SA failed, peer not responding

^ permalink raw reply

* Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump
From: Ido Schimmel @ 2016-11-16 16:42 UTC (permalink / raw)
  To: David Miller
  Cc: hannes, jiri, netdev, idosch, eladr, yotamg, nogahf, arkadis,
	ogerlitz, roopa, dsa, nikolay, andy, vivien.didelot, andrew,
	f.fainelli, alexander.h.duyck, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161116.112735.19078311822311561.davem@davemloft.net>

Hi Dave,

On Wed, Nov 16, 2016 at 11:27:35AM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 16 Nov 2016 15:51:01 +0100
> 
> > I don't see a way around doing a journal like in filesystems somehow,
> 
> We really just need a sequence counter incremented for each insert/remove,
> and restart the dump from the beginning if it changes mid-dump.

When you dump the FIB table your listener is already registered to the
chain, so any changes happening mid-dump will be propagated to it. I've
noted this in 5/8 and in my reply to Hannes.

^ permalink raw reply

* RE: [patch net-next v2 5/8] Introduce sample tc action
From: Yotam Gigi @ 2016-11-16 16:26 UTC (permalink / raw)
  To: Roopa Prabhu, Jiri Pirko
  Cc: netdev@vger.kernel.org, davem@davemloft.net, Ido Schimmel,
	Elad Raz, Nogah Frankel, Or Gerlitz, jhs@mojatatu.com,
	geert+renesas@glider.be, stephen@networkplumber.org,
	xiyou.wangcong@gmail.com, linux@roeck-us.net,
	john.fastabend@gmail.com, simon.horman@netronome.com
In-Reply-To: <582C861B.8010709@cumulusnetworks.com>

>-----Original Message-----
>From: Roopa Prabhu [mailto:roopa@cumulusnetworks.com]
>Sent: Wednesday, November 16, 2016 6:15 PM
>To: Jiri Pirko <jiri@resnulli.us>
>Cc: netdev@vger.kernel.org; davem@davemloft.net; Yotam Gigi
><yotamg@mellanox.com>; Ido Schimmel <idosch@mellanox.com>; Elad Raz
><eladr@mellanox.com>; Nogah Frankel <nogahf@mellanox.com>; Or Gerlitz
><ogerlitz@mellanox.com>; jhs@mojatatu.com; geert+renesas@glider.be;
>stephen@networkplumber.org; xiyou.wangcong@gmail.com; linux@roeck-us.net;
>john.fastabend@gmail.com; simon.horman@netronome.com
>Subject: Re: [patch net-next v2 5/8] Introduce sample tc action
>
>On 11/14/16, 7:00 AM, Jiri Pirko wrote:
>> From: Yotam Gigi <yotamg@mellanox.com>
>>
>> This action allow the user to sample traffic matched by tc classifier.
>> The sampling consists of choosing packets randomly, truncating them,
>> adding some informative metadata regarding the interface and the original
>> packet size and mark them with specific mark, to allow further tc rules to
>> match and process. The marked sample packets are then injected into the
>> device ingress qdisc using netif_receive_skb.
>>
>> The packets metadata is packed using the ife encapsulation protocol, and
>> the outer packet's ethernet dest, source and eth_type, along with the
>> rate, mark and the optional truncation size can be configured from
>> userspace.
>>
>> Example:
>> To sample ingress traffic from interface eth1, and redirect the sampled
>> the sampled packets to interface dummy0, one may use the commands:
>>
>> tc qdisc add dev eth1 handle ffff: ingress
>>
>> tc filter add dev eth1 parent ffff: \
>> 	   matchall action sample rate 12 mark 17
>
>Yotham, I am guessing in the future if one does not want to use mark,
>the sample api is extensible to allow for other actions to be added.
>This is from the general concern we had on using mark: some may not want to use
>mark.
>As long as the api is extensible to allow an alternate way in the future,
> we should be good. (We would prefer to not go down the path of having to
>introduce
>a new  'action sample' if this limits us in some way).

The code is extensible  - if one does want to add another action to sample, he 
totally can :)

By the way, one of the reasons we removed the patches for now is that we 
consider adding mirroring functionality to it instead of heaving two tc-rules.


>
>>
>> tc filter add parent ffff: dev eth1 protocol all \
>> 	   u32 match mark 17 0xff \
>> 	   action mirred egress redirect dev dummy0
>>
>
>thanks.

^ permalink raw reply

* Re: [patch net-next 0/8] ipv4: fib: Allow modules to dump FIB tables
From: Alexander Duyck @ 2016-11-16 16:38 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: Netdev, David Miller, idosch, eladr, yotamg, nogahf, arkadis,
	Or Gerlitz, roopa, David Ahern, nikolay, Andy Gospodarek,
	vivien.didelot, Andrew Lunn, Florian Fainelli, Duyck, Alexander H,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	kaber@trash.net
In-Reply-To: <1479305343-13167-1-git-send-email-jiri@resnulli.us>

On Wed, Nov 16, 2016 at 6:08 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Ido says:
>
> In kernel 4.9 the switchdev-specific FIB offload mechanism was replaced
> by a new FIB notification chain to which modules could register in order
> to be notified about the addition and deletion of FIB entries. The
> motivation for this change was that switchdev drivers need to be able to
> reflect the entire FIB table and not only FIBs configured on top of the
> port netdevs themselves. This is useful in case of in-band management.
>
> The fundamental problem with this approach is that upon registration
> listeners lose all the information previously sent in the chain and
> thus have an incomplete view of the FIB tables, which can result in
> packet loss. This patchset fixes that by introducing a new API to dump
> the FIB tables.
>
> The entire dump process is done under RCU and thus the FIB notification
> chain is converted to be atomic. The listeners are modified accordingly.
> This is done in the first five patches.
>
> The sixth patch adds the dump callback itself and the next patches call
> it from current listeners of the FIB notification chain.
>
> Ido Schimmel (8):
>   ipv4: fib: Export free_fib_info()
>   mlxsw: spectrum_router: Implement FIB offload in delayed work
>   rocker: Implement FIB offload in delayed work
>   ipv4: fib: Convert FIB notification chain to be atomic
>   net: ipv4: Send notifications only after removing FIB alias
>   ipv4: fib: Add an API to request a FIB dump
>   mlxsw: spectrum_router: Request a dump of FIB tables during init
>   rocker: Request a dump of FIB tables during init
>
>  drivers/net/ethernet/mellanox/mlxsw/core.c         |   6 +
>  drivers/net/ethernet/mellanox/mlxsw/core.h         |   1 +
>  .../net/ethernet/mellanox/mlxsw/spectrum_router.c  |  73 ++++++++++--
>  drivers/net/ethernet/rocker/rocker_main.c          |  59 ++++++++--
>  drivers/net/ethernet/rocker/rocker_ofdpa.c         |   1 +
>  include/net/ip_fib.h                               |   1 +
>  net/ipv4/fib_semantics.c                           |   1 +
>  net/ipv4/fib_trie.c                                | 128 +++++++++++++++++++--
>  8 files changed, 242 insertions(+), 28 deletions(-)
>

So for the pieces related to the fib_trie itself this patch series
looks good to me.

Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>

^ permalink raw reply

* Re: [PATCH] netronome: don't access real_num_rx_queues directly
From: Jakub Kicinski @ 2016-11-16 16:37 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: David S. Miller, oss-drivers, netdev
In-Reply-To: <20161116141118.1893244-1-arnd@arndb.de>

On Wed, Nov 16, 2016 at 6:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The netdev->real_num_rx_queues setting is only available if CONFIG_SYSFS
> is enabled, so we now get a build failure when that is turned off:
>
> netronome/nfp/nfp_net_common.c: In function 'nfp_net_ring_swap_enable':
> netronome/nfp/nfp_net_common.c:2489:18: error: 'struct net_device' has no member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'?
>
> As far as I can tell, the check here is only used as an optimization that
> we can skip in order to fix the compilation. If sysfs is disabled,
> the following netif_set_real_num_rx_queues() has no effect.
>
> Fixes: 164d1e9e5d52 ("nfp: add support for ethtool .set_channels")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>

Thanks Arnd!  This is needed in net-next only.

^ permalink raw reply

* Re: [PATCH net-next] bpf: Fix compilation warning in __bpf_lru_list_rotate_inactive
From: David Miller @ 2016-11-16 16:32 UTC (permalink / raw)
  To: kafai; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <1479236404-3906780-1-git-send-email-kafai@fb.com>

From: Martin KaFai Lau <kafai@fb.com>
Date: Tue, 15 Nov 2016 11:00:04 -0800

> gcc-6.2.1 gives the following warning:
> kernel/bpf/bpf_lru_list.c: In function ‘__bpf_lru_list_rotate_inactive.isra.3’:
> kernel/bpf/bpf_lru_list.c:201:28: warning: ‘next’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> The "next" is currently initialized in the while() loop which must have >=1
> iterations.
> 
> This patch initializes next to get rid of the compiler warning.
> 
> Fixes: 3a08c2fd7634 ("bpf: LRU List")
> Reported-by: David Miller <davem@davemloft.net>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next 1/1] ipv6: sr: add option to control lwtunnel support
From: David Miller @ 2016-11-16 16:32 UTC (permalink / raw)
  To: david.lebrun; +Cc: netdev, lorenzo, roopa
In-Reply-To: <1479222844-20301-1-git-send-email-david.lebrun@uclouvain.be>

From: David Lebrun <david.lebrun@uclouvain.be>
Date: Tue, 15 Nov 2016 16:14:04 +0100

> This patch adds a new option CONFIG_IPV6_SEG6_LWTUNNEL to enable/disable
> support of encapsulation with the lightweight tunnels. When this option
> is enabled, CONFIG_LWTUNNEL is automatically selected.
> 
> Fix commit 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
> 
> Without a proper option to control lwtunnel support for SR-IPv6, if
> CONFIG_LWTUNNEL=n then the IPv6 initialization fails as a consequence
> of seg6_iptunnel_init() failure with EOPNOTSUPP:
> 
> NET: Registered protocol family 10
> IPv6: Attempt to unregister permanent protocol 6
> IPv6: Attempt to unregister permanent protocol 136
> IPv6: Attempt to unregister permanent protocol 17
> NET: Unregistered protocol family 10
> 
> Tested (compiling, booting, and loading ipv6 module when relevant)
> with possible combinations of CONFIG_IPV6={y,m,n},
> CONFIG_IPV6_SEG6_LWTUNNEL={y,n} and CONFIG_LWTUNNEL={y,n}.
> 
> Reported-by: Lorenzo Colitti <lorenzo@google.com>
> Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>

Applied.

^ permalink raw reply

* Re: [PATCH net-next v2] ipv6: sr: fix IPv6 initialization failure without lwtunnels
From: David Miller @ 2016-11-16 16:31 UTC (permalink / raw)
  To: roopa; +Cc: david.lebrun, netdev, lorenzo
In-Reply-To: <582C7FFF.70203@cumulusnetworks.com>

From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Wed, 16 Nov 2016 07:49:19 -0800

> On 11/15/16, 7:18 AM, David Miller wrote:
>> Although I'd like to entertain the idea of making LWTUNNEL
>> unconditionally built and considered a fundamental piece of
>> networking infrastructure just like net/core/dst.c
> ok, ack. I can submit a patch for that. But, I had the lwtunnel infra hooks in
> CONFIG_LWTUNNEL to reduce the cost of hooks in the default fast path when it was not enabled.
> Will need to re-evaluate the cost of the hooks in the default fast-path.
 ...
> I am assuming you are ok with various encaps staying in their
> respective configs (mpls iptunnels, ila, and now ipv6 segment
> routing).

Yes.

^ permalink raw reply

* Re: net/l2tp:BUG: KASAN: use-after-free in l2tp_ip6_close
From: Guillaume Nault @ 2016-11-16 16:30 UTC (permalink / raw)
  To: Baozeng Ding; +Cc: Cong Wang, Linux Kernel Network Developers
In-Reply-To: <76f028b3-cf56-5526-352f-ff4826933779@gmail.com>

On Wed, Oct 19, 2016 at 10:52:03PM +0800, Baozeng Ding wrote:
> This use-after-free seems to be triggered by some race. I use stress tool for this: 
> https://github.com/golang/tools/blob/master/cmd/stress/stress.go 
> If you have Go toolchain installed, then the following will do: 
> $ go get golang.org/x/tools/cmd/stress 
> $ stress ./a.out
> 
> =========================================================================
> #include <unistd.h>
> #include <stdint.h>
> #include <pthread.h>
> #include <stdio.h>
> #include <sys/socket.h>
> #include <linux/l2tp.h>
> 
> int fd;
> struct sockaddr_l2tpip sock_addr = {
>         .l2tp_family = AF_INET,
>         .l2tp_unused = 0,
>         .l2tp_addr = 0,
>         .l2tp_conn_id = 8,
>         .__pad = 0
> 
> };
> 
> void *thr(void *arg)
> {
>         switch ((long)arg) {
>         case 0:
>                 fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_L2TP);
>                 break;
>         case 1:
>                 bind(fd, (struct sockaddr*) &sock_addr, 0x10ul);
>                 break;
>         case 2:
>                 bind(fd, (struct sockaddr*)&sock_addr, 0x10ul);
>                 break;
>         case 3:
>                 connect(fd, (struct sockaddr*)&sock_addr, 0x10ul);
>                 break;
>         }
>         return 0;
> }
> 
> int main()
> {
>         long i;
>         pthread_t th[4];
>         int n;
>         for (i = 0; i < 4; i++) {
>                pthread_create(&th[i], 0, thr, (void*)i);
>                usleep(10000);
>         }
>         for (i = 0; i < 4; i++) {
>                pthread_create(&th[i], 0, thr, (void*)i);
>                if (i%2==0)
>                         usleep(10000);
>         }
>         usleep(100000);
>         return 0;
> }
> 
This program targets l2tp_ip while the call trace is about l2tp_ip6. But it
looks like we have the same issue in both modules anyway.

> On 2016/10/17 3:50, Cong Wang wrote:
> > On Sun, Oct 16, 2016 at 8:07 AM, Baozeng Ding <sploving1@gmail.com> wrote:
> >> Hello,
> >> While running syzkaller fuzzer I have got the following use-after-free
> >> bug in l2tp_ip6_close. The kernel version is 4.8.0+ (on Oct 7 commit d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0).
> >>
> >> BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8
> >> Write of size 8 by task syz-executor/10987
> >> CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39
> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> >>  ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0
> >>  ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc
> >>  ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0
> >> Call Trace:
> >>  [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
> >>  [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
> >>  [<     inline     >] print_address_description mm/kasan/report.c:194
> >>  [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
> >>  [<     inline     >] kasan_report mm/kasan/report.c:303
> >>  [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
> >>  [<     inline     >] __write_once_size ./include/linux/compiler.h:249
> >>  [<     inline     >] __hlist_del ./include/linux/list.h:622
> >>  [<     inline     >] hlist_del_init ./include/linux/list.h:637
> >>  [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239
> > 
> > 
> > This one looks pretty interesting, how the hell could we call ____fput() twice
> > on the same fd...
> > 
> > 
> >>  [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
> >>  [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
> >>  [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
> >>  [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
> >>  [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
> >>  [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
> >>  [<ffffffff813774f9>] task_work_run+0xf9/0x170
> >>  [<ffffffff81324aae>] do_exit+0x85e/0x2a00
> >>  [<ffffffff81326dc8>] do_group_exit+0x108/0x330
> >>  [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
> >>  [<ffffffff811b49af>] do_signal+0x7f/0x18f0
> >>  [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
> >>  [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
> >>  [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
> >>  [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
> >> Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448
> >> Allocated:
> >> PID = 10987
> >>  [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
> >>  [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
> >>  [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
> >>  [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
> >>  [ 1116.897025] [<     inline     >] slab_post_alloc_hook mm/slab.h:417
> >>  [ 1116.897025] [<     inline     >] slab_alloc_node mm/slub.c:2708
> >>  [ 1116.897025] [<     inline     >] slab_alloc mm/slub.c:2716
> >>  [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
> >>  [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
> >>  [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
> >>  [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
> >>  [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
> >>  [ 1116.897025] [<     inline     >] sock_create net/socket.c:1193
> >>  [ 1116.897025] [<     inline     >] SYSC_socket net/socket.c:1223
> >>  [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
> >>  [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
> >> Freed:
> >> PID = 10987
> >>  [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
> >>  [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
> >>  [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
> >>  [ 1116.897025] [<     inline     >] slab_free_hook mm/slub.c:1352
> >>  [ 1116.897025] [<     inline     >] slab_free_freelist_hook mm/slub.c:1374
> >>  [ 1116.897025] [<     inline     >] slab_free mm/slub.c:2951
> >>  [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
> >>  [ 1116.897025] [<     inline     >] sk_prot_free net/core/sock.c:1369
> >>  [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
> >>  [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
> >>  [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
> >>  [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
> >>  [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
> >>  [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243
> >>  [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
> >>  [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
> >>  [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
> >>  [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
> >>  [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
> >>  [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
> >>  [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170
> >>  [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
> >>  [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
> >>  [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
> >>  [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
> >>  [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
> >>  [ 1116.897025] [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
> >>  [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
> >>  [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
> >> Memory state around the buggy address:
> >>  ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >>  ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >>> ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> >>                                                     ^
> >>  ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >>  ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ==================================================================
> >>

This looks very much like the one reported by Andrey a few days ago:
https://marc.info/?l=linux-netdev&m=147855869227527&w=2

The following patch should fix both l2tp_ip and l2tp_ip6:

diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index fce25af..982f6c4 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -251,8 +251,6 @@ static int l2tp_ip_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
        int ret;
        int chk_addr_ret;
 
-       if (!sock_flag(sk, SOCK_ZAPPED))
-               return -EINVAL;
        if (addr_len < sizeof(struct sockaddr_l2tpip))
                return -EINVAL;
        if (addr->l2tp_family != AF_INET)
@@ -267,6 +265,9 @@ static int l2tp_ip_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
        read_unlock_bh(&l2tp_ip_lock);
 
        lock_sock(sk);
+       if (!sock_flag(sk, SOCK_ZAPPED))
+               goto out;
+
        if (sk->sk_state != TCP_CLOSE || addr_len < sizeof(struct sockaddr_l2tpip))
                goto out;
 
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index ad3468c..9978d01 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -269,8 +269,6 @@ static int l2tp_ip6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
        int addr_type;
        int err;
 
-       if (!sock_flag(sk, SOCK_ZAPPED))
-               return -EINVAL;
        if (addr->l2tp_family != AF_INET6)
                return -EINVAL;
        if (addr_len < sizeof(*addr))
@@ -296,6 +294,9 @@ static int l2tp_ip6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
        lock_sock(sk);
 
        err = -EINVAL;
+       if (!sock_flag(sk, SOCK_ZAPPED))
+               goto out_unlock;
+
        if (sk->sk_state != TCP_CLOSE)
                goto out_unlock;

^ permalink raw reply related

* Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump
From: David Miller @ 2016-11-16 16:27 UTC (permalink / raw)
  To: hannes
  Cc: jiri, netdev, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz,
	roopa, dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
	alexander.h.duyck, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <e795e6e0-a680-a2c3-7d5e-afd966104a4a@stressinduktion.org>

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 16 Nov 2016 15:51:01 +0100

> I don't see a way around doing a journal like in filesystems somehow,

We really just need a sequence counter incremented for each insert/remove,
and restart the dump from the beginning if it changes mid-dump.

^ permalink raw reply

* Re: [PATCH] igmp: Make igmp group member RFC 3376 compliant
From: David Miller @ 2016-11-16 16:19 UTC (permalink / raw)
  To: haliu; +Cc: mtesar, kuznet, jmorris, kaber, netdev
In-Reply-To: <20161116062045.GB17935@leo.usersys.redhat.com>

From: Hangbin Liu <haliu@redhat.com>
Date: Wed, 16 Nov 2016 14:20:45 +0800

> Hi David,
> 
> On Tue, Nov 08, 2016 at 10:26:25AM +0100, Michal Tesar wrote:
>> On Mon, Nov 07, 2016 at 08:13:45PM -0500, David Miller wrote:
>> 
>> > From: Michal Tesar <mtesar@redhat.com>
>> > Date: Thu, 3 Nov 2016 10:38:34 +0100
>> > 
>> > >  2. If the received Query is a General Query, the interface timer is
>> > >     used to schedule a response to the General Query after the
>> > >     selected delay.  Any previously pending response to a General
>> > >     Query is canceled.
>> > > --8<--
>> > > 
>> > > Currently the timer is rearmed with new random expiration time for
>> > > every incoming query regardless of possibly already pending report.
>> > > Which is not aligned with the above RFE.
>> > 
>> > I don't read it that way.  #2 says if this is a general query then any
>> > pending response to a general query is cancelled.  And that's
>> > effectively what the code is doing right now.
>> 
>> Hi David,
>> I think that it is important to notice that the RFC says also 
>> that only the first matching rule is applied.
>> 
>> "
>> When new Query with the Router-Alert option arrives on an
>> interface, provided the system has state to report, a delay for a
>> response is randomly selected in the range (0, [Max Resp Time]) where
>> Max Resp Time is derived from Max Resp Code in the received Query
>> message.  The following rules are then used to determine if a Report
>> needs to be scheduled and the type of Report to schedule.  The rules
>> are considered in order and only the first matching rule is applied.
> 
>  ^^
> 
> Would you like to reconsider about this? I also agree with Michal that we
> need to choose the sooner timer. Or if we receive query very quickly, we
> will keep refresh the timer and may never reply the report.

I'm still thinking about this, please be patient, I review a hundred
patches or more per day so it takes me time to get to tasks that
require deep thinking or real consideration on any level.

^ permalink raw reply

* Re: [patch net-next v2 5/8] Introduce sample tc action
From: Roopa Prabhu @ 2016-11-16 16:15 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: netdev, davem, yotamg, idosch, eladr, nogahf, ogerlitz, jhs,
	geert+renesas, stephen, xiyou.wangcong, linux, john.fastabend,
	simon.horman
In-Reply-To: <1479135638-3580-6-git-send-email-jiri@resnulli.us>

On 11/14/16, 7:00 AM, Jiri Pirko wrote:
> From: Yotam Gigi <yotamg@mellanox.com>
>
> This action allow the user to sample traffic matched by tc classifier.
> The sampling consists of choosing packets randomly, truncating them,
> adding some informative metadata regarding the interface and the original
> packet size and mark them with specific mark, to allow further tc rules to
> match and process. The marked sample packets are then injected into the
> device ingress qdisc using netif_receive_skb.
>
> The packets metadata is packed using the ife encapsulation protocol, and
> the outer packet's ethernet dest, source and eth_type, along with the
> rate, mark and the optional truncation size can be configured from
> userspace.
>
> Example:
> To sample ingress traffic from interface eth1, and redirect the sampled
> the sampled packets to interface dummy0, one may use the commands:
>
> tc qdisc add dev eth1 handle ffff: ingress
>
> tc filter add dev eth1 parent ffff: \
> 	   matchall action sample rate 12 mark 17

Yotham, I am guessing in the future if one does not want to use mark,
the sample api is extensible to allow for other actions to be added.
This is from the general concern we had on using mark: some may not want to use mark.
As long as the api is extensible to allow an alternate way in the future,
 we should be good. (We would prefer to not go down the path of having to introduce
a new  'action sample' if this limits us in some way).

>
> tc filter add parent ffff: dev eth1 protocol all \
> 	   u32 match mark 17 0xff \
> 	   action mirred egress redirect dev dummy0
>

thanks.

^ 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