* Re: [PATCH 0/5] Fixes coding style in xilinx_emaclite.c
From: David Miller @ 2018-06-19 22:55 UTC (permalink / raw)
To: radhey.shyam.pandey
Cc: andrew, michal.simek, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1529322610-27215-1-git-send-email-radhey.shyam.pandey@xilinx.com>
From: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Date: Mon, 18 Jun 2018 17:20:05 +0530
> This patchset fixes checkpatch and kernel-doc warnings in
> xilinx emaclite driver. No functional change.
Such cleanups are only appropriate for net-next, which is closed at this
time.
^ permalink raw reply
* Re: [PATCH] net: net_failover: fix typo in net_failover_slave_register()
From: David Miller @ 2018-06-19 22:57 UTC (permalink / raw)
To: liran.alon; +Cc: netdev, linux-kernel, idan.brown
In-Reply-To: <1529323445-23777-1-git-send-email-liran.alon@oracle.com>
From: Liran Alon <liran.alon@oracle.com>
Date: Mon, 18 Jun 2018 15:04:05 +0300
> Sync both unicast and multicast lists instead of unicast twice.
>
> Fixes: cfc80d9a116 ("net: Introduce net_failover driver")
> Reviewed-by: Joao Martins <joao.m.martins@oracle.com>
> Signed-off-by: Liran Alon <liran.alon@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/ipv6: respect rcu grace period before freeing fib6_info
From: David Miller @ 2018-06-19 22:58 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, dsahern
In-Reply-To: <20180618122431.131265-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 18 Jun 2018 05:24:31 -0700
> syzbot reported use after free that is caused by fib6_info being
> freed without a proper RCU grace period.
...
> Fixes: a64efe142f5e ("net/ipv6: introduce fib6_info struct and helpers")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Ahern <dsahern@gmail.com>
> Reported-by: syzbot+9e6d75e3edef427ee888@syzkaller.appspotmail.com
Applied.
^ permalink raw reply
* Re: [PATCH] ptp: replace getnstimeofday64() with ktime_get_real_ts64()
From: David Miller @ 2018-06-19 23:00 UTC (permalink / raw)
To: arnd; +Cc: richardcochran, yangbo.lu, y2038, fabio.estevam, netdev,
linux-kernel
In-Reply-To: <20180618142109.3445025-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 18 Jun 2018 16:20:39 +0200
> getnstimeofday64() is deprecated and getting replaced throughout
> the kernel with ktime_get_*() based helpers for a more consistent
> interface.
>
> The two functions do the exact same thing, so this is just
> a cosmetic change.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: use ktime_get_real_ts64() instead of getnstimeofday64()
From: David Miller @ 2018-06-19 23:01 UTC (permalink / raw)
To: arnd
Cc: weilin.chang, dvlasenk, y2038, veerasenareddy.burru,
ricardo.farrington, linux-kernel, derek.chickles, satananda.burla,
intiyaz.basha, vijaya.guvva, felix.manlunas, raghu.vatsavayi,
netdev
In-Reply-To: <20180618151724.1406034-1-arnd@arndb.de>
Arnd, please resubmit these when I open net-next up again, which
should be over the upcoming weekend.
Thank you.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: Incomplete fix for be9c798 / 7b2ee50 hv_netvsc: common detach logic?
From: Greg KH @ 2018-06-19 23:01 UTC (permalink / raw)
To: Thomas Walker; +Cc: devel, Stephen Hemminger, netdev
In-Reply-To: <20180619191941.GD32145@twosigma.com>
On Tue, Jun 19, 2018 at 03:19:41PM -0400, Thomas Walker wrote:
> Upon updating some internal kernels from 4.14.18 to 4.14.49, our hyper-v guests failed to bring up network interfaces on boot, logging "A link change request failed with some changes committed already. Interface eth0 may have been left with an inconsistent configuration, please check." Running 'ifconfig eth0 up' appears to fix the problem temporarily so I went about bisecting which landed on:
>
> commit be9c798d0d13ae609a91177323ac816545c39d28
> Author: Stephen Hemminger <stephen@networkplumber.org>
> Date: Mon May 14 15:32:18 2018 -0700
>
> hv_netvsc: common detach logic
>
> [ Commit 7b2ee50c0cd513a176a26a71f2989facdd75bfea upstream. ]
>
> Make common function for detaching internals of device
> during changes to MTU and RSS. Make sure no more packets
> are transmitted and all packets have been received before
> doing device teardown.
>
> Change the wait logic to be common and use usleep_range().
>
> Changes transmit enabling logic so that transmit queues are disabled
> during the period when lower device is being changed. And enabled
> only after sub channels are setup. This avoids issue where it could
> be that a packet was being sent while subchannel was not initialized.
>
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>
> The removal of which does indeed fix the problem. That led me to:
>
> commit 52acf73b6e9a6962045feb2ba5a8921da2201915
> Author: Dexuan Cui <decui@microsoft.com>
> Date: Wed Jun 6 21:32:51 2018 +0000
>
> hv_netvsc: Fix a network regression after ifdown/ifup
>
> Recently people reported the NIC stops working after
> "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
> enabled, after the refactoring of the common detach logic: when the NIC
> has sub-channels, usually we enable all the TX queues after all
> sub-channels are set up: see rndis_set_subchannel() ->
> netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
> the number of channels doesn't change, we also must make sure the TX queues
> are enabled. The patch fixes the regression.
>
> Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: K. Y. Srinivasan <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Which sounded very promising, but does not seem to fully fix the issue. Doing some more digging, I was able to determine that the message coincides with 'ip link set dev eth0 mtu 1300 up' very shortly (>~1 second) after the hv_netvsc driver loads. If I delay the mtu change until well after the driver loads, everything works fine. If I unload hv_netvsc and then reload it and apply the mtu change immediately, the failure re-occurs. So something is racy here, and the above doesn't entirely address it.
>
> I'm happy to test out any suggested patches and/or do additional debugging if anyone has any suggestions.
>
> (oh, and I did also try 4.18-rc1 and the problem still persists)
Always cc: the authors of the patch you are having problems with, along
with the mailing list for the networking subsystem, so that the right
people know to look at this.
Now fixed...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net] net/tcp: Fix socket lookups with SO_BINDTODEVICE
From: David Miller @ 2018-06-19 23:04 UTC (permalink / raw)
To: dsahern; +Cc: netdev, lberger, renato, dsahern
In-Reply-To: <20180618193037.3365-1-dsahern@kernel.org>
From: dsahern@kernel.org
Date: Mon, 18 Jun 2018 12:30:37 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Similar to 69678bcd4d2d ("udp: fix SO_BINDTODEVICE"), TCP socket lookups
> need to fail if dev_match is not true. Currently, a packet to a given port
> can match a socket bound to device when it should not. In the VRF case,
> this causes the lookup to hit a VRF socket and not a global socket
> resulting in a response trying to go through the VRF when it should it.
^^^
"not", I fixed this up for you.
> Fixes: 3fa6f616a7a4d ("net: ipv4: add second dif to inet socket lookups")
> Fixes: 4297a0ef08572 ("net: ipv6: add second dif to inet6 socket lookups")
> Reported-by: Lou Berger <lberger@labn.net>
> Diagnosed-by: Renato Westphal <renato@opensourcerouting.org>
> Tested-by: Renato Westphal <renato@opensourcerouting.org>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: Incomplete fix for be9c798 / 7b2ee50 hv_netvsc: common detach logic?
From: Stephen Hemminger @ 2018-06-19 23:07 UTC (permalink / raw)
To: Greg KH; +Cc: devel, Stephen Hemminger, Thomas Walker, netdev
In-Reply-To: <20180619230150.GA24530@kroah.com>
On Wed, 20 Jun 2018 08:01:50 +0900
Greg KH <greg@kroah.com> wrote:
> On Tue, Jun 19, 2018 at 03:19:41PM -0400, Thomas Walker wrote:
> > Upon updating some internal kernels from 4.14.18 to 4.14.49, our hyper-v guests failed to bring up network interfaces on boot, logging "A link change request failed with some changes committed already. Interface eth0 may have been left with an inconsistent configuration, please check." Running 'ifconfig eth0 up' appears to fix the problem temporarily so I went about bisecting which landed on:
> >
> > commit be9c798d0d13ae609a91177323ac816545c39d28
> > Author: Stephen Hemminger <stephen@networkplumber.org>
> > Date: Mon May 14 15:32:18 2018 -0700
> >
> > hv_netvsc: common detach logic
> >
> > [ Commit 7b2ee50c0cd513a176a26a71f2989facdd75bfea upstream. ]
> >
> > Make common function for detaching internals of device
> > during changes to MTU and RSS. Make sure no more packets
> > are transmitted and all packets have been received before
> > doing device teardown.
> >
> > Change the wait logic to be common and use usleep_range().
> >
> > Changes transmit enabling logic so that transmit queues are disabled
> > during the period when lower device is being changed. And enabled
> > only after sub channels are setup. This avoids issue where it could
> > be that a packet was being sent while subchannel was not initialized.
> >
> > Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> >
> > The removal of which does indeed fix the problem. That led me to:
> >
> > commit 52acf73b6e9a6962045feb2ba5a8921da2201915
> > Author: Dexuan Cui <decui@microsoft.com>
> > Date: Wed Jun 6 21:32:51 2018 +0000
> >
> > hv_netvsc: Fix a network regression after ifdown/ifup
> >
> > Recently people reported the NIC stops working after
> > "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
> > enabled, after the refactoring of the common detach logic: when the NIC
> > has sub-channels, usually we enable all the TX queues after all
> > sub-channels are set up: see rndis_set_subchannel() ->
> > netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
> > the number of channels doesn't change, we also must make sure the TX queues
> > are enabled. The patch fixes the regression.
> >
> > Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> > Cc: Stephen Hemminger <sthemmin@microsoft.com>
> > Cc: K. Y. Srinivasan <kys@microsoft.com>
> > Cc: Haiyang Zhang <haiyangz@microsoft.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > Which sounded very promising, but does not seem to fully fix the issue. Doing some more digging, I was able to determine that the message coincides with 'ip link set dev eth0 mtu 1300 up' very shortly (>~1 second) after the hv_netvsc driver loads. If I delay the mtu change until well after the driver loads, everything works fine. If I unload hv_netvsc and then reload it and apply the mtu change immediately, the failure re-occurs. So something is racy here, and the above doesn't entirely address it.
> >
> > I'm happy to test out any suggested patches and/or do additional debugging if anyone has any suggestions.
> >
> > (oh, and I did also try 4.18-rc1 and the problem still persists)
>
> Always cc: the authors of the patch you are having problems with, along
> with the mailing list for the networking subsystem, so that the right
> people know to look at this.
Let me take a look at it, and log it into the bug system.
^ permalink raw reply
* Re: [PATCH net] enic: do not overwrite error code
From: David Miller @ 2018-06-19 23:10 UTC (permalink / raw)
To: gvaradar; +Cc: netdev, ben.hutchings, benve, gregkh, alexander.levin
In-Reply-To: <20180618170105.1301-1-gvaradar@cisco.com>
From: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date: Mon, 18 Jun 2018 10:01:05 -0700
> In failure path, we overwrite err to what vnic_rq_disable() returns. In
> case it returns 0, enic_open() returns success in case of error.
>
> Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
> Fixes: e8588e268509 ("enic: enable rq before updating rq descriptors")
> Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Applied and queued up for -stable.
^ permalink raw reply
* davinci_emac failures in 4.18-rc1 on AM3517-EVM
From: Adam Ford @ 2018-06-19 23:11 UTC (permalink / raw)
To: linux-omap, netdev
I am not sure if anyone else has seen this. If not, I'll bisect, but
the AM3517 ethernet seems to have died, and it's throwing some errors
[ 2.708933] davinci_mdio davinci_mdio.0: failed to get device clock
[ 2.715363] davinci_mdio: probe of davinci_mdio.0 failed with error -2
[snip]
[ 3.054552] davinci_emac davinci_emac.0: failed to get EMAC clock
[ 3.061195] davinci_emac: probe of davinci_emac.0 failed with error -16
If no one has seen this, I'll look into it, but I didn't want to waste
time if someone is already aware of it.
adam
^ permalink raw reply
* Re: bpfilter compile failure on parisc
From: John David Anglin @ 2018-06-19 23:05 UTC (permalink / raw)
To: Meelis Roos, netdev, linux-parisc
In-Reply-To: <alpine.LRH.2.21.1806192036240.10716@math.ut.ee>
On 2018-06-19 1:38 PM, Meelis Roos wrote:
> Tried enabling bpfilter on parisc, got this:
>
> HOSTCC net/bpfilter/main.o
> net/bpfilter/main.c:3:21: fatal error: sys/uio.h: No such file or directory
> #include <sys/uio.h>
Probably has something to do with the include directories searched by
HOSTCC. The location of
the file is "/usr/include/hppa-linux-gnu/sys/uio.h".
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply
* Re: Incomplete fix for be9c798 / 7b2ee50 hv_netvsc: common detach logic?
From: Stephen Hemminger @ 2018-06-19 23:14 UTC (permalink / raw)
To: Greg KH; +Cc: devel, Stephen Hemminger, Thomas Walker, netdev
In-Reply-To: <20180619230150.GA24530@kroah.com>
On Wed, 20 Jun 2018 08:01:50 +0900
Greg KH <greg@kroah.com> wrote:
> On Tue, Jun 19, 2018 at 03:19:41PM -0400, Thomas Walker wrote:
> > Upon updating some internal kernels from 4.14.18 to 4.14.49, our hyper-v guests failed to bring up network interfaces on boot, logging "A link change request failed with some changes committed already. Interface eth0 may have been left with an inconsistent configuration, please check." Running 'ifconfig eth0 up' appears to fix the problem temporarily so I went about bisecting which landed on:
> >
> > commit be9c798d0d13ae609a91177323ac816545c39d28
> > Author: Stephen Hemminger <stephen@networkplumber.org>
> > Date: Mon May 14 15:32:18 2018 -0700
> >
> > hv_netvsc: common detach logic
> >
> > [ Commit 7b2ee50c0cd513a176a26a71f2989facdd75bfea upstream. ]
> >
> > Make common function for detaching internals of device
> > during changes to MTU and RSS. Make sure no more packets
> > are transmitted and all packets have been received before
> > doing device teardown.
> >
> > Change the wait logic to be common and use usleep_range().
> >
> > Changes transmit enabling logic so that transmit queues are disabled
> > during the period when lower device is being changed. And enabled
> > only after sub channels are setup. This avoids issue where it could
> > be that a packet was being sent while subchannel was not initialized.
> >
> > Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> >
> > The removal of which does indeed fix the problem. That led me to:
> >
> > commit 52acf73b6e9a6962045feb2ba5a8921da2201915
> > Author: Dexuan Cui <decui@microsoft.com>
> > Date: Wed Jun 6 21:32:51 2018 +0000
> >
> > hv_netvsc: Fix a network regression after ifdown/ifup
> >
> > Recently people reported the NIC stops working after
> > "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
> > enabled, after the refactoring of the common detach logic: when the NIC
> > has sub-channels, usually we enable all the TX queues after all
> > sub-channels are set up: see rndis_set_subchannel() ->
> > netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
> > the number of channels doesn't change, we also must make sure the TX queues
> > are enabled. The patch fixes the regression.
> >
> > Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> > Cc: Stephen Hemminger <sthemmin@microsoft.com>
> > Cc: K. Y. Srinivasan <kys@microsoft.com>
> > Cc: Haiyang Zhang <haiyangz@microsoft.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > Which sounded very promising, but does not seem to fully fix the issue. Doing some more digging, I was able to determine that the message coincides with 'ip link set dev eth0 mtu 1300 up' very shortly (>~1 second) after the hv_netvsc driver loads. If I delay the mtu change until well after the driver loads, everything works fine. If I unload hv_netvsc and then reload it and apply the mtu change immediately, the failure re-occurs. So something is racy here, and the above doesn't entirely address it.
> >
> > I'm happy to test out any suggested patches and/or do additional debugging if anyone has any suggestions.
> >
> > (oh, and I did also try 4.18-rc1 and the problem still persists)
>
> Always cc: the authors of the patch you are having problems with, along
> with the mailing list for the networking subsystem, so that the right
> people know to look at this.
How are you changing the MTU? and starting the device.
When MTU changes the device has to reconnect with the host. This takes a small amount of time
and no changes to device state are possible then.
If MTU change happens and at the same time some other script tries to bring up the connection,
then that script will get an error.
^ permalink raw reply
* Re: [PATCH] [net-next, v2] tcp: use monotonic timestamps for PAWS
From: Eric Dumazet @ 2018-06-19 23:38 UTC (permalink / raw)
To: Arnd Bergmann, Herbert Xu, David S. Miller, Eric Dumazet,
Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: y2038, Harsh Jain, Atul Gupta, Michael Werner,
Gustavo A. R. Silva, Yuchung Cheng, Neal Cardwell,
Soheil Hassas Yeganeh, Florian Westphal, Christoph Paasch,
Lawrence Brakmo, linux-crypto, linux-kernel, netdev
In-Reply-To: <20180619123724.2535981-1-arnd@arndb.de>
On 06/19/2018 05:36 AM, Arnd Bergmann wrote:
> Using get_seconds() for timestamps is deprecated since it can lead
> to overflows on 32-bit systems. While the interface generally doesn't
> overflow until year 2106, the specific implementation of the TCP PAWS
> algorithm breaks in 2038 when the intermediate signed 32-bit timestamps
> overflow.
>
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: use time_before32()/time_after32() everywhere as suggested
> Eric Dumazet
Thanks a lot Arnd.
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] net: propagate dev_get_valid_name return code
From: David Miller @ 2018-06-19 23:38 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1529400197-24165-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Tue, 19 Jun 2018 17:23:17 +0800
> if dev_get_valid_name failed, propagate its return code
>
> and remove the setting err to ENODEV, it will be set to
> 0 again before dev_change_net_namespace exits.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] 6lowpan: iphc: reset mac_header after decompress to fix panic
From: Michael Scott @ 2018-06-19 23:44 UTC (permalink / raw)
Cc: Michael Scott, Alexander Aring, Jukka Rissanen, David S. Miller,
linux-bluetooth, linux-wpan, netdev, linux-kernel
After decompression of 6lowpan socket data, an IPv6 header is inserted
before the existing socket payload. After this, we reset the
network_header value of the skb to account for the difference in payload
size from prior to decompression + the addition of the IPv6 header.
However, we fail to reset the mac_header value.
Leaving the mac_header value untouched here, can cause a calculation
error in net/packet/af_packet.c packet_rcv() function when an
AF_PACKET socket is opened in SOCK_RAW mode for use on a 6lowpan
interface.
On line 2088, the data pointer is moved backward by the value returned
from skb_mac_header(). If skb->data is adjusted so that it is before
the skb->head pointer (which can happen when an old value of mac_header
is left in place) the kernel generates a panic in net/core/skbuff.c
line 1717.
This panic can be generated by BLE 6lowpan interfaces (such as bt0) and
802.15.4 interfaces (such as lowpan0) as they both use the same 6lowpan
sources for compression and decompression.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
---
net/6lowpan/iphc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 6b1042e21656..52fad5dad9f7 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -770,6 +770,7 @@ int lowpan_header_decompress(struct sk_buff *skb, const struct net_device *dev,
hdr.hop_limit, &hdr.daddr);
skb_push(skb, sizeof(hdr));
+ skb_reset_mac_header(skb);
skb_reset_network_header(skb);
skb_copy_to_linear_data(skb, &hdr, sizeof(hdr));
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net] net/sched: act_ife: fix recursive lock and idr leak
From: David Miller @ 2018-06-20 0:06 UTC (permalink / raw)
To: dcaratti; +Cc: jhs, xiyou.wangcong, netdev
In-Reply-To: <40b45f70ef007b222b36a4676174e597c41d697f.1529415169.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Tue, 19 Jun 2018 15:39:46 +0200
> a recursive lock warning [1] can be observed with the following script,
...
> in case the kernel was unable to run the last command (e.g. because of
> the impossibility to load 'act_meta_skbtcindex'). For a similar reason,
> the kernel can leak idr in the error path of tcf_ife_init(), because
> tcf_idr_release() is not called after successful idr reservation:
...
> Since tcfa_lock is already taken when the action is being edited, a call
> to tcf_idr_release() wrongly makes tcf_idr_cleanup() take the same lock
> again. On the other hand, tcf_idr_release() needs to be called in the
> error path of tcf_ife_init(), to undo the last tcf_idr_create() invocation.
> Fix both problems in tcf_ife_init().
> Since the cleanup() routine can now be called when ife->params is NULL,
> also add a NULL pointer check to avoid calling kfree_rcu(NULL, rcu).
>
> [1]
...
> Fixes: 4e8c86155010 ("net sched: net sched: ife action fix late binding")
> Fixes: ef6980b6becb ("introduce IFE action")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net/sched: act_ife: preserve the action control in case of error
From: David Miller @ 2018-06-20 0:06 UTC (permalink / raw)
To: dcaratti; +Cc: jhs, xiyou.wangcong, netdev
In-Reply-To: <717d0682de4fb24ed6818f2bf264202d22e1e8be.1529415179.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Tue, 19 Jun 2018 15:45:50 +0200
> in the following script
>
> # tc actions add action ife encode allow prio pass index 42
> # tc actions replace action ife encode allow tcindex drop index 42
>
> the action control should remain equal to 'pass', if the kernel failed
> to replace the TC action. Pospone the assignment of the action control,
> to ensure it is not overwritten in the error path of tcf_ife_init().
>
> Fixes: ef6980b6becb ("introduce IFE action")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net/usb/drivers: Remove useless hrtimer_active check
From: David Miller @ 2018-06-20 0:07 UTC (permalink / raw)
To: daniel.lezcano; +Cc: oliver, linux-usb, netdev, linux-kernel
In-Reply-To: <1529417671-21384-1-git-send-email-daniel.lezcano@linaro.org>
From: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Tue, 19 Jun 2018 16:14:30 +0200
> The code does:
>
> if (hrtimer_active(&t))
> hrtimer_cancel(&t);
>
> However, hrtimer_cancel() checks if the timer is active, so the
> test above is pointless.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH] bpfilter: fix build error
From: David Miller @ 2018-06-20 0:08 UTC (permalink / raw)
To: mcroce; +Cc: netdev, ast
In-Reply-To: <20180619151620.1912-1-mcroce@redhat.com>
From: Matteo Croce <mcroce@redhat.com>
Date: Tue, 19 Jun 2018 17:16:20 +0200
> bpfilter Makefile assumes that the system locale is en_US, and the
> parsing of objdump output fails.
> Set LC_ALL=C and, while at it, rewrite the objdump parsing so it spawns
> only 2 processes instead of 7.
>
> Fixes: d2ba09c17a064 ("net: add skeleton of bpfilter kernel module")
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bpfilter: ignore binary files
From: David Miller @ 2018-06-20 0:08 UTC (permalink / raw)
To: mcroce; +Cc: netdev, ast
In-Reply-To: <20180619152136.2340-1-mcroce@redhat.com>
From: Matteo Croce <mcroce@redhat.com>
Date: Tue, 19 Jun 2018 17:21:36 +0200
> net/bpfilter/bpfilter_umh is a binary file generated when bpfilter is
> enabled, add it to .gitignore to avoid committing it.
>
> Fixes: d2ba09c17a064 ("net: add skeleton of bpfilter kernel module")
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
From: Michael Ellerman @ 2018-06-20 0:13 UTC (permalink / raw)
To: Eric Dumazet, Mathieu Malaterre, David S. Miller
Cc: Eric Dumazet, linux-kernel, netdev
In-Reply-To: <fbb95c11-240c-1a11-0a62-0483908c577e@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On 06/15/2018 11:56 AM, Mathieu Malaterre wrote:
>> This reverts commit 88078d98d1bb085d72af8437707279e203524fa5.
>>
>> It causes regressions for people using chips driven by the sungem
>> driver. Suspicion is that the skb->csum value isn't being adjusted
>> properly.
>>
>> Symptoms as seen on G4+sungem are:
>>
>> [ 34.023281] eth0: hw csum failure
>> [ 34.023438] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #2
>> [ 34.023618] Call Trace:
>> [ 34.023707] [dffedbd0] [c069ddac] __skb_checksum_complete+0xf0/0x108 (unreliable)
>> [ 34.023948] [dffedbf0] [c0777a70] tcp_v4_rcv+0x604/0xe00
>> [ 34.024118] [dffedc70] [c0731624] ip_local_deliver_finish+0xa8/0x3c4
>> [ 34.024315] [dffedcb0] [c0732430] ip_local_deliver+0xf0/0x154
>> [ 34.024493] [dffedcf0] [c07328dc] ip_rcv+0x448/0x774
>> [ 34.024653] [dffedd50] [c06aeae0] __netif_receive_skb_core+0x5e8/0x1184
>> [ 34.024857] [dffedde0] [c06bba20] napi_gro_receive+0x160/0x22c
>> [ 34.025044] [dffede10] [e14b2590] gem_poll+0x7fc/0x1ac0 [sungem]
>> [ 34.025228] [dffedee0] [c06bacf0] net_rx_action+0x34c/0x618
>> [ 34.025402] [dffedf60] [c07fd27c] __do_softirq+0x16c/0x5f0
>> [ 34.025575] [dffedfd0] [c0064c7c] irq_exit+0x110/0x1a8
>> [ 34.025738] [dffedff0] [c0016170] call_do_irq+0x24/0x3c
>> [ 34.025903] [c0cf7e80] [c0009a84] do_IRQ+0x98/0x1a0
>> [ 34.026055] [c0cf7eb0] [c001b474] ret_from_except+0x0/0x14
>> [ 34.026225] --- interrupt: 501 at arch_cpu_idle+0x30/0x78
>> LR = arch_cpu_idle+0x30/0x78
>> [ 34.026510] [c0cf7f70] [c0cf6000] 0xc0cf6000 (unreliable)
>> [ 34.026682] [c0cf7f80] [c00a3868] do_idle+0xc4/0x158
>> [ 34.026835] [c0cf7fb0] [c00a3ab0] cpu_startup_entry+0x20/0x28
>> [ 34.027013] [c0cf7fc0] [c0998820] start_kernel+0x47c/0x490
>> [ 34.027181] [c0cf7ff0] [00003444] 0x3444
>>
>> See commit 7ce5a27f2ef8 ("Revert "net: Handle CHECKSUM_COMPLETE more
>> adequately in pskb_trim_rcsum()."") for previous reference.
>
> This fix seems to hide a bug in csum functions on this architecture.
>
> Or a bug on this NIC when receiving a small packet (less than 60 bytes).
> Maybe the padding bytes are not included in NIC provided csum, and not 0.
Just so I'm clear, this turned out to be a driver/hw problem rather than
the arch csum implementation?
cheers
^ permalink raw reply
* Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
From: Eric Dumazet @ 2018-06-20 0:19 UTC (permalink / raw)
To: Michael Ellerman, Eric Dumazet, Mathieu Malaterre,
David S. Miller
Cc: Eric Dumazet, linux-kernel, netdev
In-Reply-To: <87muvqwc06.fsf@concordia.ellerman.id.au>
On 06/19/2018 05:13 PM, Michael Ellerman wrote:
> Just so I'm clear, this turned out to be a driver/hw problem rather than
> the arch csum implementation?
Yes, that was a driver bug.
I will send an official patch to fix this.
You guys will have faster RX, since CHECKSUM_COMPLETE will finally be used up to TCP/UDP stacks.
^ permalink raw reply
* Re: [net RFC] net/mlx4_en: Use frag stride in crossing page boundary condition
From: Eric Dumazet @ 2018-06-20 0:25 UTC (permalink / raw)
To: Saeed Mahameed, eric.dumazet@gmail.com, kafai@fb.com,
Tariq Toukan
Cc: netdev@vger.kernel.org, edumazet@google.com
In-Reply-To: <deda277de538f2083fb23479f26afa03ffc79644.camel@mellanox.com>
On 06/19/2018 11:05 AM, Saeed Mahameed wrote:
> this is only true for XDP setup, for non XDP max stride_size can only
> be around ~3k and only for mtu > ~6k
>
> For XDP setup you suggested:
> - priv->frag_info[0].frag_size = eff_mtu;
> + priv->frag_info[0].frag_size = PAGE_SIZE;
>
> currently the condition is:
>
> release = frags->page_offset + frag_info->frag_size > PAGE_SIZE;
>
> so my solution and yours have the same problem you described above.
>
> the problem is not with the initial values or with stride/farg size
> math, it just that in XDP we shouldn't reuse at ALL. I agree with you
> that we need to optimize and maybe for PAGE_SIZE > 8k we need to allow
> XDP setup to reuses. but for now there is a data corruption to handle.
Sure, we all agree there is a bug to fix.
The way you are fixing it is kind of illogical.
The NIC can use a frag if its _size_ is big enough to receive the frame.
The _stride_ is an abstraction created by the driver to report an estimation of the _truesize_,
or memory consumption, so that linux can better track overall memory usage.
For example, if MTU=1500, the size of the fragment is 1536 bytes, but since we can put only
2 fragments per 4KB page (on x86), we declare the _stride_ to be 2048 bytes.
Declaring that a final blob of a page, being 1600 bytes, not able to receive a frame because
_stride_ is 2048 is illogical and waste resources.
^ permalink raw reply
* Re: [PATCH net-next,RFC 00/13] New fast forwarding path
From: Andrew Collins @ 2018-06-20 0:56 UTC (permalink / raw)
To: David Miller; +Cc: f.fainelli, pablo, netfilter-devel, netdev, Steffen Klassert
In-Reply-To: <20180614.165549.1790121217625223670.davem@davemloft.net>
On Thu, Jun 14, 2018 at 5:55 PM, David Miller <davem@davemloft.net> wrote:
> And guess what? Then millions of possibilities would have been
> openned up, rather than just this one special case.
>
> So, I ask, please see the larger picture.
+cc netdev/etc
This is perhaps unrelated to the topic at hand, but as someone who's shipped
a bunch of devices over the years using the linux kernel forwarding path and
needs performance but wants to avoid moving to out of tree userspace offload
for all the reasons that you and many others have stated, is the long
term vision that the existing kernel forwarding path will transparently take
advantage of eBPF (ala bpfilter), or that users will write custom/individualized
eBPF forwarding paths for their usecases as necessary?
I (and I suspect many others) will start on the latter anyways, I'm just curious
whether it's desired/expected that such custom fastpath users will eventually
be rolled back into/replaced by a transparent upstream in-kernel equivalent.
^ permalink raw reply
* Re: [PATCH] selftests: net: add config fragments
From: Shannon Nelson @ 2018-06-20 1:42 UTC (permalink / raw)
To: Anders Roxell, davem, shuah, fw; +Cc: netdev, linux-kselftest, linux-kernel
In-Reply-To: <20180619164111.30785-1-anders.roxell@linaro.org>
On 6/19/2018 9:41 AM, Anders Roxell wrote:
> Add fragments to pass bridge and vlan tests.
>
> Fixes: 33b01b7b4f19 ("selftests: add rtnetlink test script")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
>
> Hi,
>
> net/rtnetlink.sh still fails on tc hbt hierarchy, addrlabel and ipsec:
> Error: Specified qdisc not found.
> RTNETLINK answers: No such file or directory
> Error: Parent Qdisc doesn't exists.
> We have an error talking to the kernel, -1
> Error: Parent Qdisc doesn't exists.
> We have an error talking to the kernel, -1
> Error: Parent Qdisc doesn't exists.
> We have an error talking to the kernel, -1
> Error: Parent Qdisc doesn't exists.
> We have an error talking to the kernel, -1
> Error: Parent Qdisc doesn't exists.
> We have an error talking to the kernel, -1
> Error: Parent Qdisc doesn't exists.
> We have an error talking to the kernel, -1
> Error: Invalid handle.
> FAIL: tc htb hierarchy
>
> FAIL: ipv6 addrlabel
>
> FAIL: can't add fou port 7777, skipping test
> RTNETLINK answers: Operation not supported
> FAIL: can't add macsec interface, skipping test
> RTNETLINK answers: Protocol not supported
> RTNETLINK answers: No such process
> RTNETLINK answers: No such process
> ./rtnetlink.sh: line 527: 5356 Terminated ip x m >
> $tmpfile
> FAIL: ipsec
>
>
> I'm using iproute2 tag: 4.17 and tried the qdisc command from the
> function kci_test_tc in net/rtnetlink.sh:
> $ tc qdisc add dev lo root handle 1: htb
> Error: Specified qdisc not found.
>
> For kci_test_addrlabel it fails on this row:
> ip addrlabel list |grep -q "prefix dead::/64 dev lo label 1"
>
> Any idea why these three fails?
The "Terminated" line is there because "ip x m" had been put into the
background, and at the end of the ipsec test it is killed. I can try to
play some games with exec and redirection to make that go away.
The "FAIL: ipsec" is partly because the test isn't smart enough to look
to see if there is any offload actually available to test. I'm working
on a patch to netdevsim to add the ipsec-offload in order to have a
better test. And yes, this should say "ipsec-offload", not "ipsec".
I don't know about the qdisk or addrlabel issues.
Cheers,
sln
>
> Cheers,
> Anders
>
> tools/testing/selftests/net/config | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config
> index 7ba089b33e8b..cd3a2f1545b5 100644
> --- a/tools/testing/selftests/net/config
> +++ b/tools/testing/selftests/net/config
> @@ -12,3 +12,5 @@ CONFIG_NET_IPVTI=y
> CONFIG_INET6_XFRM_MODE_TUNNEL=y
> CONFIG_IPV6_VTI=y
> CONFIG_DUMMY=y
> +CONFIG_BRIDGE=y
> +CONFIG_VLAN_8021Q=y
>
^ 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