* Re: [PATCH net] selftests/bpf: fix broken build due to types.h
From: David Miller @ 2017-05-16 19:18 UTC (permalink / raw)
To: yhs; +Cc: daniel, netdev, kernel-team
In-Reply-To: <20170516184634.2803675-1-yhs@fb.com>
Please correct the address of the netdev list (it is just plain
'netdev' not 'linux-netdev').
Secondly, __always_inline should not be defined by types.h
That has to come from linux/compiler.h which we have no reason
to define a private version of for eBPF clang compilation.
The problem is that via several layers of indirection, linux/types.h
eventually includes linux/compiler.h and that is probably the more
appropriate thing for you to do.
^ permalink raw reply
* Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure
From: Doug Ledford @ 2017-05-16 19:28 UTC (permalink / raw)
To: David Miller
Cc: Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, hch-jcswGhMUV9g,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA,
ubraun-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20170516.145249.871010194359061722.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, 2017-05-16 at 14:52 -0400, David Miller wrote:
> From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Tue, 16 May 2017 14:03:22 -0400
>
> > On Tue, 2017-05-16 at 13:36 -0400, David Miller wrote:
> >> From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> Date: Tue, 16 May 2017 13:20:44 -0400
> >>
> >> > Anyway, we're just talking out what happened, when what we
> really
> >> need
> >> > to focus on is moving forward. Again, your thoughts on marking
> SMC
> >> > EXPERIMENTAL until it's fixed up and unfreezing the API in case
> we
> >> need
> >> > to adjust it to work on different link layers?
> >>
> >> Something like:
> >>
> >> http://patchwork.ozlabs.org/patch/762803/
> >>
> >> with the addition of the EXPERIMENTAL dependency?
> >>
> >> Sure.
> >
> > Perfect. I assume you'll submit it since it's in your patchworks?
>
> Ok I applied the patch referenced above, but we don't actually have
> an EXPERIMENTAL symbol. The closest thing we have is BROKEN and
> even in this situation that's a bit harsh.
I hadn't realized EXPERIMENTAL was gone. Which is too bad, because
that's entirely appropriate in this case, and would have had the
desired side effect of keeping it out of any non-cutting edge distros
and warning people of possible API changes. With EXPERIMENTAL gone,
the closest thing we have is drivers/staging, since that tends to imply
some of the same consequences. I know you think BROKEN is overly
harsh, but I'm not sure we should just do nothing. How about we take a
few days to let some of the RDMA people closely review the 143 page
(egads!) rfc (http://www.rfc-editor.org/info/rfc7609) to see if we
think it can be fixed to use multiple link layers with the existing API
in place or if it will require something other than AF_SMC. If we need
to break API, then I think we should either fix it ASAP and send that
fix to the 4.11 stable series (which probably violates the normative
stable patch size/scope) or if the fix will take longer than this
kernel cycle, then move it to staging both here and in 4.11 stable, and
fix it there and then move it back. Something like that would prevent
the kind of API flappage we ought not do....
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] geneve: add rtnl changelink support
From: David Miller @ 2017-05-16 19:31 UTC (permalink / raw)
To: girish.moodalbail; +Cc: netdev, pshelar, joe, jbenc
In-Reply-To: <1494870424-22699-1-git-send-email-girish.moodalbail@oracle.com>
From: Girish Moodalbail <girish.moodalbail@oracle.com>
Date: Mon, 15 May 2017 10:47:04 -0700
> if (data[IFLA_GENEVE_REMOTE]) {
> - info.key.u.ipv4.dst =
> + info->key.u.ipv4.dst =
> nla_get_in_addr(data[IFLA_GENEVE_REMOTE]);
>
> - if (IN_MULTICAST(ntohl(info.key.u.ipv4.dst))) {
> + if (IN_MULTICAST(ntohl(info->key.u.ipv4.dst))) {
> netdev_dbg(dev, "multicast remote is unsupported\n");
> return -EINVAL;
> }
> + if (changelink &&
> + ip_tunnel_info_af(&geneve->info) == AF_INET6) {
> + info->mode &= ~IP_TUNNEL_INFO_IPV6;
> + info->key.tun_flags &= ~TUNNEL_CSUM;
> + *use_udp6_rx_checksums = false;
> + }
> }
I don't understand this "changelink" guarded code, why do you need to
clear all of this state out if the existing tunnel type if AF_INET6
and only when doing a changelink?
In any event, I think you need to add a comment explaining it.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] udp: scalability improvements
From: David Miller @ 2017-05-16 19:41 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet
In-Reply-To: <cover.1494881617.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 16 May 2017 11:20:12 +0200
> This patch series implement an idea suggested by Eric Dumazet to
> reduce the contention of the udp sk_receive_queue lock when the socket is
> under flood.
Series applied, thanks a lot.
^ permalink raw reply
* Re: linux-next: Tree for May 16 (net/core)
From: Paul Gortmaker @ 2017-05-16 19:44 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <f63533e7-edd3-4c0d-ddff-e3409d15abc6@infradead.org>
On Tue, May 16, 2017 at 12:28 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 05/15/17 18:21, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20170515:
>>
>
> on i386 or x86_64:
>
> when CONFIG_INET is not enabled:
>
> ../net/core/sock.c: In function 'skb_orphan_partial':
> ../net/core/sock.c:1810:2: error: implicit declaration of function 'skb_is_tcp_pure_ack' [-Werror=implicit-function-declaration]
> if (skb_is_tcp_pure_ack(skb))
Automated bisect on an ARM build with the same issue reveals:
f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9 is the first bad commit
commit f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9
Author: Eric Dumazet <edumazet@google.com>
Date: Thu May 11 15:24:41 2017 -0700
netem: fix skb_orphan_partial()
I should have known that lowering skb->truesize was dangerous :/
In case packets are not leaving the host via a standard Ethernet device,
but looped back to local sockets, bad things can happen, as reported
by Michael Madsen ( https://bugzilla.kernel.org/show_bug.cgi?id=195713 )
So instead of tweaking skb->truesize, lets change skb->destructor
and keep a reference on the owner socket via its sk_refcnt.
Fixes: f2f872f9272a ("netem: Introduce skb_orphan_partial() helper")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Michael Madsen <mkm@nabto.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
:040000 040000 7bfb7a6f5e12373b1c50ede2455b6ddd6d79cee0
b45b7255322f1dff5e3ab8d3d707cf38a91c76ce M net
bisect run success
http://kisskb.ellerman.id.au/kisskb/buildresult/13033081/
I'm guessing Eric already knows about this but I've Cc'd him just in case.
P.
--
>
>
> --
> ~Randy
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: internal implementation for pacing
From: David Miller @ 2017-05-16 19:46 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, ncardwell, ycheng, vanj, hkchu
In-Reply-To: <20170516112436.10189-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Tue, 16 May 2017 04:24:36 -0700
> BBR congestion control depends on pacing, and pacing is
> currently handled by sch_fq packet scheduler for performance reasons,
> and also because implemening pacing with FQ was convenient to truly
> avoid bursts.
>
> However there are many cases where this packet scheduler constraint
> is not practical.
> - Many linux hosts are not focusing on handling thousands of TCP
> flows in the most efficient way.
> - Some routers use fq_codel or other AQM, but still would like
> to use BBR for the few TCP flows they initiate/terminate.
>
> This patch implements an automatic fallback to internal pacing.
...
Looks great, applied, thanks!
^ permalink raw reply
* Re: [patch iproute2 v2 repost 1/3] tc_filter: add support for chain index
From: Jiri Pirko @ 2017-05-16 19:47 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, davem, jhs, xiyou.wangcong, dsa, edumazet, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170516111658.42b9191c@xeon-e3>
Tue, May 16, 2017 at 08:16:58PM CEST, stephen@networkplumber.org wrote:
>On Tue, 16 May 2017 19:29:35 +0200
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Allow user to put filter to a specific chain identified by index.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>This will have to wait for the chain bits to show up upstream in net-next.
>
Sure. I just like to send the kernel patches alongside with the related
iproute2 patches. Thanks.
^ permalink raw reply
* Re: [PATCH] [net, 4.12] mlx5e: add CONFIG_INET dependency
From: David Miller @ 2017-05-16 19:48 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, erezsh-VPRAkNaXOzVWk0Htik3J/w,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170516112807.4107417-1-arnd-r2nGTMty4D4@public.gmane.org>
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Date: Tue, 16 May 2017 13:27:49 +0200
> We now reference the arp_tbl, which requires IPv4 support to be
> enabled in the kernel, otherwise we get a link error:
>
> drivers/net/built-in.o: In function `mlx5e_tc_update_neigh_used_value':
> (.text+0x16afec): undefined reference to `arp_tbl'
> drivers/net/built-in.o: In function `mlx5e_rep_neigh_init':
> en_rep.c:(.text+0x16c16d): undefined reference to `arp_tbl'
> drivers/net/built-in.o: In function `mlx5e_rep_netevent_event':
> en_rep.c:(.text+0x16cbb5): undefined reference to `arp_tbl'
>
> This adds a Kconfig dependency for it.
>
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Remove open coded carrier check
From: David Miller @ 2017-05-16 19:49 UTC (permalink / raw)
To: leon; +Cc: Yuval.Mintz, netdev, leonro
In-Reply-To: <20170516122056.1534-1-leon@kernel.org>
From: Leon Romanovsky <leon@kernel.org>
Date: Tue, 16 May 2017 15:20:56 +0300
> From: Leon Romanovsky <leonro@mellanox.com>
>
> There is inline function to test if carrier present,
> so it makes open-coded solution redundant.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier.
From: David Miller @ 2017-05-16 19:52 UTC (permalink / raw)
To: ecree; +Cc: daniel, ast, alexei.starovoitov, netdev
In-Reply-To: <754f2c39-fdb0-2407-c2f2-aa36d506d202@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Tue, 16 May 2017 13:37:42 +0100
> On 15/05/17 17:04, David Miller wrote:
>> If we use 1<<31, then sequences like:
>>
>> R1 = 0
>> R1 <<= 2
>>
>> do silly things.
> Hmm. It might be a bit late for this, but I wonder if, instead of handling
> alignments as (1 << align), you could store them as -(1 << align), i.e.
> leading 1s followed by 'align' 0s.
> Now the alignment of 0 is 0 (really 1 << 32), which doesn't change when
> left-shifted some more. Shifts of other numbers' alignments also do the
> right thing, e.g. align(6) << 2 = (-2) << 2 = -8 = align(6 << 2). Of
> course you do all this in unsigned, to make sure right shifts work.
> This also makes other arithmetic simple to track; for instance, align(a + b)
> is at worst align(a) | align(b). (Of course, this bound isn't tight.)
> A number is 2^(n+1)-aligned if the 2^n bit of its alignment is cleared.
> Considered as unsigned numbers, smaller values are stricter alignments.
Thanks for the bit twiddling suggestion, I'll take a look!
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: update latest firmware version supported
From: David Miller @ 2017-05-16 19:53 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil
In-Reply-To: <1494948412-7818-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Tue, 16 May 2017 20:56:52 +0530
> Change t4fw_version.h to update latest firmware version
> number to 1.16.43.0.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
People are hitting regressions in 'net' due to using firmware allowed
by the current defines in combination with the FEC disabling commit.
So it doesn't make sense to "fix" this in 'net-next'.
^ permalink raw reply
* Re: [PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets
From: Joe Stringer @ 2017-05-16 19:55 UTC (permalink / raw)
To: Anoob Soman
Cc: stable, Pravin B Shelar, David S. Miller, netdev, ovs dev, LKML
In-Reply-To: <1494944710-7901-1-git-send-email-anoob.soman@citrix.com>
On 16 May 2017 at 07:25, Anoob Soman <anoob.soman@citrix.com> wrote:
> Similar to commit c29390c6dfee ("xps: must clear sender_cpu before
> forwarding") the skb->sender_cpu needs to be cleared before forwarding
> packets.
>
> Fixes: 2bd82484bb4c ("xps: fix xps for stacked devices")
> Signed-off-by: Anoob Soman <anoob.soman@citrix.com>
Is this needed for 4.1 too?
^ permalink raw reply
* Re: [PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example
From: Martin Blumenstingl @ 2017-05-16 19:56 UTC (permalink / raw)
To: Arend Van Spriel, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: kvalo-sgV2jX0FEOL9JmXXK+q4OQ, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8155d0f1-aed3-fc47-4524-635067f9ee7b-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Hi Arend,
On Tue, May 16, 2017 at 12:05 AM, Arend Van Spriel
<arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On 15-5-2017 22:13, Martin Blumenstingl wrote:
>> The example in the BCM43xx documentation uses "brcmf" as node name.
>> However, wireless devices should be named "wifi" instead. Fix this to
>
> Hi Martin,
>
> Since when is that a rule. I never got the memo and the DTC did not ever
> complain to me about the naming. That being said I do not really care
> and I suppose it is for the sake of consistency only.
I'm not sure if it's actually a rule or (as you already noted) just
for consistency. back when I added devicetree support to ath9k Rob
pointed out that the node should be named "wifi" (instead of "ath9k"),
see [0]
>> make sure that .dts authors can simply use the documentation as
>> reference (or simply copy the node from the documentation and then
>> adjust only the board specific bits).
>
> Please feel free to add my...
>
> Acked-by: Arend van Spriel <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
thank you!
@Rob: maybe you can ACK this as well if you're fine with this patch?
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> index 5dbf169cd81c..590f622188de 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> @@ -31,7 +31,7 @@ mmc3: mmc@01c12000 {
>> non-removable;
>> status = "okay";
>>
>> - brcmf: bcrmf@1 {
>> + brcmf: wifi@1 {
>> reg = <1>;
>> compatible = "brcm,bcm4329-fmac";
>> interrupt-parent = <&pio>;
>>
[0] http://www.mail-archive.com/ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ@public.gmane.org/msg14678.html
^ permalink raw reply
* Re: [PATCH] net: phy: Remove residual magic from PHY drivers
From: David Miller @ 2017-05-16 19:58 UTC (permalink / raw)
To: andrew; +Cc: f.fainelli, netdev
In-Reply-To: <1494952151-3040-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 16 May 2017 18:29:11 +0200
> commit fa8cddaf903c ("net phylib: Remove unnecessary condition check in phy")
> removed the only place where the PHY flag PHY_HAS_MAGICANEG was
> checked. But it left the flag being set in the drivers. Remove the flag.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] liquidio: use pcie_flr instead of duplicating it
From: David Miller @ 2017-05-16 20:00 UTC (permalink / raw)
To: hch
Cc: felix.manlunas, raghu.vatsavayi, satananda.burla, derek.chickles,
netdev
In-Reply-To: <20170516142146.21739-1-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 16 May 2017 16:21:46 +0200
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Tested-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] geneve: add rtnl changelink support
From: Pravin Shelar @ 2017-05-16 20:00 UTC (permalink / raw)
To: Girish Moodalbail
Cc: Linux Kernel Network Developers, David S. Miller, Joe Stringer,
Jiri Benc
In-Reply-To: <1494870424-22699-1-git-send-email-girish.moodalbail@oracle.com>
On Mon, May 15, 2017 at 10:47 AM, Girish Moodalbail
<girish.moodalbail@oracle.com> wrote:
> This patch adds changelink rtnl operation support for geneve devices.
> Code changes involve:
> - refactor geneve_newlink into geneve_nl2info to be used by both
> geneve_newlink and geneve_changelink
> - geneve_nl2info takes a changelink boolean argument to isolate
> changelink checks and updates.
> - Allow changing only a few attributes:
> - return -EOPNOTSUPP for attributes that cannot be changed for
> now. Incremental patches can make the non-supported one
> available in the future if needed.
>
Thanks for working on this.
> Signed-off-by: Girish Moodalbail <girish.moodalbail@oracle.com>
> ---
> drivers/net/geneve.c | 149 ++++++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 117 insertions(+), 32 deletions(-)
>
...
> @@ -1169,45 +1181,58 @@ static void init_tnl_info(struct ip_tunnel_info *info, __u16 dst_port)
> info->key.tp_dst = htons(dst_port);
> }
>
> -static int geneve_newlink(struct net *net, struct net_device *dev,
> - struct nlattr *tb[], struct nlattr *data[])
> +static int geneve_nl2info(struct net_device *dev, struct nlattr *tb[],
> + struct nlattr *data[], struct ip_tunnel_info *info,
> + bool *metadata, bool *use_udp6_rx_checksums,
> + bool changelink)
> {
> - bool use_udp6_rx_checksums = false;
> - struct ip_tunnel_info info;
> - bool metadata = false;
> + struct geneve_dev *geneve = netdev_priv(dev);
>
> - init_tnl_info(&info, GENEVE_UDP_PORT);
> + if (changelink) {
> + /* if changelink operation, start with old existing info */
> + memcpy(info, &geneve->info, sizeof(*info));
> + *metadata = geneve->collect_md;
> + *use_udp6_rx_checksums = geneve->use_udp6_rx_checksums;
> + } else {
> + init_tnl_info(info, GENEVE_UDP_PORT);
> + }
>
> if (data[IFLA_GENEVE_REMOTE] && data[IFLA_GENEVE_REMOTE6])
> return -EINVAL;
>
> if (data[IFLA_GENEVE_REMOTE]) {
> - info.key.u.ipv4.dst =
> + info->key.u.ipv4.dst =
> nla_get_in_addr(data[IFLA_GENEVE_REMOTE]);
>
> - if (IN_MULTICAST(ntohl(info.key.u.ipv4.dst))) {
> + if (IN_MULTICAST(ntohl(info->key.u.ipv4.dst))) {
> netdev_dbg(dev, "multicast remote is unsupported\n");
> return -EINVAL;
> }
> + if (changelink &&
> + ip_tunnel_info_af(&geneve->info) == AF_INET6) {
> + info->mode &= ~IP_TUNNEL_INFO_IPV6;
> + info->key.tun_flags &= ~TUNNEL_CSUM;
> + *use_udp6_rx_checksums = false;
> + }
This allows changelink to change ipv4 address but there are no changes
made to the geneve tunnel port hash table after this update. We also
need to check to see if there is any conflicts with existing ports.
What is the barrier between the rx/tx threads and changelink process?
> }
>
> if (data[IFLA_GENEVE_REMOTE6]) {
> #if IS_ENABLED(CONFIG_IPV6)
> - info.mode = IP_TUNNEL_INFO_IPV6;
> - info.key.u.ipv6.dst =
> + info->mode = IP_TUNNEL_INFO_IPV6;
> + info->key.u.ipv6.dst =
> nla_get_in6_addr(data[IFLA_GENEVE_REMOTE6]);
>
> - if (ipv6_addr_type(&info.key.u.ipv6.dst) &
> + if (ipv6_addr_type(&info->key.u.ipv6.dst) &
> IPV6_ADDR_LINKLOCAL) {
> netdev_dbg(dev, "link-local remote is unsupported\n");
> return -EINVAL;
> }
> - if (ipv6_addr_is_multicast(&info.key.u.ipv6.dst)) {
> + if (ipv6_addr_is_multicast(&info->key.u.ipv6.dst)) {
> netdev_dbg(dev, "multicast remote is unsupported\n");
> return -EINVAL;
> }
> - info.key.tun_flags |= TUNNEL_CSUM;
> - use_udp6_rx_checksums = true;
> + info->key.tun_flags |= TUNNEL_CSUM;
> + *use_udp6_rx_checksums = true;
Same here. We need to check/fix the geneve tunnel hash table according
to new IP address.
> #else
> return -EPFNOSUPPORT;
> #endif
> @@ -1216,48 +1241,107 @@ static int geneve_newlink(struct net *net, struct net_device *dev,
...
>
> - if (data[IFLA_GENEVE_PORT])
> - info.key.tp_dst = nla_get_be16(data[IFLA_GENEVE_PORT]);
> + if (data[IFLA_GENEVE_PORT]) {
> + if (changelink)
> + return -EOPNOTSUPP;
> + info->key.tp_dst = nla_get_be16(data[IFLA_GENEVE_PORT]);
> + }
> +
> + if (data[IFLA_GENEVE_COLLECT_METADATA]) {
> + if (changelink)
> + return -EOPNOTSUPP;
Rather than blindly returning error here it should check if the
changelink is changing existing configuration.
> + *metadata = true;
> + }
> +
> + if (data[IFLA_GENEVE_UDP_CSUM]) {
> + if (changelink)
> + return -EOPNOTSUPP;
> + if (nla_get_u8(data[IFLA_GENEVE_UDP_CSUM]))
> + info->key.tun_flags |= TUNNEL_CSUM;
> + }
> +
same here.
> + if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]) {
> + if (changelink)
> + return -EOPNOTSUPP;
> + if (nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]))
> + info->key.tun_flags &= ~TUNNEL_CSUM;
same here.
> + }
>
> - if (data[IFLA_GENEVE_COLLECT_METADATA])
> - metadata = true;
> + if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]) {
> + if (changelink)
> + return -EOPNOTSUPP;
> + if (nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]))
> + *use_udp6_rx_checksums = false;
> + }
>
> - if (data[IFLA_GENEVE_UDP_CSUM] &&
> - nla_get_u8(data[IFLA_GENEVE_UDP_CSUM]))
> - info.key.tun_flags |= TUNNEL_CSUM;
> + return 0;
> +}
>
> - if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX] &&
> - nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]))
> - info.key.tun_flags &= ~TUNNEL_CSUM;
> +static int geneve_newlink(struct net *net, struct net_device *dev,
> + struct nlattr *tb[], struct nlattr *data[])
> +{
> + bool use_udp6_rx_checksums = false;
> + struct ip_tunnel_info info;
> + bool metadata = false;
> + int err;
>
> - if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX] &&
> - nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]))
> - use_udp6_rx_checksums = false;
> + err = geneve_nl2info(dev, tb, data, &info, &metadata,
> + &use_udp6_rx_checksums, false);
> + if (err)
> + return err;
>
> return geneve_configure(net, dev, &info, metadata, use_udp6_rx_checksums);
> }
>
> +static int geneve_changelink(struct net_device *dev, struct nlattr *tb[],
> + struct nlattr *data[])
> +{
> + struct geneve_dev *geneve = netdev_priv(dev);
> + struct ip_tunnel_info info;
> + bool metadata = false;
> + bool use_udp6_rx_checksums = false;
> + int err;
> +
> + err = geneve_nl2info(dev, tb, data, &info, &metadata,
> + &use_udp6_rx_checksums, true);
> + if (err)
> + return err;
> +
> + if (!geneve_dst_addr_equal(&geneve->info, &info))
> + dst_cache_reset(&info.dst_cache);
> + geneve->info = info;
This would just overwrite dst-cache, which could leak the percpu
cached dst-entry objects.
> + geneve->collect_md = metadata;
> + geneve->use_udp6_rx_checksums = use_udp6_rx_checksums;
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH net-next] geneve: add rtnl changelink support
From: Girish Moodalbail @ 2017-05-16 20:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, pshelar, joe, jbenc
In-Reply-To: <20170516.153115.2084299272043901950.davem@davemloft.net>
On 5/16/17 12:31 PM, David Miller wrote:
> From: Girish Moodalbail <girish.moodalbail@oracle.com>
> Date: Mon, 15 May 2017 10:47:04 -0700
>
>> if (data[IFLA_GENEVE_REMOTE]) {
>> - info.key.u.ipv4.dst =
>> + info->key.u.ipv4.dst =
>> nla_get_in_addr(data[IFLA_GENEVE_REMOTE]);
>>
>> - if (IN_MULTICAST(ntohl(info.key.u.ipv4.dst))) {
>> + if (IN_MULTICAST(ntohl(info->key.u.ipv4.dst))) {
>> netdev_dbg(dev, "multicast remote is unsupported\n");
>> return -EINVAL;
>> }
>> + if (changelink &&
>> + ip_tunnel_info_af(&geneve->info) == AF_INET6) {
>> + info->mode &= ~IP_TUNNEL_INFO_IPV6;
>> + info->key.tun_flags &= ~TUNNEL_CSUM;
>> + *use_udp6_rx_checksums = false;
>> + }
>> }
>
> I don't understand this "changelink" guarded code, why do you need to
> clear all of this state out if the existing tunnel type if AF_INET6
> and only when doing a changelink?
>
> In any event, I think you need to add a comment explaining it.
>
If geneve link was overlayed over IPv6 network and now the user modifies the
link to be over IPv4 network by doing
# ip link set gen0 type geneve id 100 remote 192.168.13.2
Then we will need to
- reset info->mode to be not IPv6 type
- the default for UDP checksum over IPv4 is 'no', so reset that and
- set use_udp6_rx_checksums to its default value which is false.
I will capture the above information concisely in a comment around that
'changelink' guard.
thanks,
~Girish
^ permalink raw reply
* Re: linux-next: Tree for May 16 (net/core)
From: Eric Dumazet @ 2017-05-16 20:12 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Randy Dunlap, Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, netdev@vger.kernel.org
In-Reply-To: <CAP=VYLoYkz1HE4yOHVGQvBanDtpkWhtHBMvbeuyd8PtNFCivRQ@mail.gmail.com>
On Tue, May 16, 2017 at 12:44 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On Tue, May 16, 2017 at 12:28 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
>> On 05/15/17 18:21, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20170515:
>>>
>>
>> on i386 or x86_64:
>>
>> when CONFIG_INET is not enabled:
>>
>> ../net/core/sock.c: In function 'skb_orphan_partial':
>> ../net/core/sock.c:1810:2: error: implicit declaration of function 'skb_is_tcp_pure_ack' [-Werror=implicit-function-declaration]
>> if (skb_is_tcp_pure_ack(skb))
>
> Automated bisect on an ARM build with the same issue reveals:
>
> f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9 is the first bad commit
> commit f6ba8d33cfbb46df569972e64dbb5bb7e929bfd9
> Author: Eric Dumazet <edumazet@google.com>
> Date: Thu May 11 15:24:41 2017 -0700
>
> netem: fix skb_orphan_partial()
>
> I should have known that lowering skb->truesize was dangerous :/
>
> In case packets are not leaving the host via a standard Ethernet device,
> but looped back to local sockets, bad things can happen, as reported
> by Michael Madsen ( https://bugzilla.kernel.org/show_bug.cgi?id=195713 )
>
> So instead of tweaking skb->truesize, lets change skb->destructor
> and keep a reference on the owner socket via its sk_refcnt.
>
> Fixes: f2f872f9272a ("netem: Introduce skb_orphan_partial() helper")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Michael Madsen <mkm@nabto.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> :040000 040000 7bfb7a6f5e12373b1c50ede2455b6ddd6d79cee0
> b45b7255322f1dff5e3ab8d3d707cf38a91c76ce M net
> bisect run success
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/13033081/
>
> I'm guessing Eric already knows about this but I've Cc'd him just in case.
I was not aware of this, I will submit a fix, thanks.
^ permalink raw reply
* Re: switchdev offload & ecmp
From: Nicolas Dichtel @ 2017-05-16 20:22 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Jiri Pirko, Nikolay Aleksandrov, Roopa Prabhu, netdev
In-Reply-To: <20170516141149.GA1874@splinter.mtl.com>
Le 16/05/2017 à 16:11, Ido Schimmel a écrit :
> On Tue, May 16, 2017 at 02:57:47PM +0200, Nicolas Dichtel wrote:
>>>> I suspect that there can be scenarii where some packets of a flow are forwarded
>>>> by the driver and some other are forwarded by the kernel.
>>>
>>> Can you elaborate? The kernel only sees specific packets, which were
>>> trapped to the CPU. See:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/ethernet/mellanox/mlxsw/spectrum.c#n2996
>> Ok, this part was not clear for me, thank you for the pointer.
>>
>> So, when an arp resolution is needed, the packets are not trapped to the CPU,
>> the device manages the queue itself?
>
> There are two cases here. If you need an ARP resolution following a hit
> of a directly connected route and this neighbour isn't in the device's
> table, then packet is trapped (HOST_MISS_IPV4 in above list) to the CPU
> and triggers ARP resolution in the kernel. Eventually a NETEVENT will be
> sent and the neighbour will be programmed to the device.
>
> If you need an ARP resolution of a nexthop, then this is a bit
> different. If you have an ECMP group with several nexthops, then once
> one of them is resolved, packets will be forwarded using it. To make
> sure other nexthops will also be resolved we try to periodically refresh
> them. Otherwise packets will always be forwarded using a single nexthop,
> as the kernel won't have motivation to resolve the others.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c#n987
>
> In case no nexthops can be resolved, then packets will be trapped to the
> CPU (RTR_INGRESS0 in above list) and forwarded by the kernel.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c#n1896
>
Ok, thank you for the details.
Regards,
Nicolas
^ permalink raw reply
* Re: [patch net-next v3 01/10] net: sched: move tc_classify function to cls_api.c
From: Cong Wang @ 2017-05-16 20:25 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <20170516172802.1317-2-jiri@resnulli.us>
On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Move tc_classify function to cls_api.c where it belongs, rename it to
> fit the namespace.
>
It is not a pure move, you silently remove the CONFIG_NET_CLS_ACT
macros in tc_classify(). Probably not buggy, just redundancy when
actions are not compiled.
^ permalink raw reply
* [PATCH net] net: fix compile error in skb_orphan_partial()
From: Eric Dumazet @ 2017-05-16 20:27 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Randy Dunlap, Stephen Rothwell, netdev@vger.kernel.org
In-Reply-To: <CAP=VYLoYkz1HE4yOHVGQvBanDtpkWhtHBMvbeuyd8PtNFCivRQ@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
If CONFIG_INET is not set, net/core/sock.c can not compile :
net/core/sock.c: In function ‘skb_orphan_partial’:
net/core/sock.c:1810:2: error: implicit declaration of function
‘skb_is_tcp_pure_ack’ [-Werror=implicit-function-declaration]
if (skb_is_tcp_pure_ack(skb))
^
Fix this by always including <net/tcp.h>
Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/core/sock.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index e43e71d7856b385111cd4c4b1bd835a78c670c60..727f924b7f91f495d9e7a4e7297c9c937d3258ed 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -139,10 +139,7 @@
#include <trace/events/sock.h>
-#ifdef CONFIG_INET
#include <net/tcp.h>
-#endif
-
#include <net/busy_poll.h>
static DEFINE_MUTEX(proto_list_mutex);
^ permalink raw reply related
* [PATCH net 0/2] bnxt_en: DCBX fixes.
From: Michael Chan @ 2017-05-16 20:39 UTC (permalink / raw)
To: davem; +Cc: netdev
2 bug fixes for the case where the NIC's firmware DCBX agent is enabled.
With these fixes, we will return the proper information to lldpad.
Michael Chan (2):
bnxt_en: Call bnxt_dcb_init() after getting firmware DCBX
configuration.
bnxt_en: Check status of firmware DCBX agent before setting
DCB_CAP_DCBX_HOST.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +--
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 ++++--
2 files changed, 5 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 1/2] bnxt_en: Call bnxt_dcb_init() after getting firmware DCBX configuration.
From: Michael Chan @ 2017-05-16 20:39 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1494967184-12865-1-git-send-email-michael.chan@broadcom.com>
In the current code, bnxt_dcb_init() is called too early before we
determine if the firmware DCBX agent is running or not. As a result,
we are not setting the DCB_CAP_DCBX_HOST and DCB_CAP_DCBX_LLD_MANAGED
flags properly to report to DCBNL.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index b56c54d..03f55da 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -7630,8 +7630,6 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->min_mtu = ETH_ZLEN;
dev->max_mtu = BNXT_MAX_MTU;
- bnxt_dcb_init(bp);
-
#ifdef CONFIG_BNXT_SRIOV
init_waitqueue_head(&bp->sriov_cfg_wait);
#endif
@@ -7669,6 +7667,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
bnxt_hwrm_func_qcfg(bp);
bnxt_hwrm_port_led_qcaps(bp);
bnxt_ethtool_init(bp);
+ bnxt_dcb_init(bp);
bnxt_set_rx_skb_mode(bp, false);
bnxt_set_tpa_flags(bp);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/2] bnxt_en: Check status of firmware DCBX agent before setting DCB_CAP_DCBX_HOST.
From: Michael Chan @ 2017-05-16 20:39 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1494967184-12865-1-git-send-email-michael.chan@broadcom.com>
Otherwise, all the host based DCBX settings from lldpad will fail if the
firmware DCBX agent is running.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
index 46de2f8..5c6dd0c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
@@ -553,8 +553,10 @@ static u8 bnxt_dcbnl_setdcbx(struct net_device *dev, u8 mode)
if ((mode & DCB_CAP_DCBX_VER_CEE) || !(mode & DCB_CAP_DCBX_VER_IEEE))
return 1;
- if ((mode & DCB_CAP_DCBX_HOST) && BNXT_VF(bp))
- return 1;
+ if (mode & DCB_CAP_DCBX_HOST) {
+ if (BNXT_VF(bp) || (bp->flags & BNXT_FLAG_FW_LLDP_AGENT))
+ return 1;
+ }
if (mode == bp->dcbx_cap)
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/2] drivers: net: DSA: Sort drivers
From: Andrew Lunn @ 2017-05-16 20:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Vivien Didelot, Andrew Lunn
In-Reply-To: <1494967208-11550-1-git-send-email-andrew@lunn.ch>
With more drivers being added, it is time to sort the drivers to
impose some order.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/Kconfig | 40 ++++++++++++++++++++--------------------
drivers/net/dsa/Makefile | 6 +++---
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 862ee22303c2..68131a45ac5e 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -1,13 +1,7 @@
menu "Distributed Switch Architecture drivers"
depends on HAVE_NET_DSA
-config NET_DSA_MV88E6060
- tristate "Marvell 88E6060 ethernet switch chip support"
- depends on NET_DSA
- select NET_DSA_TAG_TRAILER
- ---help---
- This enables support for the Marvell 88E6060 ethernet switch
- chip.
+source "drivers/net/dsa/b53/Kconfig"
config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
@@ -21,19 +15,6 @@ config NET_DSA_BCM_SF2
This enables support for the Broadcom Starfighter 2 Ethernet
switch chips.
-source "drivers/net/dsa/b53/Kconfig"
-
-source "drivers/net/dsa/mv88e6xxx/Kconfig"
-
-config NET_DSA_QCA8K
- tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
- depends on NET_DSA
- select NET_DSA_TAG_QCA
- select REGMAP
- ---help---
- This enables support for the Qualcomm Atheros QCA8K Ethernet
- switch chips.
-
config NET_DSA_LOOP
tristate "DSA mock-up Ethernet switch chip support"
depends on NET_DSA
@@ -50,6 +31,25 @@ config NET_DSA_MT7530
This enables support for the Mediatek MT7530 Ethernet switch
chip.
+config NET_DSA_MV88E6060
+ tristate "Marvell 88E6060 ethernet switch chip support"
+ depends on NET_DSA
+ select NET_DSA_TAG_TRAILER
+ ---help---
+ This enables support for the Marvell 88E6060 ethernet switch
+ chip.
+
+source "drivers/net/dsa/mv88e6xxx/Kconfig"
+
+config NET_DSA_QCA8K
+ tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
+ depends on NET_DSA
+ select NET_DSA_TAG_QCA
+ select REGMAP
+ ---help---
+ This enables support for the Qualcomm Atheros QCA8K Ethernet
+ switch chips.
+
config NET_DSA_SMSC_LAN9303
tristate
select NET_DSA_TAG_LAN9303
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index edd630361736..9613f36083a6 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -1,11 +1,11 @@
-obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_BCM_SF2) += bcm-sf2.o
bcm-sf2-objs := bcm_sf2.o bcm_sf2_cfp.o
-obj-$(CONFIG_NET_DSA_QCA8K) += qca8k.o
+obj-$(CONFIG_NET_DSA_LOOP) += dsa_loop.o dsa_loop_bdinfo.o
obj-$(CONFIG_NET_DSA_MT7530) += mt7530.o
+obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
+obj-$(CONFIG_NET_DSA_QCA8K) += qca8k.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
obj-y += b53/
obj-y += mv88e6xxx/
-obj-$(CONFIG_NET_DSA_LOOP) += dsa_loop.o dsa_loop_bdinfo.o
--
2.11.0
^ permalink raw reply related
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