* Re: [PATCH net-next v12] openvswitch: enable NSH support
From: Jiri Benc @ 2017-10-19 12:43 UTC (permalink / raw)
To: Yang, Yi
Cc: netdev@vger.kernel.org, dev@openvswitch.org, e@erig.me,
pshelar@ovn.org, davem@davemloft.net
In-Reply-To: <20171019114052.GA83037@cran64.bj.intel.com>
On Thu, 19 Oct 2017 19:40:53 +0800, Yang, Yi wrote:
> Actually mdtype can't be set, only push_nsh can set mdtype, so set_nsh
> won't have mdtype flow key, we can't get it from flow_key in set_nsh,
> only ttl, flags and path_hdr can be set in set_nsh as you can see in code.
> I understand your concern is calling skb_ensure_writable twice, so
> changing the first one to pskb_may_pull is more appropriate for set_nsh.
Isn't set_nsh called only after the packet was already dissected (i.e.
parse_nsh called)? The dissected fields should be available in flow_key.
Jiri
^ permalink raw reply
* Re: Linux ECN Handling
From: Florian Westphal @ 2017-10-19 12:43 UTC (permalink / raw)
To: Steve Ibanez
Cc: ncardwell, daniel, Mohammad Alizadeh, Nick McKeown, Lavanya Jose,
netdev
In-Reply-To: <CACJspmLFdy9i8K=TkzXHnofyFMNoJf9HkYE7On8uG+PREc2Dqw@mail.gmail.com>
[ full-quoting due to Cc fixups, adding netdev ]
Steve Ibanez <sibanez@stanford.edu> wrote:
> Hi Florian, Neal, and Daniel,
>
> I hope this email finds you well. My name is Stephen Ibanez and I'm a PhD
> Student at Stanford currently working on a project with Mohammad Alizadeh,
> Nick McKeown, and Lavanya Jose. We have been doing some experiments using
> the linux DCTCP implementation and are trying to understand some strange
> behavior that we are encountering. I'm contacting you three because I have
> seen your names on some of the source files and recent commits in the linux
> source tree. Hopefully you can help us out or put us in contact with the
> right people?
>
> Here are some details about our servers:
>
> - Distribution: Ubuntu 14.04 LTS
> - Kernel release: 4.4.0-75-generic
Can you re-test with a more recent kernel such as 4.13.8?
> *The experiment:*
>
> We use iperf3 to generate two DCTCP flows from different servers to a
> common server, as shown in the diagram below. We measure the sending rate
> of each flow, record the tcp_probe output, as well as run tcpdump on the
> source host interfaces.
>
> [image: Inline image 6]
>
> *The problem:*
>
> Our rate measurements look like the one shown below; the flows often enter
> timeouts. In this case, both flows hit a timeout at t=0.3.
> [image: Inline image 2]
>
> When looking at the sequence of packets seen at the source host interfaces
> around this timeout event this is what we see:
>
> *10.0.0.1 timeout event:*
> [image: Inline image 3]
>
> *10.0.0.3 timeout event:*
> [image: Inline image 4]
>
> In both cases, the source:
> (1) receives an ACK for byte XYZ with the ECN flag set
> (2) stops sending anything for RTO_min=300ms
> (3) sends a retransmission for byte XYZ
>
> I have verified that this behavior is consistent across multiple experiment
> runs. Here are the CWND samples for the 10.0.0.1 flow provided by tcp_probe
> at the time of the timeout event:
>
> [image: Inline image 5]
>
> From what I can tell, tcp_probe logs a sample whenever a packet is
> received. If this is true, then that means when the source receives the
> final ECN marked ACK just before the timeout the CWND=1 MSS.
>
> *The conclusion:*
>
> We believe that there may be an issue with how the linux kernel is handling
> the ECN echoes. For DCTCP, if the CWND is 1 MSS and the end host is still
> receiving ECN marks then the CWND should remain at 1 MSS and should *not*
> enter a timeout. This is because the switch can perform ECN marking very
> aggressively causing the source end host to receive many redundant ECN
> echoes over a short period of time.
>
> Another potential issue is that from the CWND plot above it looks like the
> end host may be reacting to congestion signals more than once per window,
> which should not happen (section 5 of RF3168
> <https://tools.ietf.org/html/rfc3168>). tcp_probe reports SRTT measurements
> of about 400-500 us and in the plot above the CWND is reduced 6 times
> within this amount of time.
>
> We have not yet tracked down the code path in the kernel code that is
> causing the behavior described above. Perhaps this is something that you
> can help us with? We would love to hear your thoughts on this matter and
> are happy to try other experiments that you suggest.
>
> Here is a link
> <https://drive.google.com/file/d/0Bw-GEX7h5ufiYmpCV2VpOGEtQWs/view?usp=sharing>
> to
> download the packet traces if you would like to take a look.
> han-1_host.pcap is the trace from 10.0.0.1 and han-3_host.pcap is the trace
> from 10.0.0.3.
>
> Looking forward to hearing from you!
>
> Best,
> -Steve
^ permalink raw reply
* Re: [PATCH] dql: make dql_init return void
From: David Miller @ 2017-10-19 12:34 UTC (permalink / raw)
To: stephen; +Cc: tom, shimoda.hiroaki, netdev, sthemmin
In-Reply-To: <20171018001652.23740-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 17 Oct 2017 17:16:52 -0700
> dql_init always returned 0, and the only place that uses it
> in network core code didn't care about the return value anyway.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net: l2tp: mark expected switch fall-through
From: David Miller @ 2017-10-19 12:34 UTC (permalink / raw)
To: garsilva; +Cc: netdev, linux-kernel
In-Reply-To: <20171017224253.GA5877@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Tue, 17 Oct 2017 17:42:53 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case I replaced the "NOBREAK" comment with
> a "fall through" comment, which is what GCC is expecting to find.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v3 net-next] tcp: Remove use of daddr_cache in tracepoint
From: David Miller @ 2017-10-19 12:32 UTC (permalink / raw)
To: dsahern; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <1508270973-23789-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Tue, 17 Oct 2017 13:09:33 -0700
> Running perf in one window to capture tcp_retransmit_skb tracepoint:
> $ perf record -e tcp:tcp_retransmit_skb -a
>
> And causing a retransmission on an active TCP session (e.g., dropping
> packets in the receiver, changing MTU on the interface to 500 and back
> to 1500) triggers a panic:
...
> Remove use of ipv6_pinfo in favor of data in sock_common.
>
> Fixes: e086101b150a ("tcp: add a tracepoint for tcp retransmission")
> Signed-off-by: David Ahern <dsahern@gmail.com>
This doesn't apply to net-next, please respin.
Thanks.
^ permalink raw reply
* Re: [PATCH net] dccp/tcp: fix ireq->opt races
From: David Miller @ 2017-10-19 12:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, edumazet
In-Reply-To: <1508269526.31614.113.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Oct 2017 12:45:26 -0700
> syzkaller found another bug in DCCP/TCP stacks [1]
>
> For the reasons explained in commit ce1050089c96 ("tcp/dccp: fix
> ireq->pktopts race"), we need to make sure we do not access
> ireq->opt unless we own the request sock.
This doesn't apply to 'net'.
[davem@kkuri net]$ git am --signoff v2-net-dccp-tcp-fix-ireq--opt-races.patch
Applying: dccp/tcp: fix ireq->opt races
error: patch failed: include/net/inet_sock.h:96
error: include/net/inet_sock.h: patch does not apply
error: patch failed: net/dccp/ipv4.c:414
error: net/dccp/ipv4.c: patch does not apply
error: patch failed: net/ipv4/inet_connection_sock.c:540
error: net/ipv4/inet_connection_sock.c: patch does not apply
error: patch failed: net/ipv4/syncookies.c:355
error: net/ipv4/syncookies.c: patch does not apply
error: patch failed: net/ipv4/tcp_input.c:6196
error: net/ipv4/tcp_input.c: patch does not apply
error: patch failed: net/ipv4/tcp_ipv4.c:877
error: net/ipv4/tcp_ipv4.c: patch does not apply
^ permalink raw reply
* Re: [PATCH 2/2] liquidio: mark expected switch fall-through in octeon_destroy_resources
From: David Miller @ 2017-10-19 12:28 UTC (permalink / raw)
To: garsilva
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, linux-kernel, garsilva
In-Reply-To: <20171017190145.GA17015@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Tue, 17 Oct 2017 14:01:45 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 1/2] liquidio: remove unnecessary NULL check before kfree in delete_glists
From: David Miller @ 2017-10-19 12:28 UTC (permalink / raw)
To: garsilva
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, linux-kernel, garsilva
In-Reply-To: <20171017185920.GA16976@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Tue, 17 Oct 2017 13:59:20 -0500
> NULL check before freeing functions like kfree is not needed.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net/ethernet/sgi: Code cleanup
From: David Miller @ 2017-10-19 12:27 UTC (permalink / raw)
To: kumba; +Cc: ralf, linux-mips, netdev, tglx, linux-kernel
In-Reply-To: <53f0ad54-514a-b572-5801-7bd237055f86@gentoo.org>
From: Joshua Kinard <kumba@gentoo.org>
Date: Tue, 17 Oct 2017 13:54:30 -0400
> From: Joshua Kinard <kumba@gentoo.org>
>
> The below patch attempts to clean up the code for the in-tree driver
> for IOC3 ethernet and serial console support, primarily used by SGI
> MIPS platforms. Notable changes include:
>
> - Lots of whitespace cleanup
> - Using shorthand integer types (u16, u32, etc) where appropriate
These seem to be arbitrary, "unsigned int" is a fine value for a
hash computation.
You're also making many different kinds of changes in one patch
which makes it very difficult to review.
This driver is also for such ancient hardware, that the risk
of potentially breaking the driver far outweighs the value of
"cleaning up" the code.
^ permalink raw reply
* Re: [patch net-next 01/20] net: sched: add block bind/unbind notif. and extended block_get/put
From: David Miller @ 2017-10-19 12:23 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, jeffrey.t.kirsher, saeedm,
matanb, leonro, idosch, jakub.kicinski, ast, daniel, simon.horman,
pieter.jansenvanvuuren, john.hurley, alexander.h.duyck
In-Reply-To: <20171017200615.4530-2-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 17 Oct 2017 22:05:56 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Introduce new type of ndo_setup_tc message to propage binding/unbinding
> of a block to driver. Call this ndo whenever qdisc gets/puts a block.
> Alongside with this, there's need to propagate binder type from qdisc
> code down to the notifier. So introduce extended variants of
> block_get/put in order to pass this info.
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/linux/netdevice.h | 1 +
> include/net/pkt_cls.h | 40 +++++++++++++++++++++++++++++++++
> net/sched/cls_api.c | 56 ++++++++++++++++++++++++++++++++++++++++++++---
> 3 files changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 31bb301..062a4f5 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -771,6 +771,7 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
>
> enum tc_setup_type {
> TC_SETUP_MQPRIO,
> + TC_SETUP_BLOCK,
> TC_SETUP_CLSU32,
> TC_SETUP_CLSFLOWER,
> TC_SETUP_CLSMATCHALL,
Like David I think you should add this to the end of the list.
If you don't "think" about backporting issues when doing upstream
work, you're not "think"ing about some of the people who end up using
your code.
Thank you.
^ permalink raw reply
* [PATCH v2] udp: make some messages more descriptive
From: Matteo Croce @ 2017-10-19 12:22 UTC (permalink / raw)
To: netdev, David Miller
In-Reply-To: <20171017164812.21503-1-mcroce@redhat.com>
In the UDP code there are two leftover error messages with very few meaning.
Replace them with a more descriptive error message as some users
reported them as "strange network error".
Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
v2: added proper signed off tag
net/ipv4/udp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index e45177ceb0ee..806b298a3bdd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1061,7 +1061,7 @@ int udp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
/* ... which is an evident application bug. --ANK */
release_sock(sk);
- net_dbg_ratelimited("cork app bug 2\n");
+ net_dbg_ratelimited("socket already corked\n");
err = -EINVAL;
goto out;
}
@@ -1144,7 +1144,7 @@ int udp_sendpage(struct sock *sk, struct page *page, int offset,
if (unlikely(!up->pending)) {
release_sock(sk);
- net_dbg_ratelimited("udp cork app bug 3\n");
+ net_dbg_ratelimited("cork failed\n");
return -EINVAL;
}
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net-next 0/3] ibmvnic: Enable SG and TSO feature support
From: David Miller @ 2017-10-19 12:20 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev
In-Reply-To: <1508261816-3145-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Tue, 17 Oct 2017 12:36:53 -0500
> This patch set is fairly straightforward. The first patch enables
> scatter-gather support in the ibmvnic driver. The following patch
> then enables the TCP Segmentation offload feature. The final patch
> allows users to enable or disable net device features using ethtool.
>
> Enabling SG and TSO grants a large increase in throughput with TX
> speed increasing from 1Gb/s to 9Gb/s in our initial test runs.
Series applied.
^ permalink raw reply
* Re: Linux 4.12+ memory leak on router with i40e NICs
From: Anders K. Pedersen | Cohaesio @ 2017-10-19 12:19 UTC (permalink / raw)
To: pstaszewski@itcare.pl, alexander.duyck@gmail.com
Cc: netdev@vger.kernel.org, pavlos.parissis@gmail.com,
intel-wired-lan@lists.osuosl.org, alexander.h.duyck@intel.com
In-Reply-To: <CAKgT0Ud=GRrsNtoM0gOgzsh1uPJ7nuT9S-xbigmbUMi+iz-ufw@mail.gmail.com>
Hi Alex,
On ons, 2017-10-18 at 16:37 -0700, Alexander Duyck wrote:
> When we last talked I had asked if you could do a git bisect to find
> the memory leak and you said you would look into it. The most useful
> way to solve this would be to do a git bisect between your current
> kernel and the 4.11 kernel to find the point at which this started.
> If
> we can do that then fixing this becomes much simpler as we just have
> to fix the patch that introduced the issue.
We're also seeing a smaller memory leak (about 1 GB per day) than the
original one even with the "Fix memory leak related filter programming
status" fix applied. So far I've determined that the leak is present on
4.13.7 and was introduced between 4.11 and 4.12, so I'll do another
round of bisection to identify the patch that introduced this.
Since the router must run for a couple of hours before I can be sure
whether a kernel is good or bad, and I can't reboot it during working
hours, it'll probably be about a week before I have a result.
--
Venlig hilsen / Best Regards
Anders K. Pedersen
Senior Technical Manager
Cohaesio A/S email: akp@cohaesio.com
Parken | Per Henrik Lings Allé 4, 4 main: +45 45 88 08 88
DK-2100 Copenhagen | Denmark direct: +45 45 20 78 11
Visit us at www.cohaesio.com
Cohaesio is a leading IT solutions provider in Scandinavia, providing
certified IT outsourcing, service desk and managed hosting solutions to
professional customers.
^ permalink raw reply
* Re: [PATCH net-next] tun: relax check on eth_get_headlen() return value
From: David Miller @ 2017-10-19 12:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, peterpenkov96
In-Reply-To: <1508260064.31614.108.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Oct 2017 10:07:44 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> syzkaller hit the WARN() in tun_get_user(), providing skb
> with payload in fragments only, and nothing in skb->head
>
> GRO layer is fine with this, so relax the check.
>
> Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] udp: make some messages more descriptive
From: David Miller @ 2017-10-19 12:17 UTC (permalink / raw)
To: mcroce; +Cc: netdev
In-Reply-To: <20171017164812.21503-1-mcroce@redhat.com>
From: Matteo Croce <mcroce@redhat.com>
Date: Tue, 17 Oct 2017 18:48:12 +0200
> In the UDP code there are two leftover error messages with very few meaning.
> Replace them with a more descriptive error message as some users
> reported them as "strange network error".
Please repost with a proper signoff.
^ permalink raw reply
* Re: [PATCH net] sctp: do not peel off an assoc from one netns to another one
From: David Miller @ 2017-10-19 12:16 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, chunwang, syzkaller
In-Reply-To: <e637d68ce6f4f94dce8cb30c647e672ebb1f0b7b.1508253970.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 17 Oct 2017 23:26:10 +0800
> Now when peeling off an association to the sock in another netns, all
> transports in this assoc are not to be rehashed and keep use the old
> key in hashtable.
>
> As a transport uses sk->net as the hash key to insert into hashtable,
> it would miss removing these transports from hashtable due to the new
> netns when closing the sock and all transports are being freeed, then
> later an use-after-free issue could be caused when looking up an asoc
> and dereferencing those transports.
>
> This is a very old issue since very beginning, ChunYu found it with
> syzkaller fuzz testing with this series:
>
> socket$inet6_sctp()
> bind$inet6()
> sendto$inet6()
> unshare(0x40000000)
> getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
> getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
>
> This patch is to block this call when peeling one assoc off from one
> netns to another one, so that the netns of all transport would not
> go out-sync with the key in hashtable.
>
> Note that this patch didn't fix it by rehashing transports, as it's
> difficult to handle the situation when the tuple is already in use
> in the new netns. Besides, no one would like to peel off one assoc
> to another netns, considering ipaddrs, ifaces, etc. are usually
> different.
>
> Reported-by: ChunYu Wang <chunwang@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH][next] mqprio: fix potential null pointer dereference on opt
From: David Miller @ 2017-10-19 12:15 UTC (permalink / raw)
To: colin.king
Cc: jhs, xiyou.wangcong, jiri, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171017150130.23606-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 17 Oct 2017 16:01:30 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The pointer opt has a null check however before for this check opt is
> dereferenced when len is initialized, hence we potentially have a null
> pointer deference on opt. Avoid this by checking for a null opt before
> dereferencing it.
>
> Detected by CoverityScan, CID#1458234 ("Dereference before null check")
>
> Fixes: 4e8b86c06269 ("mqprio: Introduce new hardware offload mode and shaper in mqprio")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat
From: David Miller @ 2017-10-19 12:14 UTC (permalink / raw)
To: daniel
Cc: tj, ast, john.fastabend, mark.rutland, richard, sp3485, netdev,
linux-kernel
In-Reply-To: <cover.1508251210.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 17 Oct 2017 16:55:51 +0200
> The set fixes a splat in devmap percpu allocation when we alloc
> the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2,
> patch 1 is rather small, so if this could be routed via -net, for
> example, with Tejun's Ack that would be good. Patch 3 gets rid of
> remaining PCPU_MIN_UNIT_SIZE checks, which are percpu allocator
> internals and should not be used.
Series applied.
^ permalink raw reply
* [PATCH v2 net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods
From: Egil Hjelmeland @ 2017-10-19 12:10 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20171019121015.7395-1-privat@egil-hjelmeland.no>
Add DSA method port_fast_age as a step to STP support.
Add low level functions for accessing the lan9303 ALR (Address Logic
Resolution).
Added DSA method port_fdb_dump
Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
---
drivers/net/dsa/lan9303-core.c | 159 +++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lan9303.h | 2 +
2 files changed, 161 insertions(+)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 09a748327fc6..ae904242b001 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -124,6 +124,21 @@
#define LAN9303_MAC_RX_CFG_2 0x0c01
#define LAN9303_MAC_TX_CFG_2 0x0c40
#define LAN9303_SWE_ALR_CMD 0x1800
+# define ALR_CMD_MAKE_ENTRY BIT(2)
+# define ALR_CMD_GET_FIRST BIT(1)
+# define ALR_CMD_GET_NEXT BIT(0)
+#define LAN9303_SWE_ALR_WR_DAT_0 0x1801
+#define LAN9303_SWE_ALR_WR_DAT_1 0x1802
+# define ALR_DAT1_VALID BIT(26)
+# define ALR_DAT1_END_OF_TABL BIT(25)
+# define ALR_DAT1_AGE_OVERRID BIT(25)
+# define ALR_DAT1_STATIC BIT(24)
+# define ALR_DAT1_PORT_BITOFFS 16
+# define ALR_DAT1_PORT_MASK (7 << ALR_DAT1_PORT_BITOFFS)
+#define LAN9303_SWE_ALR_RD_DAT_0 0x1805
+#define LAN9303_SWE_ALR_RD_DAT_1 0x1806
+#define LAN9303_SWE_ALR_CMD_STS 0x1808
+# define ALR_STS_MAKE_PEND BIT(0)
#define LAN9303_SWE_VLAN_CMD 0x180b
# define LAN9303_SWE_VLAN_CMD_RNW BIT(5)
# define LAN9303_SWE_VLAN_CMD_PVIDNVLAN BIT(4)
@@ -478,6 +493,125 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
return 0;
}
+/* ----------------- Address Logic Resolution (ALR)------------------*/
+
+/* Map ALR-port bits to port bitmap, and back*/
+static const int alrport_2_portmap[] = {1, 2, 4, 0, 3, 5, 6, 7 };
+static const int portmap_2_alrport[] = {3, 0, 1, 4, 2, 5, 6, 7 };
+
+/* ALR: Actual register access functions */
+
+/* This function will wait a while until mask & reg == value */
+/* Otherwise, return timeout */
+static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno,
+ int mask, char value)
+{
+ int i;
+
+ for (i = 0; i < 0x1000; i++) {
+ u32 reg;
+
+ lan9303_read_switch_reg(chip, regno, ®);
+ if ((reg & mask) == value)
+ return 0;
+ usleep_range(1000, 2000);
+ }
+ return -ETIMEDOUT;
+}
+
+static int lan9303_alr_make_entry_raw(struct lan9303 *chip, u32 dat0, u32 dat1)
+{
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_WR_DAT_0, dat0);
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_WR_DAT_1, dat1);
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_CMD, ALR_CMD_MAKE_ENTRY);
+ lan9303_csr_reg_wait(
+ chip, LAN9303_SWE_ALR_CMD_STS, ALR_STS_MAKE_PEND, 0);
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
+ return 0;
+}
+
+typedef void alr_loop_cb_t(struct lan9303 *chip, u32 dat0, u32 dat1,
+ int portmap, void *ctx);
+
+static void lan9303_alr_loop(struct lan9303 *chip, alr_loop_cb_t *cb, void *ctx)
+{
+ int i;
+
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, ALR_CMD_GET_FIRST);
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
+
+ for (i = 1; i < LAN9303_NUM_ALR_RECORDS; i++) {
+ u32 dat0, dat1;
+ int alrport, portmap;
+
+ lan9303_read_switch_reg(chip, LAN9303_SWE_ALR_RD_DAT_0, &dat0);
+ lan9303_read_switch_reg(chip, LAN9303_SWE_ALR_RD_DAT_1, &dat1);
+ if (dat1 & ALR_DAT1_END_OF_TABL)
+ break;
+
+ alrport = (dat1 & ALR_DAT1_PORT_MASK) >> ALR_DAT1_PORT_BITOFFS;
+ portmap = alrport_2_portmap[alrport];
+
+ cb(chip, dat0, dat1, portmap, ctx);
+
+ lan9303_write_switch_reg(
+ chip, LAN9303_SWE_ALR_CMD, ALR_CMD_GET_NEXT);
+ lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
+ }
+}
+
+/* ALR: lan9303_alr_loop callback functions */
+
+static void alr_reg_to_mac(u32 dat0, u32 dat1, u8 mac[6])
+{
+ mac[0] = (dat0 >> 0) & 0xff;
+ mac[1] = (dat0 >> 8) & 0xff;
+ mac[2] = (dat0 >> 16) & 0xff;
+ mac[3] = (dat0 >> 24) & 0xff;
+ mac[4] = (dat1 >> 0) & 0xff;
+ mac[5] = (dat1 >> 8) & 0xff;
+}
+
+/* Clear learned (non-static) entry on given port */
+static void alr_loop_cb_del_port_learned(struct lan9303 *chip, u32 dat0,
+ u32 dat1, int portmap, void *ctx)
+{
+ int *port = ctx;
+
+ if (((BIT(*port) & portmap) == 0) || (dat1 & ALR_DAT1_STATIC))
+ return;
+
+ /* learned entries has only one port, we can just delete */
+ dat1 &= ~ALR_DAT1_VALID; /* delete entry */
+ lan9303_alr_make_entry_raw(chip, dat0, dat1);
+}
+
+struct port_fdb_dump_ctx {
+ int port;
+ void *data;
+ dsa_fdb_dump_cb_t *cb;
+};
+
+static void alr_loop_cb_fdb_port_dump(struct lan9303 *chip, u32 dat0,
+ u32 dat1, int portmap, void *ctx)
+{
+ struct port_fdb_dump_ctx *dump_ctx = ctx;
+ u8 mac[ETH_ALEN];
+ bool is_static;
+
+ if ((BIT(dump_ctx->port) & portmap) == 0)
+ return;
+
+ alr_reg_to_mac(dat0, dat1, mac);
+ is_static = !!(dat1 & ALR_DAT1_STATIC);
+ dump_ctx->cb(mac, 0, is_static, dump_ctx->data);
+}
+
+/* --------------------- Various chip setup ----------------------*/
+
static int lan9303_disable_processing_port(struct lan9303 *chip,
unsigned int port)
{
@@ -923,6 +1057,29 @@ static void lan9303_port_stp_state_set(struct dsa_switch *ds, int port,
/* else: touching SWE_PORT_STATE would break port separation */
}
+static void lan9303_port_fast_age(struct dsa_switch *ds, int port)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d)\n", __func__, port);
+ lan9303_alr_loop(chip, alr_loop_cb_del_port_learned, &port);
+}
+
+static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
+ dsa_fdb_dump_cb_t *cb, void *data)
+{
+ struct lan9303 *chip = ds->priv;
+ struct port_fdb_dump_ctx dump_ctx = {
+ .port = port,
+ .data = data,
+ .cb = cb,
+ };
+
+ dev_dbg(chip->dev, "%s(%d)\n", __func__, port);
+ lan9303_alr_loop(chip, alr_loop_cb_fdb_port_dump, &dump_ctx);
+ return 0;
+}
+
static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
@@ -937,6 +1094,8 @@ static const struct dsa_switch_ops lan9303_switch_ops = {
.port_bridge_join = lan9303_port_bridge_join,
.port_bridge_leave = lan9303_port_bridge_leave,
.port_stp_state_set = lan9303_port_stp_state_set,
+ .port_fast_age = lan9303_port_fast_age,
+ .port_fdb_dump = lan9303_port_fdb_dump,
};
static int lan9303_register_switch(struct lan9303 *chip)
diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
index 68ecd544b658..4db323d65741 100644
--- a/drivers/net/dsa/lan9303.h
+++ b/drivers/net/dsa/lan9303.h
@@ -11,6 +11,8 @@ struct lan9303_phy_ops {
int regnum, u16 val);
};
+#define LAN9303_NUM_ALR_RECORDS 512
+
struct lan9303 {
struct device *dev;
struct regmap *regmap;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 net-next 0/2] net: dsa: lan9303: Add fdb/mdb methods
From: Egil Hjelmeland @ 2017-10-19 12:10 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
This series add support for accessing and managing the lan9303 ALR
(Address Logic Resolution).
The first patch add low level functions for accessing the ALR, along
with port_fast_age and port_fdb_dump methods.
The second patch add functions for managing ALR entires, along with
remaining fdb/mdb methods.
Note that to complete STP support, a special ALR entry with the STP eth
address must be added too. This must be addressed later.
Comments welcome!
Changes v1 -> v2:
- Patch 2: Removed question comment
Egil Hjelmeland (2):
net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods
net: dsa: lan9303: Add fdb/mdb manipulation
drivers/net/dsa/lan9303-core.c | 331 +++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lan9303.h | 11 ++
2 files changed, 342 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH v2 net-next 2/2] net: dsa: lan9303: Add fdb/mdb manipulation
From: Egil Hjelmeland @ 2017-10-19 12:10 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20171019121015.7395-1-privat@egil-hjelmeland.no>
Add functions for managing the lan9303 ALR (Address Logic
Resolution).
Implement DSA methods: port_fdb_add, port_fdb_del, port_mdb_prepare,
port_mdb_add and port_mdb_del.
Since the lan9303 do not offer reading specific ALR entry, the driver
caches all static entries - in a flat table.
Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
---
drivers/net/dsa/lan9303-core.c | 172 +++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/lan9303.h | 9 +++
2 files changed, 181 insertions(+)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index ae904242b001..71e91435e479 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -19,6 +19,7 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/if_bridge.h>
+#include <linux/etherdevice.h>
#include "lan9303.h"
@@ -499,6 +500,37 @@ static int lan9303_detect_phy_setup(struct lan9303 *chip)
static const int alrport_2_portmap[] = {1, 2, 4, 0, 3, 5, 6, 7 };
static const int portmap_2_alrport[] = {3, 0, 1, 4, 2, 5, 6, 7 };
+/* ALR: Cache static entries: mac address + port bitmap */
+
+/* Return pointer to first free ALR cache entry, return NULL if none */
+static struct lan9303_alr_cache_entry *
+lan9303_alr_cache_find_free(struct lan9303 *chip)
+{
+ int i;
+ struct lan9303_alr_cache_entry *entr = chip->alr_cache;
+
+ for (i = 0; i < LAN9303_NUM_ALR_RECORDS; i++, entr++)
+ if (entr->port_map == 0)
+ return entr;
+ return NULL;
+}
+
+/* Return pointer to ALR cache entry matching MAC address */
+static struct lan9303_alr_cache_entry *
+lan9303_alr_cache_find_mac(struct lan9303 *chip, const u8 *mac_addr)
+{
+ int i;
+ struct lan9303_alr_cache_entry *entr = chip->alr_cache;
+
+ BUILD_BUG_ON_MSG(sizeof(struct lan9303_alr_cache_entry) & 1,
+ "ether_addr_equal require u16 alignment");
+
+ for (i = 0; i < LAN9303_NUM_ALR_RECORDS; i++, entr++)
+ if (ether_addr_equal(entr->mac_addr, mac_addr))
+ return entr;
+ return NULL;
+}
+
/* ALR: Actual register access functions */
/* This function will wait a while until mask & reg == value */
@@ -610,6 +642,73 @@ static void alr_loop_cb_fdb_port_dump(struct lan9303 *chip, u32 dat0,
dump_ctx->cb(mac, 0, is_static, dump_ctx->data);
}
+/* ALR: Add/modify/delete ALR entries */
+
+/* Set a static ALR entry. Delete entry if port_map is zero */
+static void lan9303_alr_set_entry(struct lan9303 *chip, const u8 *mac,
+ u8 port_map, bool stp_override)
+{
+ u32 dat0, dat1, alr_port;
+
+ dev_dbg(chip->dev, "%s(%pM, %d)\n", __func__, mac, port_map);
+ dat1 = ALR_DAT1_STATIC;
+ if (port_map)
+ dat1 |= ALR_DAT1_VALID; /* otherwise no ports: delete entry */
+ if (stp_override)
+ dat1 |= ALR_DAT1_AGE_OVERRID;
+
+ alr_port = portmap_2_alrport[port_map & 7];
+ dat1 &= ~ALR_DAT1_PORT_MASK;
+ dat1 |= alr_port << ALR_DAT1_PORT_BITOFFS;
+
+ dat0 = 0;
+ dat0 |= (mac[0] << 0);
+ dat0 |= (mac[1] << 8);
+ dat0 |= (mac[2] << 16);
+ dat0 |= (mac[3] << 24);
+
+ dat1 |= (mac[4] << 0);
+ dat1 |= (mac[5] << 8);
+
+ lan9303_alr_make_entry_raw(chip, dat0, dat1);
+}
+
+/* Add port to static ALR entry, create new static entry if needed */
+static int lan9303_alr_add_port(struct lan9303 *chip, const u8 *mac,
+ int port, bool stp_override)
+{
+ struct lan9303_alr_cache_entry *entr;
+
+ entr = lan9303_alr_cache_find_mac(chip, mac);
+ if (!entr) { /*New entry */
+ entr = lan9303_alr_cache_find_free(chip);
+ if (!entr)
+ return -ENOSPC;
+ ether_addr_copy(entr->mac_addr, mac);
+ }
+ entr->port_map |= BIT(port);
+ entr->stp_override = stp_override;
+ lan9303_alr_set_entry(chip, mac, entr->port_map, stp_override);
+ return 0;
+}
+
+/* Delete static port from ALR entry, delete entry if last port */
+static int lan9303_alr_del_port(struct lan9303 *chip, const u8 *mac,
+ int port)
+{
+ struct lan9303_alr_cache_entry *entr;
+
+ entr = lan9303_alr_cache_find_mac(chip, mac);
+ if (!entr)
+ return 0; /* no static entry found */
+
+ entr->port_map &= ~BIT(port);
+ if (entr->port_map == 0) /* zero means its free again */
+ eth_zero_addr(&entr->port_map);
+ lan9303_alr_set_entry(chip, mac, entr->port_map, entr->stp_override);
+ return 0;
+}
+
/* --------------------- Various chip setup ----------------------*/
static int lan9303_disable_processing_port(struct lan9303 *chip,
@@ -1065,6 +1164,30 @@ static void lan9303_port_fast_age(struct dsa_switch *ds, int port)
lan9303_alr_loop(chip, alr_loop_cb_del_port_learned, &port);
}
+static int lan9303_port_fdb_add(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, addr, vid);
+ if (vid)
+ return -EOPNOTSUPP;
+ return lan9303_alr_add_port(chip, addr, port, false);
+}
+
+static int lan9303_port_fdb_del(struct dsa_switch *ds, int port,
+ const unsigned char *addr, u16 vid)
+
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, addr, vid);
+ if (vid)
+ return -EOPNOTSUPP;
+ lan9303_alr_del_port(chip, addr, port);
+ return 0;
+}
+
static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
dsa_fdb_dump_cb_t *cb, void *data)
{
@@ -1080,6 +1203,50 @@ static int lan9303_port_fdb_dump(struct dsa_switch *ds, int port,
return 0;
}
+static int lan9303_port_mdb_prepare(
+ struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb,
+ struct switchdev_trans *trans)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, mdb->addr,
+ mdb->vid);
+ if (mdb->vid)
+ return -EOPNOTSUPP;
+ if (lan9303_alr_cache_find_mac(chip, mdb->addr))
+ return 0;
+ if (!lan9303_alr_cache_find_free(chip))
+ return -ENOSPC;
+ return 0;
+}
+
+static void lan9303_port_mdb_add(
+ struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb,
+ struct switchdev_trans *trans)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, mdb->addr,
+ mdb->vid);
+ lan9303_alr_add_port(chip, mdb->addr, port, false);
+}
+
+static int lan9303_port_mdb_del(
+ struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb)
+{
+ struct lan9303 *chip = ds->priv;
+
+ dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, mdb->addr,
+ mdb->vid);
+ if (mdb->vid)
+ return -EOPNOTSUPP;
+ lan9303_alr_del_port(chip, mdb->addr, port);
+ return 0;
+}
+
static const struct dsa_switch_ops lan9303_switch_ops = {
.get_tag_protocol = lan9303_get_tag_protocol,
.setup = lan9303_setup,
@@ -1095,7 +1262,12 @@ static const struct dsa_switch_ops lan9303_switch_ops = {
.port_bridge_leave = lan9303_port_bridge_leave,
.port_stp_state_set = lan9303_port_stp_state_set,
.port_fast_age = lan9303_port_fast_age,
+ .port_fdb_add = lan9303_port_fdb_add,
+ .port_fdb_del = lan9303_port_fdb_del,
.port_fdb_dump = lan9303_port_fdb_dump,
+ .port_mdb_prepare = lan9303_port_mdb_prepare,
+ .port_mdb_add = lan9303_port_mdb_add,
+ .port_mdb_del = lan9303_port_mdb_del,
};
static int lan9303_register_switch(struct lan9303 *chip)
diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h
index 4db323d65741..d807b1be35f2 100644
--- a/drivers/net/dsa/lan9303.h
+++ b/drivers/net/dsa/lan9303.h
@@ -12,6 +12,11 @@ struct lan9303_phy_ops {
};
#define LAN9303_NUM_ALR_RECORDS 512
+struct lan9303_alr_cache_entry {
+ u8 mac_addr[ETH_ALEN];
+ u8 port_map; /* Bitmap of ports. Zero if unused entry */
+ u8 stp_override; /* non zero if set ALR_DAT1_AGE_OVERRID */
+};
struct lan9303 {
struct device *dev;
@@ -25,6 +30,10 @@ struct lan9303 {
const struct lan9303_phy_ops *ops;
bool is_bridged; /* true if port 1 and 2 are bridged */
u32 swe_port_state; /* remember SWE_PORT_STATE while not bridged */
+ /* LAN9303 do not offer reading specific ALR entry. Cache all
+ * static entries in a flat table
+ **/
+ struct lan9303_alr_cache_entry alr_cache[LAN9303_NUM_ALR_RECORDS];
};
extern const struct regmap_access_table lan9303_register_set;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net] geneve: Fix function matching VNI and tunnel ID on big-endian
From: Jakub Sitnicki @ 2017-10-19 12:08 UTC (permalink / raw)
To: Stefano Brivio
Cc: David S . Miller, netdev, pravin shelar, Girish Moodalbail,
Sabrina Dubroca
In-Reply-To: <7fb32cd5779c5c0133754194aa6914fa8689853e.1508412016.git.sbrivio@redhat.com>
On Thu, 19 Oct 2017 13:31:28 +0200
Stefano Brivio <sbrivio@redhat.com> wrote:
> On big-endian machines, functions converting between tunnel ID
> and VNI use the three LSBs of tunnel ID storage to map VNI.
>
> The comparison function eq_tun_id_and_vni(), on the other hand,
> attempted to map the VNI from the three MSBs. Fix it by using
> the same check implemented on LE, which maps VNI from the three
> LSBs of tunnel ID.
>
> Fixes: 2e0b26e10352 ("geneve: Optimize geneve device lookup.")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Thanks, Stefano.
Reviewed-by: Jakub Sitnicki <jkbs@redhat.com>
^ permalink raw reply
* Re: [PATCH 2/2 net-next] thunderbolt: Right shifting to zero bug in tbnet_handle_packet()
From: David Miller @ 2017-10-19 12:05 UTC (permalink / raw)
To: dan.carpenter
Cc: michael.jamet, amir.jer.levy, mika.westerberg, yehezkel.bernat,
netdev, kernel-janitors
In-Reply-To: <20171017123301.z6heqexdlo6lc52b@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 17 Oct 2017 15:33:01 +0300
> There is a problem when we do:
>
> sequence = pkg->hdr.length_sn & TBIP_HDR_SN_MASK;
> sequence >>= TBIP_HDR_SN_SHIFT;
>
> TBIP_HDR_SN_SHIFT is 27, and right shifting a u8 27 bits is always
> going to result in zero. The fix is to declare these variables as u32.
>
> Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2 v2 net-next] thunderbolt: Fix a couple right shifting to zero bugs
From: David Miller @ 2017-10-19 12:04 UTC (permalink / raw)
To: dan.carpenter
Cc: andreas.noever, michael.jamet, mika.westerberg, yehezkel.bernat,
netdev, kernel-janitors
In-Reply-To: <20171017123217.p3ctmptbrm75ys46@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 17 Oct 2017 15:32:17 +0300
> The problematic code looks like this:
>
> res_seq = res_hdr->xd_hdr.length_sn & TB_XDOMAIN_SN_MASK;
> res_seq >>= TB_XDOMAIN_SN_SHIFT;
>
> TB_XDOMAIN_SN_SHIFT is 27, and right shifting a u8 27 bits is always
> going to result in zero. The fix is to declare these variables as u32.
>
> Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/3] bonding: void calling rtmsg_ifinfo for netlink notifications
From: David Miller @ 2017-10-19 12:03 UTC (permalink / raw)
To: lucien.xin; +Cc: jiri, netdev
In-Reply-To: <CADvbK_c7R2OJNq=DyXOCSNVzD2aU2qxBO6UiitGbCYS=icwxTQ@mail.gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 17 Oct 2017 18:28:45 +0800
> On Tue, Oct 17, 2017 at 5:59 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Oct 17, 2017 at 11:39:38AM CEST, lucien.xin@gmail.com wrote:
>>>It's better to send notifications to userspace by the events
>>>in rtnetlink_event, instead of calling rtmsg_ifinfo directly.
>>>
>>>This patcheset is to remove rtmsg_ifinfo called in bonding,
>>>the notifications can be handled by NETDEV_CHANGEUPPER and
>>>NETDEV_CHANGELOWERSTATE events in rtnetlink_event.
>>>
>>>It could also fix some redundant notifications from bonding.
>>
>> This should go to net-next.
>
> NETDEV_CHANGEUPPER is not yet in rtnetlink_event in net-next tree.
> patches can only work on net tree by now.
>
> Hi, David, you want me to hold them until the patches for NETDEV_CHANGEUPPER
> are copied to net-next, or you would apply them to net ?
Please hold until net is next merged into net-next, thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox