2019-05-19 13:08:20 +01:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2011-06-19 22:48:34 -07:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2014-02-18 20:53:18 +01:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2007-12-25 17:23:59 -08:00
|
|
|
|
2011-07-03 15:21:01 -04:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-29 17:24:11 +02:00
|
|
|
|
2024-04-10 12:05:01 -07:00
|
|
|
|
2023-08-04 20:05:24 +02:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-22 20:54:32 +02:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2017-03-29 08:24:21 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2017-03-29 08:24:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-30 22:14:52 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-25 10:54:44 +08:00
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
2021-11-25 10:54:44 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-22 20:54:33 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-03 18:07:32 -07:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2007-10-03 18:07:32 -07:00
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2023-04-22 20:54:33 +02:00
|
|
|
|
|
|
|
|
|
2007-10-03 18:07:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2023-05-09 11:05:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2023-04-22 20:54:33 +02:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-26 15:22:14 +02:00
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-26 15:22:14 +02:00
|
|
|
|
2018-10-11 18:36:50 +09:00
|
|
|
|
|
|
|
|
|
2023-04-22 20:54:33 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
2023-04-22 20:54:33 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-26 15:22:14 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-26 15:22:14 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2023-11-21 20:08:44 +01:00
|
|
|
|
2023-04-22 20:54:33 +02:00
|
|
|
|
|
|
|
|
|
2023-05-09 11:05:16 +02:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2021-03-30 00:43:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:50 +02:00
|
|
|
|
|
|
|
|
|
2021-03-30 00:43:12 +02:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-02 01:03:33 -07:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-03 18:07:32 -07:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2017-03-29 08:24:21 +02:00
|
|
|
|
2019-04-12 13:06:15 +02:00
|
|
|
|
2021-03-30 00:43:12 +02:00
|
|
|
|
2021-07-20 10:41:50 +02:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-18 19:00:27 -07:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-18 19:00:27 -07:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2020-08-18 19:00:27 -07:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-08 15:28:22 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2022-02-12 00:38:38 +01:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2023-09-01 12:09:21 +08:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
|
|
|
|
|
2022-04-06 16:18:54 +02:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:39 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2021-04-09 13:04:39 +02:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-29 17:24:11 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
veth: Use tstats per-CPU traffic counters
Currently veth devices use the lstats per-CPU traffic counters, which only
cover TX traffic. veth_get_stats64() actually populates RX stats of a veth
device from its peer's TX counters, based on the assumption that a veth
device can _only_ receive packets from its peer, which is no longer true:
For example, recent CNIs (like Cilium) can use the bpf_redirect_peer() BPF
helper to redirect traffic from NIC's tc ingress to veth's tc ingress (in
a different netns), skipping veth's peer device. Unfortunately, this kind
of traffic isn't currently accounted for in veth's RX stats.
In preparation for the fix, use tstats (instead of lstats) to maintain
both RX and TX counters for each veth device. We'll use RX counters for
bpf_redirect_peer() traffic, and keep using TX counters for the usual
"peer-to-peer" traffic. In veth_get_stats64(), calculate RX stats by
_adding_ RX count to peer's TX count, in order to cover both kinds of
traffic.
veth_stats_rx() might need a name change (perhaps to "veth_stats_xdp()")
for less confusion, but let's leave it to another patch to keep the fix
minimal.
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20231114004220.6495-5-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-11-14 01:42:16 +01:00
|
|
|
|
2023-08-24 20:31:31 +08:00
|
|
|
|
|
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
2023-09-01 12:09:21 +08:00
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2023-09-01 12:09:21 +08:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2020-03-19 17:41:29 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2020-03-19 17:41:27 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-26 15:22:14 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2020-03-19 17:41:29 +01:00
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:27 +01:00
|
|
|
|
2022-10-26 15:22:14 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2020-03-19 17:41:29 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:27 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-06 19:12:52 -08:00
|
|
|
|
|
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
|
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
veth: Use tstats per-CPU traffic counters
Currently veth devices use the lstats per-CPU traffic counters, which only
cover TX traffic. veth_get_stats64() actually populates RX stats of a veth
device from its peer's TX counters, based on the assumption that a veth
device can _only_ receive packets from its peer, which is no longer true:
For example, recent CNIs (like Cilium) can use the bpf_redirect_peer() BPF
helper to redirect traffic from NIC's tc ingress to veth's tc ingress (in
a different netns), skipping veth's peer device. Unfortunately, this kind
of traffic isn't currently accounted for in veth's RX stats.
In preparation for the fix, use tstats (instead of lstats) to maintain
both RX and TX counters for each veth device. We'll use RX counters for
bpf_redirect_peer() traffic, and keep using TX counters for the usual
"peer-to-peer" traffic. In veth_get_stats64(), calculate RX stats by
_adding_ RX count to peer's TX count, in order to cover both kinds of
traffic.
veth_stats_rx() might need a name change (perhaps to "veth_stats_xdp()")
for less confusion, but let's leave it to another patch to keep the fix
minimal.
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20231114004220.6495-5-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-11-14 01:42:16 +01:00
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
veth: Use tstats per-CPU traffic counters
Currently veth devices use the lstats per-CPU traffic counters, which only
cover TX traffic. veth_get_stats64() actually populates RX stats of a veth
device from its peer's TX counters, based on the assumption that a veth
device can _only_ receive packets from its peer, which is no longer true:
For example, recent CNIs (like Cilium) can use the bpf_redirect_peer() BPF
helper to redirect traffic from NIC's tc ingress to veth's tc ingress (in
a different netns), skipping veth's peer device. Unfortunately, this kind
of traffic isn't currently accounted for in veth's RX stats.
In preparation for the fix, use tstats (instead of lstats) to maintain
both RX and TX counters for each veth device. We'll use RX counters for
bpf_redirect_peer() traffic, and keep using TX counters for the usual
"peer-to-peer" traffic. In veth_get_stats64(), calculate RX stats by
_adding_ RX count to peer's TX count, in order to cover both kinds of
traffic.
veth_stats_rx() might need a name change (perhaps to "veth_stats_xdp()")
for less confusion, but let's leave it to another patch to keep the fix
minimal.
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20231114004220.6495-5-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-11-14 01:42:16 +01:00
|
|
|
|
|
|
|
|
|
2012-12-29 16:02:43 +00:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
veth: Use tstats per-CPU traffic counters
Currently veth devices use the lstats per-CPU traffic counters, which only
cover TX traffic. veth_get_stats64() actually populates RX stats of a veth
device from its peer's TX counters, based on the assumption that a veth
device can _only_ receive packets from its peer, which is no longer true:
For example, recent CNIs (like Cilium) can use the bpf_redirect_peer() BPF
helper to redirect traffic from NIC's tc ingress to veth's tc ingress (in
a different netns), skipping veth's peer device. Unfortunately, this kind
of traffic isn't currently accounted for in veth's RX stats.
In preparation for the fix, use tstats (instead of lstats) to maintain
both RX and TX counters for each veth device. We'll use RX counters for
bpf_redirect_peer() traffic, and keep using TX counters for the usual
"peer-to-peer" traffic. In veth_get_stats64(), calculate RX stats by
_adding_ RX count to peer's TX count, in order to cover both kinds of
traffic.
veth_stats_rx() might need a name change (perhaps to "veth_stats_xdp()")
for less confusion, but let's leave it to another patch to keep the fix
minimal.
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20231114004220.6495-5-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-11-14 01:42:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2013-10-04 16:52:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-11 01:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2020-03-19 17:41:29 +01:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2021-04-16 17:47:45 +02:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2021-04-16 17:47:45 +02:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:18 +01:00
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
2020-01-26 16:14:02 -08:00
|
|
|
|
2018-10-11 18:36:48 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:14 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
2021-03-08 12:06:58 +01:00
|
|
|
|
2020-03-26 23:10:20 +01:00
|
|
|
|
|
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-05-28 22:47:29 +02:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2021-01-12 19:26:13 +01:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2021-11-30 11:08:07 +01:00
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-02 10:54:22 -07:00
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-14 10:33:51 -05:00
|
|
|
|
|
|
|
|
|
2024-02-12 10:50:57 +01:00
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
2024-02-12 10:50:57 +01:00
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-07-28 18:24:04 +02:00
|
|
|
|
2018-09-14 13:33:44 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
2020-05-14 12:49:48 +02:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-11-30 11:08:07 +01:00
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-14 12:49:48 +02:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
2020-05-14 12:49:48 +02:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2020-05-14 12:49:48 +02:00
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2022-03-11 10:14:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:28 -08:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:13 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:18 +01:00
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
|
|
|
|
|
2021-12-22 19:39:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-29 23:04:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2020-03-19 17:41:27 +01:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:25 +01:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2019-06-13 18:39:59 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2022-12-20 12:59:03 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
2022-02-08 15:28:22 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-19 17:41:26 +01:00
|
|
|
|
2020-03-26 23:10:19 +01:00
|
|
|
|
2018-08-03 16:58:17 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-22 20:54:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2023-04-22 20:54:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2023-08-12 10:30:16 +08:00
|
|
|
|
2023-04-22 20:54:32 +02:00
|
|
|
|
2023-08-12 10:30:16 +08:00
|
|
|
|
2023-04-22 20:54:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2020-09-09 10:37:51 -07:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-22 20:54:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-27 06:27:53 -07:00
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
net: veth: clear GRO when clearing XDP even when down
veth sets NETIF_F_GRO automatically when XDP is enabled,
because both features use the same NAPI machinery.
The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which
is called both on ndo_stop and when XDP is turned off.
To avoid the flag from being cleared when the device is brought
down, the clearing is skipped when IFF_UP is not set.
Bringing the device down should indeed not modify its features.
Unfortunately, this means that clearing is also skipped when
XDP is disabled _while_ the device is down. And there's nothing
on the open path to bring the device features back into sync.
IOW if user enables XDP, disables it and then brings the device
up we'll end up with a stray GRO flag set but no NAPI instances.
We don't depend on the GRO flag on the datapath, so the datapath
won't crash. We will crash (or hang), however, next time features
are sync'ed (either by user via ethtool or peer changing its config).
The GRO flag will go away, and veth will try to disable the NAPIs.
But the open path never created them since XDP was off, the GRO flag
was a stray. If NAPI was initialized before we'll hang in napi_disable().
If it never was we'll crash trying to stop uninitialized hrtimer.
Move the GRO flag updates to the XDP enable / disable paths,
instead of mixing them with the ndo_open / ndo_close paths.
Fixes: d3256efd8e8b ("veth: allow enabling NAPI even without XDP")
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: syzbot+039399a9b96297ddedca@syzkaller.appspotmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-21 15:12:10 -08:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
2022-09-27 06:27:53 -07:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-14 00:08:40 +01:00
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2023-09-11 15:58:25 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-25 19:47:29 +00:00
|
|
|
|
|
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
2013-01-10 08:32:45 +00:00
|
|
|
|
2009-02-25 19:47:29 +00:00
|
|
|
|
|
|
|
|
|
2013-01-10 08:32:45 +00:00
|
|
|
|
|
|
|
|
|
2009-02-25 19:47:29 +00:00
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-25 19:47:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: use core MTU range checking in core net infra
geneve:
- Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu
- This one isn't quite as straight-forward as others, could use some
closer inspection and testing
macvlan:
- set min/max_mtu
tun:
- set min/max_mtu, remove tun_net_change_mtu
vxlan:
- Merge __vxlan_change_mtu back into vxlan_change_mtu
- Set max_mtu to IP_MAX_MTU and retain dynamic MTU range checks in
change_mtu function
- This one is also not as straight-forward and could use closer inspection
and testing from vxlan folks
bridge:
- set max_mtu of IP_MAX_MTU and retain dynamic MTU range checks in
change_mtu function
openvswitch:
- set min/max_mtu, remove internal_dev_change_mtu
- note: max_mtu wasn't checked previously, it's been set to 65535, which
is the largest possible size supported
sch_teql:
- set min/max_mtu (note: max_mtu previously unchecked, used max of 65535)
macsec:
- min_mtu = 0, max_mtu = 65535
macvlan:
- min_mtu = 0, max_mtu = 65535
ntb_netdev:
- min_mtu = 0, max_mtu = 65535
veth:
- min_mtu = 68, max_mtu = 65535
8021q:
- min_mtu = 0, max_mtu = 65535
CC: netdev@vger.kernel.org
CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Tom Herbert <tom@herbertland.com>
CC: Daniel Borkmann <daniel@iogearbox.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Jiri Benc <jbenc@redhat.com>
CC: WANG Cong <xiyou.wangcong@gmail.com>
CC: Roopa Prabhu <roopa@cumulusnetworks.com>
CC: Pravin B Shelar <pshelar@ovn.org>
CC: Sabrina Dubroca <sd@queasysnail.net>
CC: Patrick McHardy <kaber@trash.net>
CC: Stephen Hemminger <stephen@networkplumber.org>
CC: Pravin Shelar <pshelar@nicira.com>
CC: Maxim Krasnyansky <maxk@qti.qualcomm.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-20 13:55:20 -04:00
|
|
|
|
2009-03-03 23:36:04 -08:00
|
|
|
|
net: use core MTU range checking in core net infra
geneve:
- Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu
- This one isn't quite as straight-forward as others, could use some
closer inspection and testing
macvlan:
- set min/max_mtu
tun:
- set min/max_mtu, remove tun_net_change_mtu
vxlan:
- Merge __vxlan_change_mtu back into vxlan_change_mtu
- Set max_mtu to IP_MAX_MTU and retain dynamic MTU range checks in
change_mtu function
- This one is also not as straight-forward and could use closer inspection
and testing from vxlan folks
bridge:
- set max_mtu of IP_MAX_MTU and retain dynamic MTU range checks in
change_mtu function
openvswitch:
- set min/max_mtu, remove internal_dev_change_mtu
- note: max_mtu wasn't checked previously, it's been set to 65535, which
is the largest possible size supported
sch_teql:
- set min/max_mtu (note: max_mtu previously unchecked, used max of 65535)
macsec:
- min_mtu = 0, max_mtu = 65535
macvlan:
- min_mtu = 0, max_mtu = 65535
ntb_netdev:
- min_mtu = 0, max_mtu = 65535
veth:
- min_mtu = 68, max_mtu = 65535
8021q:
- min_mtu = 0, max_mtu = 65535
CC: netdev@vger.kernel.org
CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Tom Herbert <tom@herbertland.com>
CC: Daniel Borkmann <daniel@iogearbox.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Jiri Benc <jbenc@redhat.com>
CC: WANG Cong <xiyou.wangcong@gmail.com>
CC: Roopa Prabhu <roopa@cumulusnetworks.com>
CC: Pravin B Shelar <pshelar@ovn.org>
CC: Sabrina Dubroca <sd@queasysnail.net>
CC: Patrick McHardy <kaber@trash.net>
CC: Stephen Hemminger <stephen@networkplumber.org>
CC: Pravin Shelar <pshelar@nicira.com>
CC: Maxim Krasnyansky <maxk@qti.qualcomm.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-20 13:55:20 -04:00
|
|
|
|
2009-03-03 23:36:04 -08:00
|
|
|
|
|
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-23 15:59:08 -08:00
|
|
|
|
|
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
2018-10-11 18:36:49 +09:00
|
|
|
|
|
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-23 15:59:08 -08:00
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
net: add netdev_lockdep_set_classes() to virtual drivers
Based on a syzbot report, it appears many virtual
drivers do not yet use netdev_lockdep_set_classes(),
triggerring lockdep false positives.
WARNING: possible recursive locking detected
6.8.0-rc4-next-20240212-syzkaller #0 Not tainted
syz-executor.0/19016 is trying to acquire lock:
ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline]
ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
but task is already holding lock:
ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline]
ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_xmit_ETHER#2);
lock(_xmit_ETHER#2);
*** DEADLOCK ***
May be due to missing lock nesting notation
9 locks held by syz-executor.0/19016:
#0: ffffffff8f385208 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline]
#0: ffffffff8f385208 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x82c/0x1040 net/core/rtnetlink.c:6603
#1: ffffc90000a08c00 ((&in_dev->mr_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0xc0/0x600 kernel/time/timer.c:1697
#2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]
#2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]
#2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x45f/0x1360 net/ipv4/ip_output.c:228
#3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: local_bh_disable include/linux/bottom_half.h:20 [inline]
#3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: rcu_read_lock_bh include/linux/rcupdate.h:802 [inline]
#3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x2c4/0x3b10 net/core/dev.c:4284
#4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: spin_trylock include/linux/spinlock.h:361 [inline]
#4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin include/net/sch_generic.h:195 [inline]
#4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_xmit_skb net/core/dev.c:3771 [inline]
#4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x1262/0x3b10 net/core/dev.c:4325
#5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
#5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline]
#5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
#6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]
#6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]
#6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x45f/0x1360 net/ipv4/ip_output.c:228
#7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: local_bh_disable include/linux/bottom_half.h:20 [inline]
#7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: rcu_read_lock_bh include/linux/rcupdate.h:802 [inline]
#7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x2c4/0x3b10 net/core/dev.c:4284
#8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: spin_trylock include/linux/spinlock.h:361 [inline]
#8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin include/net/sch_generic.h:195 [inline]
#8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_xmit_skb net/core/dev.c:3771 [inline]
#8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x1262/0x3b10 net/core/dev.c:4325
stack backtrace:
CPU: 1 PID: 19016 Comm: syz-executor.0 Not tainted 6.8.0-rc4-next-20240212-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
check_deadlock kernel/locking/lockdep.c:3062 [inline]
validate_chain+0x15c1/0x58e0 kernel/locking/lockdep.c:3856
__lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
lock_acquire+0x1e4/0x530 kernel/locking/lockdep.c:5754
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:351 [inline]
__netif_tx_lock include/linux/netdevice.h:4452 [inline]
sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
__dev_xmit_skb net/core/dev.c:3784 [inline]
__dev_queue_xmit+0x1912/0x3b10 net/core/dev.c:4325
neigh_output include/net/neighbour.h:542 [inline]
ip_finish_output2+0xe66/0x1360 net/ipv4/ip_output.c:235
iptunnel_xmit+0x540/0x9b0 net/ipv4/ip_tunnel_core.c:82
ip_tunnel_xmit+0x20ee/0x2960 net/ipv4/ip_tunnel.c:831
erspan_xmit+0x9de/0x1460 net/ipv4/ip_gre.c:720
__netdev_start_xmit include/linux/netdevice.h:4989 [inline]
netdev_start_xmit include/linux/netdevice.h:5003 [inline]
xmit_one net/core/dev.c:3555 [inline]
dev_hard_start_xmit+0x242/0x770 net/core/dev.c:3571
sch_direct_xmit+0x2b6/0x5f0 net/sched/sch_generic.c:342
__dev_xmit_skb net/core/dev.c:3784 [inline]
__dev_queue_xmit+0x1912/0x3b10 net/core/dev.c:4325
neigh_output include/net/neighbour.h:542 [inline]
ip_finish_output2+0xe66/0x1360 net/ipv4/ip_output.c:235
igmpv3_send_cr net/ipv4/igmp.c:723 [inline]
igmp_ifc_timer_expire+0xb71/0xd90 net/ipv4/igmp.c:813
call_timer_fn+0x17e/0x600 kernel/time/timer.c:1700
expire_timers kernel/time/timer.c:1751 [inline]
__run_timers+0x621/0x830 kernel/time/timer.c:2038
run_timer_softirq+0x67/0xf0 kernel/time/timer.c:2051
__do_softirq+0x2bc/0x943 kernel/softirq.c:554
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1076 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1076
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0010:resched_offsets_ok kernel/sched/core.c:10127 [inline]
RIP: 0010:__might_resched+0x16f/0x780 kernel/sched/core.c:10142
Code: 00 4c 89 e8 48 c1 e8 03 48 ba 00 00 00 00 00 fc ff df 48 89 44 24 38 0f b6 04 10 84 c0 0f 85 87 04 00 00 41 8b 45 00 c1 e0 08 <01> d8 44 39 e0 0f 85 d6 00 00 00 44 89 64 24 1c 48 8d bc 24 a0 00
RSP: 0018:ffffc9000ee069e0 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880296a9e00
RDX: dffffc0000000000 RSI: ffff8880296a9e00 RDI: ffffffff8bfe8fa0
RBP: ffffc9000ee06b00 R08: ffffffff82326877 R09: 1ffff11002b5ad1b
R10: dffffc0000000000 R11: ffffed1002b5ad1c R12: 0000000000000000
R13: ffff8880296aa23c R14: 000000000000062a R15: 1ffff92001dc0d44
down_write+0x19/0x50 kernel/locking/rwsem.c:1578
kernfs_activate fs/kernfs/dir.c:1403 [inline]
kernfs_add_one+0x4af/0x8b0 fs/kernfs/dir.c:819
__kernfs_create_file+0x22e/0x2e0 fs/kernfs/file.c:1056
sysfs_add_file_mode_ns+0x24a/0x310 fs/sysfs/file.c:307
create_files fs/sysfs/group.c:64 [inline]
internal_create_group+0x4f4/0xf20 fs/sysfs/group.c:152
internal_create_groups fs/sysfs/group.c:192 [inline]
sysfs_create_groups+0x56/0x120 fs/sysfs/group.c:218
create_dir lib/kobject.c:78 [inline]
kobject_add_internal+0x472/0x8d0 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_init_and_add+0x124/0x190 lib/kobject.c:457
netdev_queue_add_kobject net/core/net-sysfs.c:1706 [inline]
netdev_queue_update_kobjects+0x1f3/0x480 net/core/net-sysfs.c:1758
register_queue_kobjects net/core/net-sysfs.c:1819 [inline]
netdev_register_kobject+0x265/0x310 net/core/net-sysfs.c:2059
register_netdevice+0x1191/0x19c0 net/core/dev.c:10298
bond_newlink+0x3b/0x90 drivers/net/bonding/bond_netlink.c:576
rtnl_newlink_create net/core/rtnetlink.c:3506 [inline]
__rtnl_newlink net/core/rtnetlink.c:3726 [inline]
rtnl_newlink+0x158f/0x20a0 net/core/rtnetlink.c:3739
rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6606
netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
netlink_sendmsg+0xa3c/0xd70 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0x221/0x270 net/socket.c:745
__sys_sendto+0x3a4/0x4f0 net/socket.c:2191
__do_sys_sendto net/socket.c:2203 [inline]
__se_sys_sendto net/socket.c:2199 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2199
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fc3fa87fa9c
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240212140700.2795436-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-12 14:07:00 +00:00
|
|
|
|
2023-11-14 01:42:14 +01:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2009-06-25 02:45:42 -07:00
|
|
|
|
|
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
2009-06-25 02:45:42 -07:00
|
|
|
|
|
|
|
|
|
2014-06-23 15:36:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2014-06-23 15:36:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-02 17:07:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-22 10:50:08 +00:00
|
|
|
|
2015-04-02 17:07:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
|
|
|
|
|
2022-11-22 11:50:15 +08:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-26 10:45:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-11 10:14:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:18 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
2023-04-17 23:53:22 +02:00
|
|
|
|
|
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-21 14:52:31 +01:00
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-12 21:48:40 +02:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
|
|
|
|
|
2023-04-12 21:48:50 +02:00
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
2023-04-12 21:48:50 +02:00
|
|
|
|
2023-03-21 14:52:31 +01:00
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
2023-04-12 21:48:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-05 22:08:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-19 21:50:10 -08:00
|
|
|
|
2009-02-22 00:04:45 -08:00
|
|
|
|
|
|
|
|
|
2009-02-25 19:47:29 +00:00
|
|
|
|
2009-02-22 00:04:45 -08:00
|
|
|
|
2011-06-08 14:53:59 +00:00
|
|
|
|
2013-10-04 16:52:24 +08:00
|
|
|
|
2009-02-22 00:04:45 -08:00
|
|
|
|
2014-06-23 15:36:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-02 17:07:11 +02:00
|
|
|
|
2018-08-03 16:58:11 +09:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2015-07-31 15:03:25 +09:00
|
|
|
|
2016-02-26 10:45:41 +01:00
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2020-03-19 17:41:28 +01:00
|
|
|
|
2020-10-11 01:40:02 +02:00
|
|
|
|
2008-11-19 21:50:10 -08:00
|
|
|
|
|
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-05 22:08:41 +01:00
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
|
|
|
|
|
2016-04-19 14:02:26 -04:00
|
|
|
|
2016-08-25 13:21:49 +08:00
|
|
|
|
2016-04-19 14:02:26 -04:00
|
|
|
|
2013-04-19 02:04:32 +00:00
|
|
|
|
|
|
|
|
|
2012-12-29 16:26:10 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 06:05:38 +00:00
|
|
|
|
2012-10-30 16:22:01 +00:00
|
|
|
|
2015-08-18 10:30:29 +02:00
|
|
|
|
2016-02-26 10:45:41 +01:00
|
|
|
|
2024-08-05 02:40:11 -07:00
|
|
|
|
2024-08-29 14:33:37 +02:00
|
|
|
|
2011-07-26 06:05:38 +00:00
|
|
|
|
2008-11-19 21:50:10 -08:00
|
|
|
|
2023-01-19 14:15:29 -08:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2012-12-29 16:26:10 +00:00
|
|
|
|
2014-02-18 21:20:08 +09:00
|
|
|
|
2014-03-27 22:14:48 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: Fix inconsistent teardown and release of private netdev state.
Network devices can allocate reasources and private memory using
netdev_ops->ndo_init(). However, the release of these resources
can occur in one of two different places.
Either netdev_ops->ndo_uninit() or netdev->destructor().
The decision of which operation frees the resources depends upon
whether it is necessary for all netdev refs to be released before it
is safe to perform the freeing.
netdev_ops->ndo_uninit() presumably can occur right after the
NETDEV_UNREGISTER notifier completes and the unicast and multicast
address lists are flushed.
netdev->destructor(), on the other hand, does not run until the
netdev references all go away.
Further complicating the situation is that netdev->destructor()
almost universally does also a free_netdev().
This creates a problem for the logic in register_netdevice().
Because all callers of register_netdevice() manage the freeing
of the netdev, and invoke free_netdev(dev) if register_netdevice()
fails.
If netdev_ops->ndo_init() succeeds, but something else fails inside
of register_netdevice(), it does call ndo_ops->ndo_uninit(). But
it is not able to invoke netdev->destructor().
This is because netdev->destructor() will do a free_netdev() and
then the caller of register_netdevice() will do the same.
However, this means that the resources that would normally be released
by netdev->destructor() will not be.
Over the years drivers have added local hacks to deal with this, by
invoking their destructor parts by hand when register_netdevice()
fails.
Many drivers do not try to deal with this, and instead we have leaks.
Let's close this hole by formalizing the distinction between what
private things need to be freed up by netdev->destructor() and whether
the driver needs unregister_netdevice() to perform the free_netdev().
netdev->priv_destructor() performs all actions to free up the private
resources that used to be freed by netdev->destructor(), except for
free_netdev().
netdev->needs_free_netdev is a boolean that indicates whether
free_netdev() should be done at the end of unregister_netdevice().
Now, register_netdevice() can sanely release all resources after
ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
and netdev->priv_destructor().
And at the end of unregister_netdevice(), we invoke
netdev->priv_destructor() and optionally call free_netdev().
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-05-08 12:52:56 -04:00
|
|
|
|
|
|
|
|
|
veth: Use tstats per-CPU traffic counters
Currently veth devices use the lstats per-CPU traffic counters, which only
cover TX traffic. veth_get_stats64() actually populates RX stats of a veth
device from its peer's TX counters, based on the assumption that a veth
device can _only_ receive packets from its peer, which is no longer true:
For example, recent CNIs (like Cilium) can use the bpf_redirect_peer() BPF
helper to redirect traffic from NIC's tc ingress to veth's tc ingress (in
a different netns), skipping veth's peer device. Unfortunately, this kind
of traffic isn't currently accounted for in veth's RX stats.
In preparation for the fix, use tstats (instead of lstats) to maintain
both RX and TX counters for each veth device. We'll use RX counters for
bpf_redirect_peer() traffic, and keep using TX counters for the usual
"peer-to-peer" traffic. In veth_get_stats64(), calculate RX stats by
_adding_ RX count to peer's TX count, in order to cover both kinds of
traffic.
veth_stats_rx() might need a name change (perhaps to "veth_stats_xdp()")
for less confusion, but let's leave it to another patch to keep the fix
minimal.
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://lore.kernel.org/r/20231114004220.6495-5-daniel@iogearbox.net
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2023-11-14 01:42:16 +01:00
|
|
|
|
net: use core MTU range checking in core net infra
geneve:
- Merge __geneve_change_mtu back into geneve_change_mtu, set max_mtu
- This one isn't quite as straight-forward as others, could use some
closer inspection and testing
macvlan:
- set min/max_mtu
tun:
- set min/max_mtu, remove tun_net_change_mtu
vxlan:
- Merge __vxlan_change_mtu back into vxlan_change_mtu
- Set max_mtu to IP_MAX_MTU and retain dynamic MTU range checks in
change_mtu function
- This one is also not as straight-forward and could use closer inspection
and testing from vxlan folks
bridge:
- set max_mtu of IP_MAX_MTU and retain dynamic MTU range checks in
change_mtu function
openvswitch:
- set min/max_mtu, remove internal_dev_change_mtu
- note: max_mtu wasn't checked previously, it's been set to 65535, which
is the largest possible size supported
sch_teql:
- set min/max_mtu (note: max_mtu previously unchecked, used max of 65535)
macsec:
- min_mtu = 0, max_mtu = 65535
macvlan:
- min_mtu = 0, max_mtu = 65535
ntb_netdev:
- min_mtu = 0, max_mtu = 65535
veth:
- min_mtu = 68, max_mtu = 65535
8021q:
- min_mtu = 0, max_mtu = 65535
CC: netdev@vger.kernel.org
CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
CC: Tom Herbert <tom@herbertland.com>
CC: Daniel Borkmann <daniel@iogearbox.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Jiri Benc <jbenc@redhat.com>
CC: WANG Cong <xiyou.wangcong@gmail.com>
CC: Roopa Prabhu <roopa@cumulusnetworks.com>
CC: Pravin B Shelar <pshelar@ovn.org>
CC: Sabrina Dubroca <sd@queasysnail.net>
CC: Patrick McHardy <kaber@trash.net>
CC: Stephen Hemminger <stephen@networkplumber.org>
CC: Pravin Shelar <pshelar@nicira.com>
CC: Maxim Krasnyansky <maxk@qti.qualcomm.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-20 13:55:20 -04:00
|
|
|
|
2011-03-31 01:01:35 +00:00
|
|
|
|
2012-12-29 16:26:10 +00:00
|
|
|
|
2013-10-25 18:25:03 -07:00
|
|
|
|
2016-08-24 20:10:45 -07:00
|
|
|
|
2022-05-13 11:34:06 -07:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 23:56:01 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-03 23:36:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-08 00:53:51 -08:00
|
|
|
|
2017-06-25 23:55:59 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2018-08-15 17:07:29 +09:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-14 16:37:25 +02:00
|
|
|
|
rtnetlink: support specifying device flags on device creation
commit e8469ed959c373c2ff9e6f488aa5a14971aebe1f
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 23 20:41:30 2010 +0100
Support specifying the initial device flags when creating a device though
rtnl_link. Devices allocated by rtnl_create_link() are marked as INITIALIZING
in order to surpress netlink registration notifications. To complete setup,
rtnl_configure_link() must be called, which performs the device flag changes
and invokes the deferred notifiers if everything went well.
Two examples:
# add macvlan to eth0
#
$ ip link add link eth0 up allmulticast on type macvlan
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 26:f8:84:02:f9:2a brd ff:ff:ff:ff:ff:ff
[ROUTE]ff00::/8 dev macvlan0 table local metric 256 mtu 1500 advmss 1440 hoplimit 0
[ROUTE]fe80::/64 dev macvlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500
link/ether 26:f8:84:02:f9:2a
[ADDR]11: macvlan0 inet6 fe80::24f8:84ff:fe02:f92a/64 scope link
valid_lft forever preferred_lft forever
[ROUTE]local fe80::24f8:84ff:fe02:f92a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 0
[ROUTE]default via fe80::215:e9ff:fef0:10f8 dev macvlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 0
[NEIGH]fe80::215:e9ff:fef0:10f8 dev macvlan0 lladdr 00:15:e9:f0:10:f8 router STALE
[ROUTE]2001:6f8:974::/64 dev macvlan0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 0
[PREFIX]prefix 2001:6f8:974::/64 dev macvlan0 onlink autoconf valid 14400 preferred 131084
[ADDR]11: macvlan0 inet6 2001:6f8:974:0:24f8:84ff:fe02:f92a/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
# add VLAN to eth1, eth1 is down
#
$ ip link add link eth1 up type vlan id 1000
RTNETLINK answers: Network is down
<no events>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 06:34:54 +00:00
|
|
|
|
2009-11-08 00:53:51 -08:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rtnetlink: support specifying device flags on device creation
commit e8469ed959c373c2ff9e6f488aa5a14971aebe1f
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 23 20:41:30 2010 +0100
Support specifying the initial device flags when creating a device though
rtnl_link. Devices allocated by rtnl_create_link() are marked as INITIALIZING
in order to surpress netlink registration notifications. To complete setup,
rtnl_configure_link() must be called, which performs the device flag changes
and invokes the deferred notifiers if everything went well.
Two examples:
# add macvlan to eth0
#
$ ip link add link eth0 up allmulticast on type macvlan
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 26:f8:84:02:f9:2a brd ff:ff:ff:ff:ff:ff
[ROUTE]ff00::/8 dev macvlan0 table local metric 256 mtu 1500 advmss 1440 hoplimit 0
[ROUTE]fe80::/64 dev macvlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500
link/ether 26:f8:84:02:f9:2a
[ADDR]11: macvlan0 inet6 fe80::24f8:84ff:fe02:f92a/64 scope link
valid_lft forever preferred_lft forever
[ROUTE]local fe80::24f8:84ff:fe02:f92a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 0
[ROUTE]default via fe80::215:e9ff:fef0:10f8 dev macvlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 0
[NEIGH]fe80::215:e9ff:fef0:10f8 dev macvlan0 lladdr 00:15:e9:f0:10:f8 router STALE
[ROUTE]2001:6f8:974::/64 dev macvlan0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 0
[PREFIX]prefix 2001:6f8:974::/64 dev macvlan0 onlink autoconf valid 14400 preferred 131084
[ADDR]11: macvlan0 inet6 2001:6f8:974:0:24f8:84ff:fe02:f92a/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
# add VLAN to eth1, eth1 is down
#
$ ip link add link eth1 up type vlan id 1000
RTNETLINK answers: Network is down
<no events>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 06:34:54 +00:00
|
|
|
|
net: validate veth and vxcan peer ifindexes
veth and vxcan need to make sure the ifindexes of the peer
are not negative, core does not validate this.
Using iproute2 with user-space-level checking removed:
Before:
# ./ip link add index 10 type veth peer index -1
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:74:b2:03 brd ff:ff:ff:ff:ff:ff
10: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 8a:90:ff:57:6d:5d brd ff:ff:ff:ff:ff:ff
-1: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether ae:ed:18:e6:fa:7f brd ff:ff:ff:ff:ff:ff
Now:
$ ./ip link add index 10 type veth peer index -1
Error: ifindex can't be negative.
This problem surfaced in net-next because an explicit WARN()
was added, the root cause is older.
Fixes: e6f8f1a739b6 ("veth: Allow to create peer link with given ifindex")
Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)")
Reported-by: syzbot+5ba06978f34abb058571@syzkaller.appspotmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2023-08-18 18:26:02 -07:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 23:56:01 +02:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rtnetlink: support specifying device flags on device creation
commit e8469ed959c373c2ff9e6f488aa5a14971aebe1f
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 23 20:41:30 2010 +0100
Support specifying the initial device flags when creating a device though
rtnl_link. Devices allocated by rtnl_create_link() are marked as INITIALIZING
in order to surpress netlink registration notifications. To complete setup,
rtnl_configure_link() must be called, which performs the device flag changes
and invokes the deferred notifiers if everything went well.
Two examples:
# add macvlan to eth0
#
$ ip link add link eth0 up allmulticast on type macvlan
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 26:f8:84:02:f9:2a brd ff:ff:ff:ff:ff:ff
[ROUTE]ff00::/8 dev macvlan0 table local metric 256 mtu 1500 advmss 1440 hoplimit 0
[ROUTE]fe80::/64 dev macvlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500
link/ether 26:f8:84:02:f9:2a
[ADDR]11: macvlan0 inet6 fe80::24f8:84ff:fe02:f92a/64 scope link
valid_lft forever preferred_lft forever
[ROUTE]local fe80::24f8:84ff:fe02:f92a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 0
[ROUTE]default via fe80::215:e9ff:fef0:10f8 dev macvlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 0
[NEIGH]fe80::215:e9ff:fef0:10f8 dev macvlan0 lladdr 00:15:e9:f0:10:f8 router STALE
[ROUTE]2001:6f8:974::/64 dev macvlan0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 0
[PREFIX]prefix 2001:6f8:974::/64 dev macvlan0 onlink autoconf valid 14400 preferred 131084
[ADDR]11: macvlan0 inet6 2001:6f8:974:0:24f8:84ff:fe02:f92a/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
# add VLAN to eth1, eth1 is down
#
$ ip link add link eth1 up type vlan id 1000
RTNETLINK answers: Network is down
<no events>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 06:34:54 +00:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
rtnetlink: support specifying device flags on device creation
commit e8469ed959c373c2ff9e6f488aa5a14971aebe1f
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 23 20:41:30 2010 +0100
Support specifying the initial device flags when creating a device though
rtnl_link. Devices allocated by rtnl_create_link() are marked as INITIALIZING
in order to surpress netlink registration notifications. To complete setup,
rtnl_configure_link() must be called, which performs the device flag changes
and invokes the deferred notifiers if everything went well.
Two examples:
# add macvlan to eth0
#
$ ip link add link eth0 up allmulticast on type macvlan
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 26:f8:84:02:f9:2a brd ff:ff:ff:ff:ff:ff
[ROUTE]ff00::/8 dev macvlan0 table local metric 256 mtu 1500 advmss 1440 hoplimit 0
[ROUTE]fe80::/64 dev macvlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500
link/ether 26:f8:84:02:f9:2a
[ADDR]11: macvlan0 inet6 fe80::24f8:84ff:fe02:f92a/64 scope link
valid_lft forever preferred_lft forever
[ROUTE]local fe80::24f8:84ff:fe02:f92a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 0
[ROUTE]default via fe80::215:e9ff:fef0:10f8 dev macvlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 0
[NEIGH]fe80::215:e9ff:fef0:10f8 dev macvlan0 lladdr 00:15:e9:f0:10:f8 router STALE
[ROUTE]2001:6f8:974::/64 dev macvlan0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 0
[PREFIX]prefix 2001:6f8:974::/64 dev macvlan0 onlink autoconf valid 14400 preferred 131084
[ADDR]11: macvlan0 inet6 2001:6f8:974:0:24f8:84ff:fe02:f92a/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
# add VLAN to eth1, eth1 is down
#
$ ip link add link eth1 up type vlan id 1000
RTNETLINK answers: Network is down
<no events>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 06:34:54 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2017-06-21 12:12:24 +03:00
|
|
|
|
2020-11-15 18:08:06 +01:00
|
|
|
|
2014-07-14 16:37:25 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2014-07-14 16:37:25 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2009-11-08 00:53:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-14 16:37:25 +02:00
|
|
|
|
2018-11-06 12:51:14 -08:00
|
|
|
|
2009-11-08 00:53:51 -08:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2009-11-08 00:53:51 -08:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2017-06-21 12:12:24 +03:00
|
|
|
|
2012-02-15 06:45:39 +00:00
|
|
|
|
2012-08-08 21:53:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2022-05-05 19:51:31 -07:00
|
|
|
|
2017-12-07 15:40:20 -08:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2009-11-08 00:53:51 -08:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2022-10-28 04:42:21 -04:00
|
|
|
|
rtnetlink: support specifying device flags on device creation
commit e8469ed959c373c2ff9e6f488aa5a14971aebe1f
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 23 20:41:30 2010 +0100
Support specifying the initial device flags when creating a device though
rtnl_link. Devices allocated by rtnl_create_link() are marked as INITIALIZING
in order to surpress netlink registration notifications. To complete setup,
rtnl_configure_link() must be called, which performs the device flag changes
and invokes the deferred notifiers if everything went well.
Two examples:
# add macvlan to eth0
#
$ ip link add link eth0 up allmulticast on type macvlan
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 26:f8:84:02:f9:2a brd ff:ff:ff:ff:ff:ff
[ROUTE]ff00::/8 dev macvlan0 table local metric 256 mtu 1500 advmss 1440 hoplimit 0
[ROUTE]fe80::/64 dev macvlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500
link/ether 26:f8:84:02:f9:2a
[ADDR]11: macvlan0 inet6 fe80::24f8:84ff:fe02:f92a/64 scope link
valid_lft forever preferred_lft forever
[ROUTE]local fe80::24f8:84ff:fe02:f92a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 0
[ROUTE]default via fe80::215:e9ff:fef0:10f8 dev macvlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 0
[NEIGH]fe80::215:e9ff:fef0:10f8 dev macvlan0 lladdr 00:15:e9:f0:10:f8 router STALE
[ROUTE]2001:6f8:974::/64 dev macvlan0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 0
[PREFIX]prefix 2001:6f8:974::/64 dev macvlan0 onlink autoconf valid 14400 preferred 131084
[ADDR]11: macvlan0 inet6 2001:6f8:974:0:24f8:84ff:fe02:f92a/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
# add VLAN to eth1, eth1 is down
#
$ ip link add link eth1 up type vlan id 1000
RTNETLINK answers: Network is down
<no events>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 06:34:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-15 06:45:39 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2011-04-30 01:28:17 +00:00
|
|
|
|
2020-11-15 18:08:06 +01:00
|
|
|
|
2011-04-30 01:28:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2021-07-20 10:41:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
2021-07-20 10:41:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 16:58:10 +09:00
|
|
|
|
2021-04-09 13:04:38 +02:00
|
|
|
|
2023-03-09 13:25:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:51 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
rtnetlink: support specifying device flags on device creation
commit e8469ed959c373c2ff9e6f488aa5a14971aebe1f
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Feb 23 20:41:30 2010 +0100
Support specifying the initial device flags when creating a device though
rtnl_link. Devices allocated by rtnl_create_link() are marked as INITIALIZING
in order to surpress netlink registration notifications. To complete setup,
rtnl_configure_link() must be called, which performs the device flag changes
and invokes the deferred notifiers if everything went well.
Two examples:
# add macvlan to eth0
#
$ ip link add link eth0 up allmulticast on type macvlan
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 26:f8:84:02:f9:2a brd ff:ff:ff:ff:ff:ff
[ROUTE]ff00::/8 dev macvlan0 table local metric 256 mtu 1500 advmss 1440 hoplimit 0
[ROUTE]fe80::/64 dev macvlan0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
[LINK]11: macvlan0@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500
link/ether 26:f8:84:02:f9:2a
[ADDR]11: macvlan0 inet6 fe80::24f8:84ff:fe02:f92a/64 scope link
valid_lft forever preferred_lft forever
[ROUTE]local fe80::24f8:84ff:fe02:f92a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 0
[ROUTE]default via fe80::215:e9ff:fef0:10f8 dev macvlan0 proto kernel metric 1024 mtu 1500 advmss 1440 hoplimit 0
[NEIGH]fe80::215:e9ff:fef0:10f8 dev macvlan0 lladdr 00:15:e9:f0:10:f8 router STALE
[ROUTE]2001:6f8:974::/64 dev macvlan0 proto kernel metric 256 expires 0sec mtu 1500 advmss 1440 hoplimit 0
[PREFIX]prefix 2001:6f8:974::/64 dev macvlan0 onlink autoconf valid 14400 preferred 131084
[ADDR]11: macvlan0 inet6 2001:6f8:974:0:24f8:84ff:fe02:f92a/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
# add VLAN to eth1, eth1 is down
#
$ ip link add link eth1 up type vlan id 1000
RTNETLINK answers: Network is down
<no events>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 06:34:54 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-27 07:06:36 +00:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-04 15:42:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-30 01:00:27 -07:00
|
|
|
|
2013-02-08 20:10:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
2012-02-15 04:09:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
2015-01-20 15:15:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-20 10:41:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-20 15:15:46 +01:00
|
|
|
|
2021-07-20 10:41:51 +02:00
|
|
|
|
|
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-20 17:25:14 -08:00
|
|
|
|
2007-09-25 16:14:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|