* Re: [PATCH] net-tcp: extend tcp_tw_reuse sysctl to enable loopback only optimization
From: Eric Dumazet @ 2018-06-04 17:18 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller, Eric Dumazet
Cc: netdev, Neal Cardwell, Yuchung Cheng, Wei Wang
In-Reply-To: <20180603174117.48539-1-zenczykowski@gmail.com>
On 06/03/2018 10:41 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> This changes the /proc/sys/net/ipv4/tcp_tw_reuse from a boolean
> to an integer.
>
> It now takes the values 0, 1 and 2, where 0 and 1 behave as before,
> while 2 enables timewait socket reuse only for sockets that we can
> prove are loopback connections:
> ie. bound to 'lo' interface or where one of source or destination
> IPs is 127.0.0.0/8, ::ffff:127.0.0.0/104 or ::1.
>
> This enables quicker reuse of ephemeral ports for loopback connections
> - where tcp_tw_reuse is 100% safe from a protocol perspective
> (this assumes no artificially induced packet loss on 'lo').
>
> This also makes estblishing many loopback connections *much* faster
> (allocating ports out of the first half of the ephemeral port range
> is significantly faster, then allocating from the second half)
>
> Without this change in a 32K ephemeral port space my sample program
> (it just establishes and closes [::1]:ephemeral -> [::1]:server_port
> connections in a tight loop) fails after 32765 connections in 24 seconds.
> With it enabled 50000 connections only take 4.7 seconds.
>
> This is particularly problematic for IPv6 where we only have one local
> address and cannot play tricks with varying source IP from 127.0.0.0/8
> pool.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Wei Wang <weiwan@google.com>
This seems fine, thanks Maciej
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net v3] ipv6: omit traffic class when calculating flow hash
From: David Miller @ 2018-06-04 17:22 UTC (permalink / raw)
To: mkubecek; +Cc: netdev, linux-kernel, nicolas.dichtel, tom, dsahern, idosch
In-Reply-To: <20180604095619.7D9C1A09F0@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Mon, 4 Jun 2018 11:36:05 +0200
> Some of the code paths calculating flow hash for IPv6 use flowlabel member
> of struct flowi6 which, despite its name, encodes both flow label and
> traffic class. If traffic class changes within a TCP connection (as e.g.
> ssh does), ECMP route can switch between path. It's also inconsistent with
> other code paths where ip6_flowlabel() (returning only flow label) is used
> to feed the key.
>
> Use only flow label everywhere, including one place where hash key is set
> using ip6_flowinfo().
>
> Fixes: 51ebd3181572 ("ipv6: add support of equal cost multipath (ECMP)")
> Fixes: f70ea018da06 ("net: Add functions to get skb->hash based on flow structures")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> ---
> v2: introduce and use an inline helper as suggested by David Ahern
> v3: keep the cast out of the helper to make future cleanup easier
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [RFC PATCH 0/6] net: ethernet: ti: cpsw: add MQPRIO and CBS Qdisc offload
From: Vinicius Costa Gomes @ 2018-06-04 17:23 UTC (permalink / raw)
To: Ivan Khoronzhuk, grygorii.strashko, davem
Cc: corbet, akpm, netdev, linux-doc, linux-kernel, linux-omap, henrik,
jesus.sanchez-palencia, Ivan Khoronzhuk
In-Reply-To: <20180518211510.13341-1-ivan.khoronzhuk@linaro.org>
Hi Ivan,
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> writes:
> This series adds MQPRIO and CBS Qdisc offload for TI cpsw driver.
> It potentially can be used in audio video bridging (AVB) and time
> sensitive networking (TSN).
>
> Patchset was tested on AM572x EVM and BBB boards. Last patch from this
> series adds detailed description of configuration with examples. For
> consistency reasons, in role of talker and listener, tools from
> patchset "TSN: Add qdisc based config interface for CBS" were used and
> can be seen here: https://www.spinics.net/lists/netdev/msg460869.html
>
> Based on net-next/master
>
I didn't test this, but it looks fine from my side.
I agree with Grygorii, that if no comments, this should be re-sent as a
patch series next.
> Ivan Khoronzhuk (6):
> net: ethernet: ti: cpsw: use cpdma channels in backward order for txq
> net: ethernet: ti: cpdma: fit rated channels in backward order
> net: ethernet: ti: cpsw: add MQPRIO Qdisc offload
> net: ethernet: ti: cpsw: add CBS Qdisc offload
> net: ethernet: ti: cpsw: restore shaper configuration while down/up
> Documentation: networking: cpsw: add MQPRIO & CBS offload examples
>
> Documentation/networking/cpsw.txt | 540 ++++++++++++++++++++++++
> drivers/net/ethernet/ti/cpsw.c | 364 +++++++++++++++-
> drivers/net/ethernet/ti/davinci_cpdma.c | 31 +-
> 3 files changed, 913 insertions(+), 22 deletions(-)
> create mode 100644 Documentation/networking/cpsw.txt
>
> --
> 2.17.0
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [PATCH] net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets
From: Eric Dumazet @ 2018-06-04 17:24 UTC (permalink / raw)
To: Maciej Żenczykowski, Maciej Żenczykowski,
David S . Miller
Cc: Eric Dumazet, netdev
In-Reply-To: <20180603174705.51802-1-zenczykowski@gmail.com>
On 06/03/2018 10:47 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH v5 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2
From: Matthias Reichl @ 2018-06-04 17:47 UTC (permalink / raw)
To: Sean Young
Cc: linux-media, linux-kernel, Alexei Starovoitov,
Mauro Carvalho Chehab, Daniel Borkmann, netdev, Devin Heitmueller,
Y Song, Quentin Monnet
In-Reply-To: <9f2c54d4956f962f44fcda739a824397ddea132c.1527419762.git.sean@mess.org>
Hi Sean,
I finally found the time to test your patch series and noticed
2 issues - comments are inline
On Sun, May 27, 2018 at 12:24:09PM +0100, Sean Young wrote:
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index eb2c3b6eca7f..d5b35a6ba899 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -25,6 +25,19 @@ config LIRC
> passes raw IR to and from userspace, which is needed for
> IR transmitting (aka "blasting") and for the lirc daemon.
>
> +config BPF_LIRC_MODE2
> + bool "Support for eBPF programs attached to lirc devices"
> + depends on BPF_SYSCALL
> + depends on RC_CORE=y
Requiring rc-core to be built into the kernel could become
problematic in the future for people using media_build.
Currently the whole media tree (including rc-core) can be built
as modules so DVB and IR drivers can be replaced by newer versions.
But with rc-core in the kernel things could easily break if internal
data structures are changed.
Maybe we should add a small layer with a stable API/ABI between
bpf-lirc and rc-core to decouple them? Or would it be possible
to build rc-core with bpf support as a module?
> + depends on LIRC
> + help
> + Allow attaching eBPF programs to a lirc device using the bpf(2)
> + syscall command BPF_PROG_ATTACH. This is supported for raw IR
> + receivers.
> +
> + These eBPF programs can be used to decode IR into scancodes, for
> + IR protocols not supported by the kernel decoders.
> +
> menuconfig RC_DECODERS
> bool "Remote controller decoders"
> depends on RC_CORE
> [...]
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 388d4feda348..3c104113d040 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -11,6 +11,7 @@
> */
> #include <linux/bpf.h>
> #include <linux/bpf_trace.h>
> +#include <linux/bpf_lirc.h>
> #include <linux/btf.h>
> #include <linux/syscalls.h>
> #include <linux/slab.h>
> @@ -1578,6 +1579,8 @@ static int bpf_prog_attach(const union bpf_attr *attr)
> case BPF_SK_SKB_STREAM_PARSER:
> case BPF_SK_SKB_STREAM_VERDICT:
> return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, true);
> + case BPF_LIRC_MODE2:
> + return lirc_prog_attach(attr);
> default:
> return -EINVAL;
> }
> @@ -1648,6 +1651,8 @@ static int bpf_prog_detach(const union bpf_attr *attr)
> case BPF_SK_SKB_STREAM_PARSER:
> case BPF_SK_SKB_STREAM_VERDICT:
> return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, false);
> + case BPF_LIRC_MODE2:
> + return lirc_prog_detach(attr);
> default:
> return -EINVAL;
> }
> @@ -1695,6 +1700,8 @@ static int bpf_prog_query(const union bpf_attr *attr,
> case BPF_CGROUP_SOCK_OPS:
> case BPF_CGROUP_DEVICE:
> break;
> + case BPF_LIRC_MODE2:
> + return lirc_prog_query(attr, uattr);
When testing this patch series I was wondering why I always got
-EINVAL when trying to query the registered programs.
Closer inspection revealed that bpf_prog_attach/detach/query and
calls to them in the bpf syscall are in "#ifdef CONFIG_CGROUP_BPF"
blocks - and as I built the kernel without CONFIG_CGROUP_BPF
BPF_PROG_ATTACH/DETACH/QUERY weren't handled in the syscall switch
and I got -EINVAL from the bpf syscall function.
I haven't checked in detail yet, but it looks to me like
bpf_prog_attach/detach/query could always be built (or when
either cgroup bpf or lirc bpf are enabled) and the #ifdefs moved
inside the switch(). So lirc bpf could be used without cgroup bpf.
Or am I missing something?
so long,
Hias
> default:
> return -EINVAL;
> }
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH net-next V2 1/2] cls_flower: Fix missing free of rhashtable
From: Simon Horman @ 2018-06-04 17:51 UTC (permalink / raw)
To: Paul Blakey
Cc: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev,
Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz
In-Reply-To: <1528009574-63306-1-git-send-email-paulb@mellanox.com>
On Sun, Jun 03, 2018 at 10:06:13AM +0300, Paul Blakey wrote:
> When destroying the instance, destroy the head rhashtable.
>
> Fixes: 05cd271fd61a ("cls_flower: Support multiple masks per priority")
> Reported-by: Vlad Buslov <vladbu@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* Re: [PATCH net-next V2 2/2] cls_flower: Fix comparing of old filter mask with new filter
From: Simon Horman @ 2018-06-04 17:52 UTC (permalink / raw)
To: Paul Blakey
Cc: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David Miller, netdev,
Yevgeny Kliteynik, Roi Dayan, Shahar Klein, Mark Bloch,
Or Gerlitz
In-Reply-To: <1528009574-63306-2-git-send-email-paulb@mellanox.com>
On Sun, Jun 03, 2018 at 10:06:14AM +0300, Paul Blakey wrote:
> We incorrectly compare the mask and the result is that we can't modify
> an already existing rule.
>
> Fix that by comparing correctly.
>
> Fixes: 05cd271fd61a ("cls_flower: Support multiple masks per priority")
> Reported-by: Vlad Buslov <vladbu@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
^ permalink raw reply
* [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-06-04
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains a smorgasbord of updates to documentation, e1000e,
igb, ixgbe, ixgbevf and i40e.
Benjamin Poirier fixes a potential kernel crash due to NULL pointer
dereference in e1000e.
Jeff updates the kernel documentation for e100 and e1000 to correct
default values and URLs which were incorrect in the documentation. Also
took the time to update these to the new reStructured text format for
kernel documentation.
Joanna Yurdal fixes a missing PTP transmit timestamp by ensuring that
TSICR gets cleared when ICR is cleared.
Sergey updates igb to reset all the transmit queues at one time so that
we only have to wait once for all the queues to be reset.
Alex fixes ixgbevf so that malicious driver detection (MDD) can co-exist
with XDP.
Emil and Tony extend the RTNL lock to ensure we get the most up-to-date
values for the bits and avoid a possible race condition when going down.
YueHaibing from Huawei introduces a helper function in ixgbe for
operation reads to simplify the code a bit more.
Daniel Borkmann adds support for XDP meta data when using build SKB
for i40e.
Shannon Nelson provides twp fixes for the IPSec code in ixgbe, first is
to make sure we do not try to offload the decryption of any incoming
packet that is destined for the management engine. The other fix is to
resolve a cast problem introduced by a sparse cleanup patch.
The following are changes since commit 8284fd4cb85577eecca024fe1e7a35b39ed0f3f5:
Merge branch 'selftests-net-various'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Alexander Duyck (1):
ixgbevf: Fix coexistence of malicious driver detection with XDP
Benjamin Poirier (1):
e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes
Daniel Borkmann (1):
bpf, i40e: add meta data support
Emil Tantilov (1):
ixgbevf: fix possible race in the reset subtask
Jeff Kirsher (2):
Documentation: e100: Update the Intel 10/100 driver doc
Documentation: e1000: Update kernel documentation
Joanna Yurdal (1):
igb: Clear TSICR interrupts together with ICR
Sergey Nemov (1):
igb: Wait 10ms just once after TX queues reset
Shannon Nelson (2):
ixgbe: check ipsec ip addr against mgmt filters
ixgbe: fix broken ipsec Rx with proper cast on spi
Tony Nguyen (1):
ixgbe: fix possible race in reset subtask
YueHaibing (1):
ixgbe: introduce a helper to simplify code
.../networking/{e100.txt => e100.rst} | 60 ++++++-------
.../networking/{e1000.txt => e1000.rst} | 59 +++---------
Documentation/networking/index.rst | 2 +
MAINTAINERS | 4 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++--
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 39 ++++++--
drivers/net/ethernet/intel/igb/igb_main.c | 15 ++--
.../net/ethernet/intel/ixgbe/ixgbe_debugfs.c | 57 +++++-------
.../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 90 ++++++++++++++++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1 +
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 42 +++++++--
12 files changed, 236 insertions(+), 154 deletions(-)
rename Documentation/networking/{e100.txt => e100.rst} (79%)
rename Documentation/networking/{e1000.txt => e1000.rst} (89%)
--
2.17.1
^ permalink raw reply
* [net-next 02/12] Documentation: e100: Update the Intel 10/100 driver doc
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
Over the years, several of the links have changed or are no longer valid
so update them. In addition, the default values were incorrect for a
couple of parameters.
Converted the text file to the reStructuredText (RST) format, since the
Linux kernel documentation now uses this format for documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
---
.../networking/{e100.txt => e100.rst} | 60 +++++++++----------
Documentation/networking/index.rst | 1 +
MAINTAINERS | 2 +-
3 files changed, 29 insertions(+), 34 deletions(-)
rename Documentation/networking/{e100.txt => e100.rst} (79%)
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.rst
similarity index 79%
rename from Documentation/networking/e100.txt
rename to Documentation/networking/e100.rst
index 54810b82c01a..d4d837027925 100644
--- a/Documentation/networking/e100.txt
+++ b/Documentation/networking/e100.rst
@@ -1,7 +1,7 @@
Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
==============================================================
-March 15, 2011
+June 1, 2018
Contents
========
@@ -36,16 +36,9 @@ Channel Bonding documentation can be found in the Linux kernel source:
Identifying Your Adapter
========================
-For more information on how to identify your adapter, go to the Adapter &
-Driver ID Guide at:
-
- http://support.intel.com/support/network/adapter/pro100/21397.htm
-
-For the latest Intel network drivers for Linux, refer to the following
-website. In the search field, enter your adapter name or type, or use the
-networking link on the left to search for your adapter:
-
- http://downloadfinder.intel.com/scripts-df/support_intel.asp
+For information on how to identify your adapter, and for the latest Intel
+network drivers, refer to the Intel Support website:
+http://www.intel.com/support
Driver Configuration Parameters
===============================
@@ -57,22 +50,26 @@ Rx Descriptors: Number of receive descriptors. A receive descriptor is a data
structure that describes a receive buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to write
data from the controller to host memory. In the 3.x.x driver the valid range
- for this parameter is 64-256. The default value is 64. This parameter can be
- changed using the command:
+ for this parameter is 64-256. The default value is 256. This parameter can be
+ changed using the command::
- ethtool -G eth? rx n, where n is the number of desired rx descriptors.
+ ethtool -G eth? rx n
+
+ Where n is the number of desired Rx descriptors.
Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a data
structure that describes a transmit buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to read
data from the host memory to the controller. In the 3.x.x driver the valid
- range for this parameter is 64-256. The default value is 64. This parameter
- can be changed using the command:
+ range for this parameter is 64-256. The default value is 128. This parameter
+ can be changed using the command::
+
+ ethtool -G eth? tx n
- ethtool -G eth? tx n, where n is the number of desired tx descriptors.
+ Where n is the number of desired Tx descriptors.
Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
- default. The ethtool utility can be used as follows to force speed/duplex.
+ default. The ethtool utility can be used as follows to force speed/duplex.::
ethtool -s eth? autoneg off speed {10|100} duplex {full|half}
@@ -81,7 +78,7 @@ Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
Event Log Message Level: The driver uses the message level flag to log events
to syslog. The message level can be set at driver load time. It can also be
- set using the command:
+ set using the command::
ethtool -s eth? msglvl n
@@ -112,9 +109,9 @@ Additional Configurations
---------------------
In order to see link messages and other Intel driver information on your
console, you must set the dmesg level up to six. This can be done by
- entering the following on the command line before loading the e100 driver:
+ entering the following on the command line before loading the e100 driver::
- dmesg -n 8
+ dmesg -n 6
If you wish to see all messages issued by the driver, including debug
messages, set the dmesg level to eight.
@@ -146,7 +143,8 @@ Additional Configurations
NAPI (Rx polling mode) is supported in the e100 driver.
- See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
+ See https://wiki.linuxfoundation.org/networking/napi for more information
+ on NAPI.
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
@@ -160,7 +158,7 @@ Additional Configurations
If you have multiple interfaces in a server, either turn on ARP
filtering by
- (1) entering: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
+ (1) entering:: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5), or
(2) installing the interfaces in separate broadcast domains (either
@@ -169,15 +167,11 @@ Additional Configurations
Support
=======
-
For general information, go to the Intel support website at:
+http://www.intel.com/support/
- http://support.intel.com
-
- or the Intel Wired Networking project hosted by Sourceforge at:
-
- http://sourceforge.net/projects/e1000
-
-If an issue is identified with the released source code on the supported
-kernel with a supported adapter, email the specific information related to the
-issue to e1000-devel@lists.sourceforge.net.
+or the Intel Wired Networking project hosted by Sourceforge at:
+http://sourceforge.net/projects/e1000
+If an issue is identified with the released source code on a supported kernel
+with a supported adapter, email the specific information related to the issue
+to e1000-devel@lists.sf.net.
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index cbd9bdd4a79e..d11a62977edd 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -10,6 +10,7 @@ Contents:
batman-adv
can
dpaa2/index
+ e100
kapi
z8530book
msg_zerocopy
diff --git a/MAINTAINERS b/MAINTAINERS
index 0ae0dbf0e15e..d68981ca9896 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7089,7 +7089,7 @@ Q: http://patchwork.ozlabs.org/project/intel-wired-lan/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
S: Supported
-F: Documentation/networking/e100.txt
+F: Documentation/networking/e100.rst
F: Documentation/networking/e1000.txt
F: Documentation/networking/e1000e.txt
F: Documentation/networking/igb.txt
--
2.17.1
^ permalink raw reply related
* [net-next 01/12] e1000e: Ignore TSYNCRXCTL when getting I219 clock attributes
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Benjamin Poirier, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Benjamin Poirier <bpoirier@suse.com>
There have been multiple reports of crashes that look like
kernel: RIP: 0010:[<ffffffff8110303f>] timecounter_read+0xf/0x50
[...]
kernel: Call Trace:
kernel: [<ffffffffa0806b0f>] e1000e_phc_gettime+0x2f/0x60 [e1000e]
kernel: [<ffffffffa0806c5d>] e1000e_systim_overflow_work+0x1d/0x80 [e1000e]
kernel: [<ffffffff810992c5>] process_one_work+0x155/0x440
kernel: [<ffffffff81099e16>] worker_thread+0x116/0x4b0
kernel: [<ffffffff8109f422>] kthread+0xd2/0xf0
kernel: [<ffffffff8163184f>] ret_from_fork+0x3f/0x70
These can be traced back to the fact that e1000e_systim_reset() skips the
timecounter_init() call if e1000e_get_base_timinca() returns -EINVAL, which
leads to a null deref in timecounter_read().
Commit 83129b37ef35 ("e1000e: fix systim issues", v4.2-rc1) reworked
e1000e_get_base_timinca() in such a way that it can return -EINVAL for
e1000_pch_spt if the SYSCFI bit is not set in TSYNCRXCTL.
Some experimentation has shown that on I219 (e1000_pch_spt, "MAC: 12")
adapters, the E1000_TSYNCRXCTL_SYSCFI flag is unstable; TSYNCRXCTL reads
sometimes don't have the SYSCFI bit set. Retrying the read shortly after
finds the bit to be set. This was observed at boot (probe) but also link up
and link down.
Moreover, the phc (PTP Hardware Clock) seems to operate normally even after
reads where SYSCFI=0. Therefore, remove this register read and
unconditionally set the clock parameters.
Reported-by: Achim Mildenberger <admin@fph.physik.uni-karlsruhe.de>
Message-Id: <20180425065243.g5mqewg5irkwgwgv@f2>
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1075876
Fixes: 83129b37ef35 ("e1000e: fix systim issues")
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index d3fef7fefea8..acf1e8b52b8e 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3527,15 +3527,12 @@ s32 e1000e_get_base_timinca(struct e1000_adapter *adapter, u32 *timinca)
}
break;
case e1000_pch_spt:
- if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
- /* Stable 24MHz frequency */
- incperiod = INCPERIOD_24MHZ;
- incvalue = INCVALUE_24MHZ;
- shift = INCVALUE_SHIFT_24MHZ;
- adapter->cc.shift = shift;
- break;
- }
- return -EINVAL;
+ /* Stable 24MHz frequency */
+ incperiod = INCPERIOD_24MHZ;
+ incvalue = INCVALUE_24MHZ;
+ shift = INCVALUE_SHIFT_24MHZ;
+ adapter->cc.shift = shift;
+ break;
case e1000_pch_cnp:
if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
/* Stable 24MHz frequency */
--
2.17.1
^ permalink raw reply related
* [net-next 03/12] Documentation: e1000: Update kernel documentation
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
Updated the e1000.txt kernel documentation with the latest information.
Also convert the text file to reStructuredText (RST) format, since the
Linux kernel documentation now uses this format for documentation.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
---
.../networking/{e1000.txt => e1000.rst} | 59 ++++---------------
Documentation/networking/index.rst | 1 +
MAINTAINERS | 2 +-
3 files changed, 12 insertions(+), 50 deletions(-)
rename Documentation/networking/{e1000.txt => e1000.rst} (89%)
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.rst
similarity index 89%
rename from Documentation/networking/e1000.txt
rename to Documentation/networking/e1000.rst
index 1f6ed848363d..616848940e63 100644
--- a/Documentation/networking/e1000.txt
+++ b/Documentation/networking/e1000.rst
@@ -154,7 +154,7 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
are in use simultaneously, the CPU utilization may increase non-
linearly. In order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
- follows:
+ follows::
modprobe e1000 InterruptThrottleRate=3000,3000,3000
@@ -167,8 +167,8 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
RxDescriptors
-------------
-Valid Range: 80-256 for 82542 and 82543-based adapters
- 80-4096 for all other supported adapters
+Valid Range: 48-256 for 82542 and 82543-based adapters
+ 48-4096 for all other supported adapters
Default Value: 256
This value specifies the number of receive buffer descriptors allocated
@@ -230,8 +230,8 @@ speed. Duplex should also be set when Speed is set to either 10 or 100.
TxDescriptors
-------------
-Valid Range: 80-256 for 82542 and 82543-based adapters
- 80-4096 for all other supported adapters
+Valid Range: 48-256 for 82542 and 82543-based adapters
+ 48-4096 for all other supported adapters
Default Value: 256
This value is the number of transmit descriptors allocated by the driver.
@@ -242,41 +242,10 @@ NOTE: Depending on the available system resources, the request for a
higher number of transmit descriptors may be denied. In this case,
use a lower number.
-TxDescriptorStep
-----------------
-Valid Range: 1 (use every Tx Descriptor)
- 4 (use every 4th Tx Descriptor)
-
-Default Value: 1 (use every Tx Descriptor)
-
-On certain non-Intel architectures, it has been observed that intense TX
-traffic bursts of short packets may result in an improper descriptor
-writeback. If this occurs, the driver will report a "TX Timeout" and reset
-the adapter, after which the transmit flow will restart, though data may
-have stalled for as much as 10 seconds before it resumes.
-
-The improper writeback does not occur on the first descriptor in a system
-memory cache-line, which is typically 32 bytes, or 4 descriptors long.
-
-Setting TxDescriptorStep to a value of 4 will ensure that all TX descriptors
-are aligned to the start of a system memory cache line, and so this problem
-will not occur.
-
-NOTES: Setting TxDescriptorStep to 4 effectively reduces the number of
- TxDescriptors available for transmits to 1/4 of the normal allocation.
- This has a possible negative performance impact, which may be
- compensated for by allocating more descriptors using the TxDescriptors
- module parameter.
-
- There are other conditions which may result in "TX Timeout", which will
- not be resolved by the use of the TxDescriptorStep parameter. As the
- issue addressed by this parameter has never been observed on Intel
- Architecture platforms, it should not be used on Intel platforms.
-
TxIntDelay
----------
Valid Range: 0-65535 (0=off)
-Default Value: 64
+Default Value: 8
This value delays the generation of transmit interrupts in units of
1.024 microseconds. Transmit interrupt reduction can improve CPU
@@ -288,7 +257,7 @@ TxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
Valid Range: 0-65535 (0=off)
-Default Value: 64
+Default Value: 32
This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
@@ -310,7 +279,7 @@ Copybreak
---------
Valid Range: 0-xxxxxxx (0=off)
Default Value: 256
-Usage: insmod e1000.ko copybreak=128
+Usage: modprobe e1000.ko copybreak=128
Driver copies all packets below or equaling this size to a fresh RX
buffer before handing it up the stack.
@@ -328,14 +297,6 @@ Default Value: 0 (disabled)
Allows PHY to turn off in lower power states. The user can turn off
this parameter in supported chipsets.
-KumeranLockLoss
----------------
-Valid Range: 0-1
-Default Value: 1 (enabled)
-
-This workaround skips resetting the PHY at shutdown for the initial
-silicon releases of ICH8 systems.
-
Speed and Duplex Configuration
==============================
@@ -397,12 +358,12 @@ Additional Configurations
------------
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
- For example:
+ For example::
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. It can be made permanent if
- you add:
+ you add::
MTU=9000
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index d11a62977edd..fec8588a588e 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -11,6 +11,7 @@ Contents:
can
dpaa2/index
e100
+ e1000
kapi
z8530book
msg_zerocopy
diff --git a/MAINTAINERS b/MAINTAINERS
index d68981ca9896..32472fbf4d6e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7090,7 +7090,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git
S: Supported
F: Documentation/networking/e100.rst
-F: Documentation/networking/e1000.txt
+F: Documentation/networking/e1000.rst
F: Documentation/networking/e1000e.txt
F: Documentation/networking/igb.txt
F: Documentation/networking/igbvf.txt
--
2.17.1
^ permalink raw reply related
* [net-next 04/12] igb: Clear TSICR interrupts together with ICR
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Joanna Yurdal, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Joanna Yurdal <jyu@trackman.com>
Issuing "ip link set up/down" can block TSICR interrupts, what results in
missing PTP Tx timestamp and no PPS pulse generation.
Problem happens when the link is set up with the TSICR interrupts pending.
ICR is cleared before enabling interrupts, while TSICR is not. When all TSICR
interrupts are pending at this moment, time_sync interrupt will never
be generated. TSICR should be cleared as well.
In order to reproduce the issue:
1. Setup linux with IEEE 1588 grandmaster and PPS output enabled
2. Continue setting link up/down with random intervals between commands
3. Wait until PPS is not generated ( only one pulse is generated and PPS
dies), and ptp4l complains constantly about Tx timeout.
Signed-off-by: Joanna Yurdal <jyu@trackman.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 78574c06635b..20b728218d20 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2058,6 +2058,7 @@ int igb_up(struct igb_adapter *adapter)
igb_assign_vector(adapter->q_vector[0], 0);
/* Clear any pending interrupts. */
+ rd32(E1000_TSICR);
rd32(E1000_ICR);
igb_irq_enable(adapter);
@@ -3865,6 +3866,7 @@ static int __igb_open(struct net_device *netdev, bool resuming)
napi_enable(&(adapter->q_vector[i]->napi));
/* Clear any pending interrupts. */
+ rd32(E1000_TSICR);
rd32(E1000_ICR);
igb_irq_enable(adapter);
--
2.17.1
^ permalink raw reply related
* [net-next 05/12] igb: Wait 10ms just once after TX queues reset
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Sergey Nemov, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Sergey Nemov <sergey.nemov@intel.com>
Move 10ms sleep out of function resetting TX queue.
Reset all the TX queues in one turn and
wait for all of them just once.
Use usleep_range() instead of mdelay() in order not to
affect transmission on other interfaces.
Signed-off-by: Sergey Nemov <sergey.nemov@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 20b728218d20..c33821d2afb3 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -4055,11 +4055,6 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
u64 tdba = ring->dma;
int reg_idx = ring->reg_idx;
- /* disable the queue */
- wr32(E1000_TXDCTL(reg_idx), 0);
- wrfl();
- mdelay(10);
-
wr32(E1000_TDLEN(reg_idx),
ring->count * sizeof(union e1000_adv_tx_desc));
wr32(E1000_TDBAL(reg_idx),
@@ -4090,8 +4085,16 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
**/
static void igb_configure_tx(struct igb_adapter *adapter)
{
+ struct e1000_hw *hw = &adapter->hw;
int i;
+ /* disable the queues */
+ for (i = 0; i < adapter->num_tx_queues; i++)
+ wr32(E1000_TXDCTL(adapter->tx_ring[i]->reg_idx), 0);
+
+ wrfl();
+ usleep_range(10000, 20000);
+
for (i = 0; i < adapter->num_tx_queues; i++)
igb_configure_tx_ring(adapter, adapter->tx_ring[i]);
}
--
2.17.1
^ permalink raw reply related
* [net-next 09/12] bpf, i40e: add meta data support
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Daniel Borkmann, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Daniel Borkmann <daniel@iogearbox.net>
Add support for XDP meta data when using build skb variant of
the i40e driver. Implementation is analogous to the existing
ixgbe and ixgbevf support for meta data from 366a88fe2f40 ("bpf,
ixgbe: add meta data support") and be8333322eff ("ixgbevf: Add
support for meta data"). With the build skb variant we get
192 bytes of extra headroom which can be used for encaps or
meta data.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Tested-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 39 ++++++++++++++++-----
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 9b698c5acd05..105a26f447c0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2032,6 +2032,21 @@ static struct sk_buff *i40e_construct_skb(struct i40e_ring *rx_ring,
#if L1_CACHE_BYTES < 128
prefetch(xdp->data + L1_CACHE_BYTES);
#endif
+ /* Note, we get here by enabling legacy-rx via:
+ *
+ * ethtool --set-priv-flags <dev> legacy-rx on
+ *
+ * In this mode, we currently get 0 extra XDP headroom as
+ * opposed to having legacy-rx off, where we process XDP
+ * packets going to stack via i40e_build_skb(). The latter
+ * provides us currently with 192 bytes of headroom.
+ *
+ * For i40e_construct_skb() mode it means that the
+ * xdp->data_meta will always point to xdp->data, since
+ * the helper cannot expand the head. Should this ever
+ * change in future for legacy-rx mode on, then lets also
+ * add xdp->data_meta handling here.
+ */
/* allocate a skb to store the frags */
skb = __napi_alloc_skb(&rx_ring->q_vector->napi,
@@ -2083,19 +2098,25 @@ static struct sk_buff *i40e_build_skb(struct i40e_ring *rx_ring,
struct i40e_rx_buffer *rx_buffer,
struct xdp_buff *xdp)
{
- unsigned int size = xdp->data_end - xdp->data;
+ unsigned int metasize = xdp->data - xdp->data_meta;
#if (PAGE_SIZE < 8192)
unsigned int truesize = i40e_rx_pg_size(rx_ring) / 2;
#else
unsigned int truesize = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
- SKB_DATA_ALIGN(I40E_SKB_PAD + size);
+ SKB_DATA_ALIGN(I40E_SKB_PAD +
+ (xdp->data_end -
+ xdp->data_hard_start));
#endif
struct sk_buff *skb;
- /* prefetch first cache line of first page */
- prefetch(xdp->data);
+ /* Prefetch first cache line of first page. If xdp->data_meta
+ * is unused, this points exactly as xdp->data, otherwise we
+ * likely have a consumer accessing first few bytes of meta
+ * data, and then actual data.
+ */
+ prefetch(xdp->data_meta);
#if L1_CACHE_BYTES < 128
- prefetch(xdp->data + L1_CACHE_BYTES);
+ prefetch(xdp->data_meta + L1_CACHE_BYTES);
#endif
/* build an skb around the page buffer */
skb = build_skb(xdp->data_hard_start, truesize);
@@ -2103,8 +2124,10 @@ static struct sk_buff *i40e_build_skb(struct i40e_ring *rx_ring,
return NULL;
/* update pointers within the skb to store the data */
- skb_reserve(skb, I40E_SKB_PAD);
- __skb_put(skb, size);
+ skb_reserve(skb, I40E_SKB_PAD + (xdp->data - xdp->data_hard_start));
+ __skb_put(skb, xdp->data_end - xdp->data);
+ if (metasize)
+ skb_metadata_set(skb, metasize);
/* buffer is used by skb, update page_offset */
#if (PAGE_SIZE < 8192)
@@ -2341,7 +2364,7 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
if (!skb) {
xdp.data = page_address(rx_buffer->page) +
rx_buffer->page_offset;
- xdp_set_data_meta_invalid(&xdp);
+ xdp.data_meta = xdp.data;
xdp.data_hard_start = xdp.data -
i40e_rx_offset(rx_ring);
xdp.data_end = xdp.data + size;
--
2.17.1
^ permalink raw reply related
* [net-next 06/12] ixgbevf: Fix coexistence of malicious driver detection with XDP
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
In the case of the VF driver it is supposed to provide a context descriptor
that allows us to provide information about the header offsets inside of
the frame. However in the case of XDP we don't really have any of that
information since the data is minimally processed. As a result we were
seeing malicious driver detection (MDD) events being triggered when the PF
had that functionality enabled.
To address this I have added a bit of new code that will "prime" the XDP
ring by providing one context descriptor that assumes the minimal setup of
an Ethernet frame which is an L2 header length of 14. With just that we can
provide enough information to make the hardware happy so that we don't
trigger MDD events.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1 +
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 36 +++++++++++++++----
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 70c75681495f..56a1031dcc07 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -76,6 +76,7 @@ enum ixgbevf_ring_state_t {
__IXGBEVF_TX_DETECT_HANG,
__IXGBEVF_HANG_CHECK_ARMED,
__IXGBEVF_TX_XDP_RING,
+ __IXGBEVF_TX_XDP_RING_PRIMED,
};
#define ring_is_xdp(ring) \
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 083041129539..2d5a706c3c29 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -991,24 +991,45 @@ static int ixgbevf_xmit_xdp_ring(struct ixgbevf_ring *ring,
return IXGBEVF_XDP_CONSUMED;
/* record the location of the first descriptor for this packet */
- tx_buffer = &ring->tx_buffer_info[ring->next_to_use];
- tx_buffer->bytecount = len;
- tx_buffer->gso_segs = 1;
- tx_buffer->protocol = 0;
-
i = ring->next_to_use;
- tx_desc = IXGBEVF_TX_DESC(ring, i);
+ tx_buffer = &ring->tx_buffer_info[i];
dma_unmap_len_set(tx_buffer, len, len);
dma_unmap_addr_set(tx_buffer, dma, dma);
tx_buffer->data = xdp->data;
- tx_desc->read.buffer_addr = cpu_to_le64(dma);
+ tx_buffer->bytecount = len;
+ tx_buffer->gso_segs = 1;
+ tx_buffer->protocol = 0;
+
+ /* Populate minimal context descriptor that will provide for the
+ * fact that we are expected to process Ethernet frames.
+ */
+ if (!test_bit(__IXGBEVF_TX_XDP_RING_PRIMED, &ring->state)) {
+ struct ixgbe_adv_tx_context_desc *context_desc;
+
+ set_bit(__IXGBEVF_TX_XDP_RING_PRIMED, &ring->state);
+
+ context_desc = IXGBEVF_TX_CTXTDESC(ring, 0);
+ context_desc->vlan_macip_lens =
+ cpu_to_le32(ETH_HLEN << IXGBE_ADVTXD_MACLEN_SHIFT);
+ context_desc->seqnum_seed = 0;
+ context_desc->type_tucmd_mlhl =
+ cpu_to_le32(IXGBE_TXD_CMD_DEXT |
+ IXGBE_ADVTXD_DTYP_CTXT);
+ context_desc->mss_l4len_idx = 0;
+
+ i = 1;
+ }
/* put descriptor type bits */
cmd_type = IXGBE_ADVTXD_DTYP_DATA |
IXGBE_ADVTXD_DCMD_DEXT |
IXGBE_ADVTXD_DCMD_IFCS;
cmd_type |= len | IXGBE_TXD_CMD;
+
+ tx_desc = IXGBEVF_TX_DESC(ring, i);
+ tx_desc->read.buffer_addr = cpu_to_le64(dma);
+
tx_desc->read.cmd_type_len = cpu_to_le32(cmd_type);
tx_desc->read.olinfo_status =
cpu_to_le32((len << IXGBE_ADVTXD_PAYLEN_SHIFT) |
@@ -1688,6 +1709,7 @@ static void ixgbevf_configure_tx_ring(struct ixgbevf_adapter *adapter,
sizeof(struct ixgbevf_tx_buffer) * ring->count);
clear_bit(__IXGBEVF_HANG_CHECK_ARMED, &ring->state);
+ clear_bit(__IXGBEVF_TX_XDP_RING_PRIMED, &ring->state);
IXGBE_WRITE_REG(hw, IXGBE_VFTXDCTL(reg_idx), txdctl);
--
2.17.1
^ permalink raw reply related
* [net-next 07/12] ixgbevf: fix possible race in the reset subtask
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Extend the RTNL lock in ixgbevf_reset_subtask() to protect the state bits
check in addition to the call to ixgbevf_reinit_locked().
This is to make sure that we get the most up-to-date values for the bits
and avoid a possible race when going down.
Suggested-by: Zhiping du <zhipingdu@tencent.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 2d5a706c3c29..59416eddd840 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3141,15 +3141,17 @@ static void ixgbevf_reset_subtask(struct ixgbevf_adapter *adapter)
if (!test_and_clear_bit(__IXGBEVF_RESET_REQUESTED, &adapter->state))
return;
+ rtnl_lock();
/* If we're already down or resetting, just bail */
if (test_bit(__IXGBEVF_DOWN, &adapter->state) ||
test_bit(__IXGBEVF_REMOVING, &adapter->state) ||
- test_bit(__IXGBEVF_RESETTING, &adapter->state))
+ test_bit(__IXGBEVF_RESETTING, &adapter->state)) {
+ rtnl_unlock();
return;
+ }
adapter->tx_timeout_count++;
- rtnl_lock();
ixgbevf_reinit_locked(adapter);
rtnl_unlock();
}
--
2.17.1
^ permalink raw reply related
* [net-next 08/12] ixgbe: introduce a helper to simplify code
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: YueHaibing, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: YueHaibing <yuehaibing@huawei.com>
ixgbe_dbg_reg_ops_read and ixgbe_dbg_netdev_ops_read copy-pasting
the same code except for ixgbe_dbg_netdev_ops_buf/ixgbe_dbg_reg_ops_buf,
so introduce a helper ixgbe_dbg_common_ops_read to remove redundant code.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/ixgbe/ixgbe_debugfs.c | 57 +++++++------------
1 file changed, 21 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
index 55fe8114fe99..50dfb02fa34c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
@@ -10,15 +10,9 @@ static struct dentry *ixgbe_dbg_root;
static char ixgbe_dbg_reg_ops_buf[256] = "";
-/**
- * ixgbe_dbg_reg_ops_read - read for reg_ops datum
- * @filp: the opened file
- * @buffer: where to write the data for the user to read
- * @count: the size of the user's buffer
- * @ppos: file position offset
- **/
-static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
- size_t count, loff_t *ppos)
+static ssize_t ixgbe_dbg_common_ops_read(struct file *filp, char __user *buffer,
+ size_t count, loff_t *ppos,
+ char *dbg_buf)
{
struct ixgbe_adapter *adapter = filp->private_data;
char *buf;
@@ -29,8 +23,7 @@ static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
return 0;
buf = kasprintf(GFP_KERNEL, "%s: %s\n",
- adapter->netdev->name,
- ixgbe_dbg_reg_ops_buf);
+ adapter->netdev->name, dbg_buf);
if (!buf)
return -ENOMEM;
@@ -45,6 +38,20 @@ static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
return len;
}
+/**
+ * ixgbe_dbg_reg_ops_read - read for reg_ops datum
+ * @filp: the opened file
+ * @buffer: where to write the data for the user to read
+ * @count: the size of the user's buffer
+ * @ppos: file position offset
+ **/
+static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ return ixgbe_dbg_common_ops_read(filp, buffer, count, ppos,
+ ixgbe_dbg_reg_ops_buf);
+}
+
/**
* ixgbe_dbg_reg_ops_write - write into reg_ops datum
* @filp: the opened file
@@ -121,33 +128,11 @@ static char ixgbe_dbg_netdev_ops_buf[256] = "";
* @count: the size of the user's buffer
* @ppos: file position offset
**/
-static ssize_t ixgbe_dbg_netdev_ops_read(struct file *filp,
- char __user *buffer,
+static ssize_t ixgbe_dbg_netdev_ops_read(struct file *filp, char __user *buffer,
size_t count, loff_t *ppos)
{
- struct ixgbe_adapter *adapter = filp->private_data;
- char *buf;
- int len;
-
- /* don't allow partial reads */
- if (*ppos != 0)
- return 0;
-
- buf = kasprintf(GFP_KERNEL, "%s: %s\n",
- adapter->netdev->name,
- ixgbe_dbg_netdev_ops_buf);
- if (!buf)
- return -ENOMEM;
-
- if (count < strlen(buf)) {
- kfree(buf);
- return -ENOSPC;
- }
-
- len = simple_read_from_buffer(buffer, count, ppos, buf, strlen(buf));
-
- kfree(buf);
- return len;
+ return ixgbe_dbg_common_ops_read(filp, buffer, count, ppos,
+ ixgbe_dbg_netdev_ops_buf);
}
/**
--
2.17.1
^ permalink raw reply related
* [net-next 10/12] ixgbe: fix possible race in reset subtask
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Tony Nguyen, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Tony Nguyen <anthony.l.nguyen@intel.com>
Similar to ixgbevf, the same possibility for race exists. Extend the RTNL
lock in ixgbe_reset_subtask() to protect the state bits; this is to make
sure that we get the most up-to-date values for the bits and avoid a
possible race when going down.
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index ba3035c08572..dd8a3a037c2f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7621,17 +7621,19 @@ static void ixgbe_reset_subtask(struct ixgbe_adapter *adapter)
if (!test_and_clear_bit(__IXGBE_RESET_REQUESTED, &adapter->state))
return;
+ rtnl_lock();
/* If we're already down, removing or resetting, just bail */
if (test_bit(__IXGBE_DOWN, &adapter->state) ||
test_bit(__IXGBE_REMOVING, &adapter->state) ||
- test_bit(__IXGBE_RESETTING, &adapter->state))
+ test_bit(__IXGBE_RESETTING, &adapter->state)) {
+ rtnl_unlock();
return;
+ }
ixgbe_dump(adapter);
netdev_err(adapter->netdev, "Reset adapter\n");
adapter->tx_timeout_count++;
- rtnl_lock();
ixgbe_reinit_locked(adapter);
rtnl_unlock();
}
--
2.17.1
^ permalink raw reply related
* [net-next 11/12] ixgbe: check ipsec ip addr against mgmt filters
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Make sure we don't try to offload the decryption of an incoming
packet that should get delivered to the management engine. This
is a corner case that will likely be very seldom seen, but could
really confuse someone if they were to hit it.
Suggested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 88 +++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 99b170f1efd1..e1c976271bbd 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -444,6 +444,89 @@ static int ixgbe_ipsec_parse_proto_keys(struct xfrm_state *xs,
return 0;
}
+/**
+ * ixgbe_ipsec_check_mgmt_ip - make sure there is no clash with mgmt IP filters
+ * @xs: pointer to transformer state struct
+ **/
+static int ixgbe_ipsec_check_mgmt_ip(struct xfrm_state *xs)
+{
+ struct net_device *dev = xs->xso.dev;
+ struct ixgbe_adapter *adapter = netdev_priv(dev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ u32 mfval, manc, reg;
+ int num_filters = 4;
+ bool manc_ipv4;
+ u32 bmcipval;
+ int i, j;
+
+#define MANC_EN_IPV4_FILTER BIT(24)
+#define MFVAL_IPV4_FILTER_SHIFT 16
+#define MFVAL_IPV6_FILTER_SHIFT 24
+#define MIPAF_ARR(_m, _n) (IXGBE_MIPAF + ((_m) * 0x10) + ((_n) * 4))
+
+#define IXGBE_BMCIP(_n) (0x5050 + ((_n) * 4))
+#define IXGBE_BMCIPVAL 0x5060
+#define BMCIP_V4 0x2
+#define BMCIP_V6 0x3
+#define BMCIP_MASK 0x3
+
+ manc = IXGBE_READ_REG(hw, IXGBE_MANC);
+ manc_ipv4 = !!(manc & MANC_EN_IPV4_FILTER);
+ mfval = IXGBE_READ_REG(hw, IXGBE_MFVAL);
+ bmcipval = IXGBE_READ_REG(hw, IXGBE_BMCIPVAL);
+
+ if (xs->props.family == AF_INET) {
+ /* are there any IPv4 filters to check? */
+ if (manc_ipv4) {
+ /* the 4 ipv4 filters are all in MIPAF(3, i) */
+ for (i = 0; i < num_filters; i++) {
+ if (!(mfval & BIT(MFVAL_IPV4_FILTER_SHIFT + i)))
+ continue;
+
+ reg = IXGBE_READ_REG(hw, MIPAF_ARR(3, i));
+ if (reg == xs->id.daddr.a4)
+ return 1;
+ }
+ }
+
+ if ((bmcipval & BMCIP_MASK) == BMCIP_V4) {
+ reg = IXGBE_READ_REG(hw, IXGBE_BMCIP(3));
+ if (reg == xs->id.daddr.a4)
+ return 1;
+ }
+
+ } else {
+ /* if there are ipv4 filters, they are in the last ipv6 slot */
+ if (manc_ipv4)
+ num_filters = 3;
+
+ for (i = 0; i < num_filters; i++) {
+ if (!(mfval & BIT(MFVAL_IPV6_FILTER_SHIFT + i)))
+ continue;
+
+ for (j = 0; j < 4; j++) {
+ reg = IXGBE_READ_REG(hw, MIPAF_ARR(i, j));
+ if (reg != xs->id.daddr.a6[j])
+ break;
+ }
+ if (j == 4) /* did we match all 4 words? */
+ return 1;
+ }
+
+ if ((bmcipval & BMCIP_MASK) == BMCIP_V6) {
+ for (j = 0; j < 4; j++) {
+ reg = IXGBE_READ_REG(hw, IXGBE_BMCIP(j));
+ if (reg != xs->id.daddr.a6[j])
+ break;
+ }
+ if (j == 4) /* did we match all 4 words? */
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
/**
* ixgbe_ipsec_add_sa - program device with a security association
* @xs: pointer to transformer state struct
@@ -465,6 +548,11 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
return -EINVAL;
}
+ if (ixgbe_ipsec_check_mgmt_ip(xs)) {
+ netdev_err(dev, "IPsec IP addr clash with mgmt filters\n");
+ return -EINVAL;
+ }
+
if (xs->xso.flags & XFRM_OFFLOAD_INBOUND) {
struct rx_sa rsa;
--
2.17.1
^ permalink raw reply related
* [net-next 12/12] ixgbe: fix broken ipsec Rx with proper cast on spi
From: Jeff Kirsher @ 2018-06-04 17:56 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20180604175644.24293-1-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Fix up a cast problem introduced by a sparse cleanup patch. This fixes
a problem where the encrypted packets were not recognized on Rx and
subsequently dropped.
Fixes: 9cfbfa701b55 ("ixgbe: cleanup sparse warnings")
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index e1c976271bbd..344a1f213a5f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -663,7 +663,7 @@ static int ixgbe_ipsec_add_sa(struct xfrm_state *xs)
/* hash the new entry for faster search in Rx path */
hash_add_rcu(ipsec->rx_sa_list, &ipsec->rx_tbl[sa_idx].hlist,
- (__force u64)rsa.xs->id.spi);
+ (__force u32)rsa.xs->id.spi);
} else {
struct tx_sa tsa;
--
2.17.1
^ permalink raw reply related
* [Patch net-next] netdev-FAQ: clarify DaveM's position for stable backports
From: Cong Wang @ 2018-06-04 18:07 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, stable, Greg Kroah-Hartman
Per discussion with David at netconf 2018, let's clarify
DaveM's position of handling stable backports in netdev-FAQ.
This is important for people relying on upstream -stable
releases.
Cc: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
Documentation/networking/netdev-FAQ.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt
index 2a3278d5cf35..6dde6686c870 100644
--- a/Documentation/networking/netdev-FAQ.txt
+++ b/Documentation/networking/netdev-FAQ.txt
@@ -179,6 +179,15 @@ A: No. See above answer. In short, if you think it really belongs in
dash marker line as described in Documentation/process/submitting-patches.rst to
temporarily embed that information into the patch that you send.
+Q: Are all networking bug fixes backported to all stable releases?
+
+A: Due to capacity, Dave could only take care of the backports for the last
+ 3 stable releases. For earlier stable releases, each stable branch maintainer
+ is supposed to take care of them. If you find any patch is missing from an
+ earlier stable branch, please notify stable@vger.kernel.org with either a
+ commit ID or a formal patch backported, and CC Dave and other relevant
+ networking developers.
+
Q: Someone said that the comment style and coding convention is different
for the networking content. Is this true?
--
2.13.0
^ permalink raw reply related
* Re: [PATCH 15a/18] rhashtables: add lockdep tracking to bucket bit-spin-locks.
From: Simon Horman @ 2018-06-04 18:16 UTC (permalink / raw)
To: NeilBrown
Cc: Eric Dumazet, Herbert Xu, Thomas Graf, netdev, linux-kernel,
David S. Miller
In-Reply-To: <87po17p8jd.fsf@notabene.neil.brown.name>
On Mon, Jun 04, 2018 at 12:52:54PM +1000, NeilBrown wrote:
>
> Native bit_spin_locks are not tracked by lockdep.
>
> The bit_spin_locks used for rhashtable buckets are local
> to the rhashtable implementation, so there is little opportunity
> for the sort of misuse that lockdep might detect.
> However locks are held while a hash function or compare
> function is called, and if one of these took a lock,
> a misbehaviour is possible.
>
> As it is quite easy to add lockdep support this unlikely
> possibility see to be enough justification.
nit: s/see/seems/
>
> So create a lockdep class for bucket bit_spin_lock as attach
> through a lockdep_map in each bucket_table.
>
> With the 'nested' annotation in rhashtable_rehash_one(), lockdep
> correctly reports a possible problem as this lock it taken
> while another bucket lock (in another table) is held. This
> confirms that the added support works.
> With the correct nested annotation in place, lockdep reports
> no problems.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
^ permalink raw reply
* Re: [bug] cxgb4: vrf stopped working with cxgb4 card
From: David Ahern @ 2018-06-04 18:17 UTC (permalink / raw)
To: AMG Zollner Robert, ganeshgr; +Cc: netdev
In-Reply-To: <b515a1c7-2cf8-1af8-372d-393420d298b8@cloudmedia.eu>
On 6/4/18 8:03 AM, AMG Zollner Robert wrote:
> I have noticed that vrf is not working with kernel v4.15.0 but was
> working with v4.13.0 when using cxgb4 Chelsio driver (T520-cr)
>
> Setup:
> Two metal servers with a T520-cr card each, directly connected without a
> switch in between.
>
> SVR1 only ipfwd SVR2 with vrf
> .----------------------------. .----------------------------------.
> | | | |
> | 192.168.8.1 [ ens2f4]--|---------|--[ens1f4] 192.168.8.2 |
> | 192.168.9.1 [ens2f4d1]--|---------|--<ens1f4d1> 192.168.9.2 VRF=10 |
> `----------------------------' `----------------------------------'
>
> When vrf is not working there are no error messages (dmesg or iproute
> commands), tcpdump on the interface (SVR2.ens1f4d1) enslaved in vrf 10
> shows packets(arp req/reply) coming in and going out, but outgoing
> packets(arp reply) do not reach the other server SVR1.ens2f4d1
>
>
> Bisect:
> Found this commit to be the problem after doing a git bisect between
> v4.13..v4.15:
>
> commit ba581f77df23c8ee70b372966e69cf10bc5453d8
> Author: Ganesh Goudar <ganeshgr@chelsio.com>
> Date: Sat Sep 23 16:07:28 2017 +0530
>
> cxgb4: do DCB state reset in couple of places
>
> reset the driver's DCB state in couple of places
> where it was missing.
>
>
> A bisect step was considered good when:
> - successful ping from SVR1 to SVR2.ens1f4d1 vrf interface
> - successful ping from SVR2 global to SVR2 vrf interface trough SVR1(l3
> forwarding) (this check was redundant,both tests fail or pass simultaneous)
>
> The problem is still present on recent kernels also, checked v4.16.0 and
> v4.17.rc7
>
> Disabling DCB for the card support fixes the problem ( Compiling kernel
> with "CONFIG_CHELSIO_T4_DCB=n")
>
Are you doing the VRF enslave while it is up?
If so, does it work ok if you change the sequence:
ip li set ens1f4d1 down
ip li set ens1f4d1 master <VRF>
ip li set ens1f4d1 up
^ permalink raw reply
* Re: [PATCH] net/dns_resolver: dns_query Modify parameter checking to avoid dead code
From: Simon Horman @ 2018-06-04 18:25 UTC (permalink / raw)
To: nixiaoming
Cc: davem, dhowells, manuel.schoelling, wang840925, linux-kernel,
netdev
In-Reply-To: <20180604064031.116472-1-nixiaoming@huawei.com>
On Mon, Jun 04, 2018 at 02:40:31PM +0800, nixiaoming wrote:
> After commit 1a4240f4764a ("DNS: Separate out CIFS DNS Resolver code")
> a dead code exists in function dns_query
>
> code show as below:
> if (!name || namelen == 0)
> return -EINVAL;
> /*Now the value of "namelen" cannot be equal to 0*/
> ....
> if (!namelen) /*The condition "!namelen"" cannot be true*/
> namelen = strnlen(name, 256); /*deadcode*/
>
> Modify parameter checking to avoid dead code
>
> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
> ---
> net/dns_resolver/dns_query.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/net/dns_resolver/dns_query.c b/net/dns_resolver/dns_query.c
> index 49da670..f2acee2 100644
> --- a/net/dns_resolver/dns_query.c
> +++ b/net/dns_resolver/dns_query.c
> @@ -81,7 +81,9 @@ int dns_query(const char *type, const char *name, size_t namelen,
> kenter("%s,%*.*s,%zu,%s",
> type, (int)namelen, (int)namelen, name, namelen, options);
>
> - if (!name || namelen == 0)
> + if (!name || namelen < 3 || namelen > 255)
> + return -EINVAL;
> + if (namelen > strnlen(name, 256)) /*maybe only need part of name*/
The line above seems to change the behaviour of this function.
I think it and the previous line can be dropped.
> return -EINVAL;
>
> /* construct the query key description as "[<type>:]<name>" */
> @@ -94,10 +96,6 @@ int dns_query(const char *type, const char *name, size_t namelen,
> desclen += typelen + 1;
> }
>
> - if (!namelen)
> - namelen = strnlen(name, 256);
> - if (namelen < 3 || namelen > 255)
> - return -EINVAL;
> desclen += namelen + 1;
I think the initialisation of desclen can be changed
to include namelen + 1 without changing the behaviour of this function.
>
> desc = kmalloc(desclen, GFP_KERNEL);
> --
> 2.10.1
>
^ permalink raw reply
* Re: [PATCH bpf-next v3 05/11] bpf: avoid retpoline for lookup/update/delete calls on maps
From: Jakub Kicinski @ 2018-06-04 18:25 UTC (permalink / raw)
To: Phil Sutter
Cc: Jesper Dangaard Brouer, Daniel Borkmann, alexei.starovoitov,
netdev, Jakub Kicinski, Quentin Monnet
In-Reply-To: <20180604110225.GX11363@tatos.vnet>
On Mon, 4 Jun 2018 13:02:25 +0200, Phil Sutter wrote:
> On Sun, Jun 03, 2018 at 07:08:55PM +0200, Jesper Dangaard Brouer wrote:
> > Secondly I personally *hate* how the 'ip' does it's short options
> > parsing and especially order/precedence ambiguity. Phil Sutter
> > (Fedora/RHEL iproute2 maintainer) have a funny quiz illustrating the
> > ambiguity issues.
>
> Hehe, yes. It's a classical case of something smart evolving into a
> pain: At first there's only 'ip link', so you allow 'ip l' as a
> shortcut. Then someone implements 'ip l2tp' - so what do you do?
Good example, I like that "ip l" shows me the links because that's what
99.99% of people want when they type that command ;)
> Establish a policy of abbreviation having to be unique and break
> existing behaviour or accept the mess and head on.
Commands are tested in order of addition so older ones take precedence.
The iproute2 behaviour was replicated in bpftool on purpose, because
it should be very familiar to people. It is to me at least. And IMHO
it's better to be consistent with a well known tool than have our own
quirks and rules...
> My suggestion would be to not get into the abbreviated subcommands
> business at all but instead ship and maintain a bash-completion script.
We prefer to have both :) Those of us who like to abbreviate can do
that, and others can use completions. I personally think Quentin did
an awesome job on the completions, they cover the entire syntax unlike
the iproute2 ones and we intend to keep them that way!
^ 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