* 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
* 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: 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: 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
* 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: [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
* 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] 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: 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-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: [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] 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] 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 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 1/1] tcp: tcp_mtup_probe -> tcp_mtu_probe
From: David Miller @ 2018-06-19 22:55 UTC (permalink / raw)
To: jianjian.wang1; +Cc: edumazet, kuznet, yoshfuji, netdev
In-Reply-To: <CAP4sYWVqrAyE6sXerWe9Vn7N-jeMtDL_2xZGbu_ScebPY3iK3w@mail.gmail.com>
From: Wang Jian <jianjian.wang1@gmail.com>
Date: Mon, 18 Jun 2018 18:58:50 +0800
> Comment correction.
>
> Signed-off-by: Jian Wang <jianjian.wang1@gmail.com>
This patch was corrupted by your email client.
Please fix this, email the patch to yourself, and only resubmit this patch
to the mailing list when you can successfull apply the patch yourself that
you send in the test email.
Thank you.
^ permalink raw reply
* Re: [PATCH net] ipvlan: use ETH_MAX_MTU as max mtu
From: David Miller @ 2018-06-19 22:54 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jarod, maheshb
In-Reply-To: <3a944c2cbcff6df280847770decca4875b671959.1529309757.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 18 Jun 2018 16:15:57 +0800
> Similar to the fixes on team and bonding, this restores the ability
> to set an ipvlan device's mtu to anything higher than 1500.
>
> Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net: hamradio: use eth_broadcast_addr
From: David Miller @ 2018-06-19 22:52 UTC (permalink / raw)
To: stefan; +Cc: netdev, linux-kernel
In-Reply-To: <20180617214058.6926-1-stefan@agner.ch>
From: Stefan Agner <stefan@agner.ch>
Date: Sun, 17 Jun 2018 23:40:53 +0200
> The array bpq_eth_addr is only used to get the size of an
> address, whereas the bcast_addr is used to set the broadcast
> address. This leads to a warning when using clang:
> drivers/net/hamradio/bpqether.c:94:13: warning: variable 'bpq_eth_addr' is not
> needed and will not be emitted [-Wunneeded-internal-declaration]
> static char bpq_eth_addr[6];
> ^
>
> Remove both variables and use the common eth_broadcast_addr
> to set the broadcast address.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net] enic: initialize enic->rfs_h.lock in enic_probe
From: David Miller @ 2018-06-19 22:49 UTC (permalink / raw)
To: gvaradar; +Cc: benve, netdev
In-Reply-To: <20180619151524.1326-1-gvaradar@cisco.com>
From: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date: Tue, 19 Jun 2018 08:15:24 -0700
> lockdep spotted that we are using rfs_h.lock in enic_get_rxnfc() without
> initializing. rfs_h.lock is initialized in enic_open(). But ethtool_ops
> can be called when interface is down.
>
> Move enic_rfs_flw_tbl_init to enic_probe.
...
> Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Applied, thanks.
^ permalink raw reply
* Re: [net] bpf, xdp, i40e: fix i40e_build_skb skb reserve and truesize
From: David Miller @ 2018-06-19 22:41 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: daniel, netdev, nhorman, sassmann, jogreene, bjorn.topel,
john.fastabend
In-Reply-To: <20180619213354.30986-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 19 Jun 2018 14:33:54 -0700
> From: Daniel Borkmann <daniel@iogearbox.net>
>
> Using skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start))
> is clearly wrong since I40E_SKB_PAD already points to the offset where
> the original xdp->data was sitting since xdp->data_hard_start is defined
> as xdp->data - i40e_rx_offset(rx_ring) where latter offsets to I40E_SKB_PAD
> when build skb is used.
>
> However, also before cc5b114dcf98 ("bpf, i40e: add meta data support")
> this seems broken since bpf_xdp_adjust_head() helper could have been used
> to alter headroom and enlarge / shrink the frame and with that the assumption
> that the xdp->data remains unchanged does not hold and would push a bogus
> packet to upper stack.
>
> ixgbe got this right in 924708081629 ("ixgbe: add XDP support for pass and
> drop actions"). In any case, fix it by removing the I40E_SKB_PAD from both
> skb_reserve() and truesize calculation.
>
> Fixes: cc5b114dcf98 ("bpf, i40e: add meta data support")
> Fixes: 0c8493d90b6b ("i40e: add XDP support for pass and drop actions")
> Reported-by: Keith Busch <keith.busch@linux.intel.com>
> Reported-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Björn Töpel <bjorn.topel@intel.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Tested-by: Keith Busch <keith.busch@linux.intel.com>
> Acked-by: John Fastabend <john.fastabend@gmail.com>
> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
From: Eric Dumazet @ 2018-06-19 22:40 UTC (permalink / raw)
To: Andreas Schwab, Eric Dumazet
Cc: Mathieu Malaterre, David S. Miller, Eric Dumazet, LKML,
Christophe LEROY, Meelis Roos, netdev, linuxppc-dev
In-Reply-To: <87lgbav24y.fsf@igel.home>
On 06/19/2018 03:32 PM, Andreas Schwab wrote:
> On Jun 19 2018, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> diff --git a/drivers/net/ethernet/sun/sungem.c b/drivers/net/ethernet/sun/sungem.c
>> index 7a16d40a72d13cf1d522e8a3a396c826fe76f9b9..672d6748ab44f0890e92d5ca55d6ff6834c20dc9 100644
>> --- a/drivers/net/ethernet/sun/sungem.c
>> +++ b/drivers/net/ethernet/sun/sungem.c
>> @@ -60,8 +60,7 @@
>> #include <linux/sungem_phy.h>
>> #include "sungem.h"
>>
>> -/* Stripping FCS is causing problems, disabled for now */
>> -#undef STRIP_FCS
>> +#define STRIP_FCS
>>
>> #define DEFAULT_MSG (NETIF_MSG_DRV | \
>> NETIF_MSG_PROBE | \
>> @@ -435,7 +434,7 @@ static int gem_rxmac_reset(struct gem *gp)
>> writel(desc_dma & 0xffffffff, gp->regs + RXDMA_DBLOW);
>> writel(RX_RING_SIZE - 4, gp->regs + RXDMA_KICK);
>> val = (RXDMA_CFG_BASE | (RX_OFFSET << 10) |
>> - ((14 / 2) << 13) | RXDMA_CFG_FTHRESH_128);
>> + (ETH_HLEN << 13) | RXDMA_CFG_FTHRESH_128);
>> writel(val, gp->regs + RXDMA_CFG);
>> if (readl(gp->regs + GREG_BIFCFG) & GREG_BIFCFG_M66EN)
>> writel(((5 & RXDMA_BLANK_IPKTS) |
>> @@ -857,6 +856,14 @@ static int gem_rx(struct gem *gp, int work_to_do)
>>
>> csum = (__force __sum16)htons((status & RXDCTRL_TCPCSUM) ^ 0xffff);
>> skb->csum = csum_unfold(csum);
>> + {
>> + __wsum rsum = csum_partial(skb->data + ETH_HLEN, len - ETH_HLEN, 0);
>> + if (csum != csum_fold(rsum) && net_ratelimit())
>> + pr_err("sungem wrong csum : %x/%x, len %u bytes\n",
>> + csum, csum_fold(rsum), len);
>> + print_hex_dump(KERN_ERR, "raw data: ", DUMP_PREFIX_OFFSET,
>> + 16, 1, skb->data, len, true);
>> + }
>> skb->ip_summed = CHECKSUM_COMPLETE;
>> skb->protocol = eth_type_trans(skb, gp->dev);
>>
>> @@ -1761,7 +1768,7 @@ static void gem_init_dma(struct gem *gp)
>> writel(0, gp->regs + TXDMA_KICK);
>>
>> val = (RXDMA_CFG_BASE | (RX_OFFSET << 10) |
>> - ((14 / 2) << 13) | RXDMA_CFG_FTHRESH_128);
>> + (ETH_HLEN << 13) | RXDMA_CFG_FTHRESH_128);
>> writel(val, gp->regs + RXDMA_CFG);
>>
>> writel(desc_dma >> 32, gp->regs + RXDMA_DBHI);
>
> With that patch I still get the wrong csum messages, but no longer the
> hw csum failure messages (tested on a PowerMac G5).
>
> [ 662.659767] sungem: sungem wrong csum : 8359/7ca6, len 86 bytes, c0000001fee9cc02
> [ 662.659775] raw data: 00000000: 00 0d 93 43 81 62 d4 3d 7e 4c 48 b7 86 dd 61 01 ...C.b.=~LH...a.
> [ 662.659778] raw data: 00000010: 1c 1e 00 20 06 40 20 01 0a 62 17 11 88 01 00 00 ... .@ ..b......
> [ 662.659780] raw data: 00000020: 00 00 00 00 0a 38 20 01 0a 62 17 11 88 01 00 00 .....8 ..b......
> [ 662.659783] raw data: 00000030: 00 00 00 00 00 07 9a 18 00 16 c1 9a 7e ea ea 44 ............~..D
> [ 662.659785] raw data: 00000040: fb 4a 80 10 05 93 44 08 00 00 01 01 08 0a 59 68 .J....D.......Yh
> [ 662.659788] raw data: 00000050: ba e2 0e bb ac ae ......
>
> Andreas.
>
Note that 8359 and 7ca6 are the same really (a missing ~ to invert csum_partial())
So the bug was that :
1) Driver programmed a wrong start offset for the csum (7 bytes instead of 14 bytes to skip Ethernet Header)
2) FCS was not stripped.
Basically CHECKSUM_COMPLETE support never worked, but this was hidden by the fact that linux stack
had to throw away this CHECKSUM_COMPLETE because the FCS had to be removed.
Thanks !
^ permalink raw reply
* Re: [PATCH] net: nixge: Add __packed attribute to DMA descriptor struct
From: David Miller @ 2018-06-19 22:37 UTC (permalink / raw)
To: f.fainelli; +Cc: mdf, keescook, netdev, linux-kernel
In-Reply-To: <832bebb8-300d-e911-2946-5edfe82dc30a@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 19 Jun 2018 10:13:55 -0700
> How could padding be inserted given than all of the structure members
> are naturally aligned (all u32 type). Compiler bug?
Agreed, this looks completely unnecessary.
__packed should only be used when absolutely necessary because using
it generates less efficient code on some architectures.
^ permalink raw reply
* Re: [PATCH 1/5] net: emaclite: Use __func__ instead of hardcoded name
From: Joe Perches @ 2018-06-19 22:37 UTC (permalink / raw)
To: Andy Shevchenko, Radhey Shyam Pandey
Cc: David S. Miller, Andrew Lunn, Michal Simek, netdev,
linux-arm Mailing List, Linux Kernel Mailing List
In-Reply-To: <CAHp75VcKuqnUgynqXvACS7zY5=6aRxqymGE1w3Yh8sshehSm2g@mail.gmail.com>
On Wed, 2018-06-20 at 00:36 +0300, Andy Shevchenko wrote:
> On Mon, Jun 18, 2018 at 2:08 PM, Radhey Shyam Pandey
> <radhey.shyam.pandey@xilinx.com> wrote:
> > Switch hardcoded function name with a reference to __func__ making
> > the code more maintainable. Address below checkpatch warning:
> >
> > WARNING: Prefer using '"%s...", __func__' to using 'xemaclite_mdio_read',
> > this function's name, in a string
> > + "xemaclite_mdio_read(phy_id=%i, reg=%x) == %x\n",
> >
> > WARNING: Prefer using '"%s...", __func__' to using 'xemaclite_mdio_write',
> > this function's name, in a string
> > + "xemaclite_mdio_write(phy_id=%i, reg=%x, val=%x)\n",
> >
>
> For dev_dbg() the __func__ should be completely dropped away.
Not really the same.
dev_dbg without CONFIG_DYNAMIC_DEBUG does not have
the ability to prefix __func__.
^ permalink raw reply
* Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
From: Andreas Schwab @ 2018-06-19 22:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mathieu Malaterre, David S. Miller, Eric Dumazet, LKML,
Christophe LEROY, Meelis Roos, netdev, linuxppc-dev
In-Reply-To: <05645b90-d3bc-466d-116f-548f3ee39de9@gmail.com>
On Jun 19 2018, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> diff --git a/drivers/net/ethernet/sun/sungem.c b/drivers/net/ethernet/sun/sungem.c
> index 7a16d40a72d13cf1d522e8a3a396c826fe76f9b9..672d6748ab44f0890e92d5ca55d6ff6834c20dc9 100644
> --- a/drivers/net/ethernet/sun/sungem.c
> +++ b/drivers/net/ethernet/sun/sungem.c
> @@ -60,8 +60,7 @@
> #include <linux/sungem_phy.h>
> #include "sungem.h"
>
> -/* Stripping FCS is causing problems, disabled for now */
> -#undef STRIP_FCS
> +#define STRIP_FCS
>
> #define DEFAULT_MSG (NETIF_MSG_DRV | \
> NETIF_MSG_PROBE | \
> @@ -435,7 +434,7 @@ static int gem_rxmac_reset(struct gem *gp)
> writel(desc_dma & 0xffffffff, gp->regs + RXDMA_DBLOW);
> writel(RX_RING_SIZE - 4, gp->regs + RXDMA_KICK);
> val = (RXDMA_CFG_BASE | (RX_OFFSET << 10) |
> - ((14 / 2) << 13) | RXDMA_CFG_FTHRESH_128);
> + (ETH_HLEN << 13) | RXDMA_CFG_FTHRESH_128);
> writel(val, gp->regs + RXDMA_CFG);
> if (readl(gp->regs + GREG_BIFCFG) & GREG_BIFCFG_M66EN)
> writel(((5 & RXDMA_BLANK_IPKTS) |
> @@ -857,6 +856,14 @@ static int gem_rx(struct gem *gp, int work_to_do)
>
> csum = (__force __sum16)htons((status & RXDCTRL_TCPCSUM) ^ 0xffff);
> skb->csum = csum_unfold(csum);
> + {
> + __wsum rsum = csum_partial(skb->data + ETH_HLEN, len - ETH_HLEN, 0);
> + if (csum != csum_fold(rsum) && net_ratelimit())
> + pr_err("sungem wrong csum : %x/%x, len %u bytes\n",
> + csum, csum_fold(rsum), len);
> + print_hex_dump(KERN_ERR, "raw data: ", DUMP_PREFIX_OFFSET,
> + 16, 1, skb->data, len, true);
> + }
> skb->ip_summed = CHECKSUM_COMPLETE;
> skb->protocol = eth_type_trans(skb, gp->dev);
>
> @@ -1761,7 +1768,7 @@ static void gem_init_dma(struct gem *gp)
> writel(0, gp->regs + TXDMA_KICK);
>
> val = (RXDMA_CFG_BASE | (RX_OFFSET << 10) |
> - ((14 / 2) << 13) | RXDMA_CFG_FTHRESH_128);
> + (ETH_HLEN << 13) | RXDMA_CFG_FTHRESH_128);
> writel(val, gp->regs + RXDMA_CFG);
>
> writel(desc_dma >> 32, gp->regs + RXDMA_DBHI);
With that patch I still get the wrong csum messages, but no longer the
hw csum failure messages (tested on a PowerMac G5).
[ 662.659767] sungem: sungem wrong csum : 8359/7ca6, len 86 bytes, c0000001fee9cc02
[ 662.659775] raw data: 00000000: 00 0d 93 43 81 62 d4 3d 7e 4c 48 b7 86 dd 61 01 ...C.b.=~LH...a.
[ 662.659778] raw data: 00000010: 1c 1e 00 20 06 40 20 01 0a 62 17 11 88 01 00 00 ... .@ ..b......
[ 662.659780] raw data: 00000020: 00 00 00 00 0a 38 20 01 0a 62 17 11 88 01 00 00 .....8 ..b......
[ 662.659783] raw data: 00000030: 00 00 00 00 00 07 9a 18 00 16 c1 9a 7e ea ea 44 ............~..D
[ 662.659785] raw data: 00000040: fb 4a 80 10 05 93 44 08 00 00 01 01 08 0a 59 68 .J....D.......Yh
[ 662.659788] raw data: 00000050: ba e2 0e bb ac ae ......
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2 0/4] Slience NCSI logging
From: David Miller @ 2018-06-19 22:27 UTC (permalink / raw)
To: joel; +Cc: sam, netdev, joe
In-Reply-To: <20180619053834.12257-1-joel@jms.id.au>
From: Joel Stanley <joel@jms.id.au>
Date: Tue, 19 Jun 2018 15:08:30 +0930
> v2:
> Fix indent issue and commit message based on Joe's feedback
> Add Sam's acks
>
> Here are three changes to silence unnecessary warnings in the ncsi code.
>
> The final patch adds Sam as the maintainer for NCSI.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next,RFC 00/13] New fast forwarding path
From: Daniel Borkmann @ 2018-06-19 22:22 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, pablo, netfilter-devel, netdev
In-Reply-To: <20180617092304.fviy36bvgnhexwtb@gauss3.secunet.de>
On 06/17/2018 11:23 AM, Steffen Klassert wrote:
[...]
>> Would be curious about
>> the numbers. You'd get implicit batching for the forwarding via devmap
>> as well if you're required to flush it out via different device with
>> XDP_REDIRECT; otherwise XDP_TX of course. Given we have recently
>> integrated helpers for XDP to do a FIB and neighbor lookup from the
>> kernel tables, where it's thus shared and integrated with the rest of
>> the stack and tooling, it would be awesome to get to the same point
>> with xfrm as well. Eyal recently did a start on that for xfrm for tc
>> progs; would be nice to have integration on XDP as well, potentially
>> it might also result in a bigger plus on the forwarding numbers.
>
> It might make sense to intrgrate XDP with xfrm to
> be able to compare numbers etc. But I need a working
> XDP setup and some understanding about it first, what
> could take some time.
Okay, no prob. If you have any questions feel free to shoot an email.
Thanks,
Daniel
^ 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