2019-05-27 08:55:01 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-06 05:50:58 +00:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-16 19:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -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
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-04 23:04:54 -07:00
|
|
|
|
2017-10-30 19:38:52 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-03 14:31:03 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-04 06:15:44 +00:00
|
|
|
|
|
|
|
|
|
2011-12-28 15:06:58 -05:00
|
|
|
|
2015-03-03 17:10:44 -06:00
|
|
|
|
2019-04-16 17:31:43 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-12 20:58:15 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-01 11:13:19 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-01 11:13:19 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-01 11:13:19 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-17 13:34:11 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-02 00:13:22 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-03-03 17:10:44 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-12 20:58:15 -05:00
|
|
|
|
2019-04-16 17:31:43 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-12-01 18:05:12 +00:00
|
|
|
|
|
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-29 08:48:32 +00:00
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
2025-08-19 17:40:30 +00:00
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-12 11:47:08 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-10-12 08:58:38 -07:00
|
|
|
|
2016-06-15 21:20:24 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-15 21:20:21 +02:00
|
|
|
|
2013-01-21 06:48:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 21:28:43 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:24 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-15 21:20:21 +02:00
|
|
|
|
2021-10-12 08:58:38 -07:00
|
|
|
|
2016-06-15 21:20:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:21 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2010-09-22 20:43:57 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
2023-08-07 03:25:32 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2024-07-29 17:30:10 -07:00
|
|
|
|
2019-07-18 23:30:03 -07:00
|
|
|
|
2024-07-29 17:30:10 -07:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2012-07-11 23:26:46 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-29 17:17:48 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-09 01:59:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-07-29 17:17:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-10 13:38:41 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-03-28 22:40:53 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-22 22:05:40 +09:00
|
|
|
|
|
|
|
|
|
2010-10-04 06:15:44 +00:00
|
|
|
|
|
|
|
|
|
2011-12-28 15:06:58 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-12-28 15:06:58 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-03-03 17:10:44 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-18 18:57:34 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-09 01:40:57 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-07-17 13:34:11 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-09 01:40:57 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-02 16:01:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-16 17:31:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-03 13:37:01 +02:00
|
|
|
|
2025-02-07 13:58:34 +00:00
|
|
|
|
2013-01-21 06:48:14 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:39 +00:00
|
|
|
|
2013-01-21 06:48:44 +00:00
|
|
|
|
2013-01-21 06:48:14 +00:00
|
|
|
|
2013-09-03 13:37:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-07 13:58:34 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-03 13:37:01 +02:00
|
|
|
|
2013-01-21 06:48:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:29 +00:00
|
|
|
|
2013-01-21 06:48:19 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:24 +00:00
|
|
|
|
2013-01-21 06:48:19 +00:00
|
|
|
|
|
|
|
|
|
net: ipv6: sysctl to specify IPv6 ND traffic class
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Solicitation (ICMPv6 type 135)
ndisc_send_ns() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Advertisement (ICMPv6 type 136)
ndisc_send_na() -> ndisc_send_skb() -> ip6_nd_hdr()
- Redirect (ICMPv6 type 137)
ndisc_send_redirect() -> ndisc_send_skb() -> ip6_nd_hdr()
and if the kernel ever gets around to generating RA's,
it would presumably also include:
- Router Advertisement (ICMPv6 type 134)
(radvd daemon could pick up on the kernel setting and use it)
Interface drivers may examine the Traffic Class value and translate
the DiffServ Code Point into a link-layer appropriate traffic
prioritization scheme. An example of mapping IETF DSCP values to
IEEE 802.11 User Priority values can be found here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11
The expected primary use case is to properly prioritize ND over wifi.
Testing:
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
0
jzem22:~# echo -1 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 256 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 0 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# echo 255 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
255
jzem22:~# echo 34 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
34
jzem22:~# echo $[0xDC] > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# tcpdump -v -i eth0 icmp6 and src host jzem22.pgc and dst host fe80::1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP6 (class 0xdc, hlim 255, next-header ICMPv6 (58) payload length: 24)
jzem22.pgc > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement,
length 24, tgt is jzem22.pgc, Flags [solicited]
(based on original change written by Erik Kline, with minor changes)
v2: fix 'suspicious rcu_dereference_check() usage'
by explicitly grabbing the rcu_read_lock.
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Erik Kline <ek@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-07 21:52:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
net: ipv6: sysctl to specify IPv6 ND traffic class
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Solicitation (ICMPv6 type 135)
ndisc_send_ns() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Advertisement (ICMPv6 type 136)
ndisc_send_na() -> ndisc_send_skb() -> ip6_nd_hdr()
- Redirect (ICMPv6 type 137)
ndisc_send_redirect() -> ndisc_send_skb() -> ip6_nd_hdr()
and if the kernel ever gets around to generating RA's,
it would presumably also include:
- Router Advertisement (ICMPv6 type 134)
(radvd daemon could pick up on the kernel setting and use it)
Interface drivers may examine the Traffic Class value and translate
the DiffServ Code Point into a link-layer appropriate traffic
prioritization scheme. An example of mapping IETF DSCP values to
IEEE 802.11 User Priority values can be found here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11
The expected primary use case is to properly prioritize ND over wifi.
Testing:
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
0
jzem22:~# echo -1 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 256 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 0 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# echo 255 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
255
jzem22:~# echo 34 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
34
jzem22:~# echo $[0xDC] > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# tcpdump -v -i eth0 icmp6 and src host jzem22.pgc and dst host fe80::1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP6 (class 0xdc, hlim 255, next-header ICMPv6 (58) payload length: 24)
jzem22.pgc > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement,
length 24, tgt is jzem22.pgc, Flags [solicited]
(based on original change written by Erik Kline, with minor changes)
v2: fix 'suspicious rcu_dereference_check() usage'
by explicitly grabbing the rcu_read_lock.
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Erik Kline <ek@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-07 21:52:09 -08:00
|
|
|
|
2013-01-21 06:48:19 +00:00
|
|
|
|
2013-01-21 06:48:39 +00:00
|
|
|
|
2013-01-21 06:48:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: ipv6: sysctl to specify IPv6 ND traffic class
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Solicitation (ICMPv6 type 135)
ndisc_send_ns() -> ndisc_send_skb() -> ip6_nd_hdr()
- Neighbour Advertisement (ICMPv6 type 136)
ndisc_send_na() -> ndisc_send_skb() -> ip6_nd_hdr()
- Redirect (ICMPv6 type 137)
ndisc_send_redirect() -> ndisc_send_skb() -> ip6_nd_hdr()
and if the kernel ever gets around to generating RA's,
it would presumably also include:
- Router Advertisement (ICMPv6 type 134)
(radvd daemon could pick up on the kernel setting and use it)
Interface drivers may examine the Traffic Class value and translate
the DiffServ Code Point into a link-layer appropriate traffic
prioritization scheme. An example of mapping IETF DSCP values to
IEEE 802.11 User Priority values can be found here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11
The expected primary use case is to properly prioritize ND over wifi.
Testing:
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
0
jzem22:~# echo -1 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 256 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
-bash: echo: write error: Invalid argument
jzem22:~# echo 0 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# echo 255 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
255
jzem22:~# echo 34 > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# cat /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
34
jzem22:~# echo $[0xDC] > /proc/sys/net/ipv6/conf/eth0/ndisc_tclass
jzem22:~# tcpdump -v -i eth0 icmp6 and src host jzem22.pgc and dst host fe80::1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP6 (class 0xdc, hlim 255, next-header ICMPv6 (58) payload length: 24)
jzem22.pgc > fe80::1: [icmp6 sum ok] ICMP6, neighbor advertisement,
length 24, tgt is jzem22.pgc, Flags [solicited]
(based on original change written by Erik Kline, with minor changes)
v2: fix 'suspicious rcu_dereference_check() usage'
by explicitly grabbing the rcu_read_lock.
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Erik Kline <ek@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-07 21:52:09 -08:00
|
|
|
|
2013-01-21 06:48:19 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:24 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
|
|
|
|
|
bonding: send IPv6 neighbor advertisement on failover
This patch adds better IPv6 failover support for bonding devices,
especially when in active-backup mode and there are only IPv6 addresses
configured, as reported by Alex Sidorenko.
- Creates a new file, net/drivers/bonding/bond_ipv6.c, for the
IPv6-specific routines. Both regular bonds and VLANs over bonds
are supported.
- Adds a new tunable, num_unsol_na, to limit the number of unsolicited
IPv6 Neighbor Advertisements that are sent on a failover event.
Default is 1.
- Creates two new IPv6 neighbor discovery functions:
ndisc_build_skb()
ndisc_send_skb()
These were required to support VLANs since we have to be able to
add the VLAN id to the skb since ndisc_send_na() and friends
shouldn't be asked to do this. These two routines are basically
__ndisc_send() split into two pieces, in a slightly different order.
- Updates Documentation/networking/bonding.txt and bumps the rev of bond
support to 3.4.0.
On failover, this new code will generate one packet:
- An unsolicited IPv6 Neighbor Advertisement, which helps the switch
learn that the address has moved to the new slave.
Testing has shown that sending just the NA results in pretty good
behavior when in active-back mode, I saw no lost ping packets for example.
Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-11-04 17:51:14 -08:00
|
|
|
|
2013-01-21 06:48:58 +00:00
|
|
|
|
2025-02-07 13:58:39 +00:00
|
|
|
|
2025-06-30 12:19:32 +00:00
|
|
|
|
2025-02-07 13:58:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bonding: send IPv6 neighbor advertisement on failover
This patch adds better IPv6 failover support for bonding devices,
especially when in active-backup mode and there are only IPv6 addresses
configured, as reported by Alex Sidorenko.
- Creates a new file, net/drivers/bonding/bond_ipv6.c, for the
IPv6-specific routines. Both regular bonds and VLANs over bonds
are supported.
- Adds a new tunable, num_unsol_na, to limit the number of unsolicited
IPv6 Neighbor Advertisements that are sent on a failover event.
Default is 1.
- Creates two new IPv6 neighbor discovery functions:
ndisc_build_skb()
ndisc_send_skb()
These were required to support VLANs since we have to be able to
add the VLAN id to the skb since ndisc_send_na() and friends
shouldn't be asked to do this. These two routines are basically
__ndisc_send() split into two pieces, in a slightly different order.
- Updates Documentation/networking/bonding.txt and bumps the rev of bond
support to 3.4.0.
On failover, this new code will generate one packet:
- An unsolicited IPv6 Neighbor Advertisement, which helps the switch
learn that the address has moved to the new slave.
Testing has shown that sending just the NA results in pretty good
behavior when in active-back mode, I saw no lost ping packets for example.
Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-11-04 17:51:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-07 13:58:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:03 +00:00
|
|
|
|
|
|
|
|
|
2016-09-10 12:09:57 -07:00
|
|
|
|
bonding: send IPv6 neighbor advertisement on failover
This patch adds better IPv6 failover support for bonding devices,
especially when in active-backup mode and there are only IPv6 addresses
configured, as reported by Alex Sidorenko.
- Creates a new file, net/drivers/bonding/bond_ipv6.c, for the
IPv6-specific routines. Both regular bonds and VLANs over bonds
are supported.
- Adds a new tunable, num_unsol_na, to limit the number of unsolicited
IPv6 Neighbor Advertisements that are sent on a failover event.
Default is 1.
- Creates two new IPv6 neighbor discovery functions:
ndisc_build_skb()
ndisc_send_skb()
These were required to support VLANs since we have to be able to
add the VLAN id to the skb since ndisc_send_na() and friends
shouldn't be asked to do this. These two routines are basically
__ndisc_send() split into two pieces, in a slightly different order.
- Updates Documentation/networking/bonding.txt and bumps the rev of bond
support to 3.4.0.
On failover, this new code will generate one packet:
- An unsolicited IPv6 Neighbor Advertisement, which helps the switch
learn that the address has moved to the new slave.
Testing has shown that sending just the NA results in pretty good
behavior when in active-back mode, I saw no lost ping packets for example.
Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-11-04 17:51:14 -08:00
|
|
|
|
2015-10-12 11:47:10 -07:00
|
|
|
|
2013-01-21 06:49:03 +00:00
|
|
|
|
|
|
|
|
|
2025-02-07 13:58:39 +00:00
|
|
|
|
2013-01-21 06:49:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-24 20:44:52 +09:00
|
|
|
|
2013-01-21 06:49:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-12 16:01:59 +00:00
|
|
|
|
2013-01-21 06:49:08 +00:00
|
|
|
|
2025-08-28 19:58:17 +00:00
|
|
|
|
2025-06-30 12:19:32 +00:00
|
|
|
|
2023-10-19 09:20:53 +08:00
|
|
|
|
2007-04-24 20:44:52 +09:00
|
|
|
|
2015-09-15 20:04:16 -05:00
|
|
|
|
2025-06-30 12:19:32 +00:00
|
|
|
|
2015-10-07 16:48:35 -05:00
|
|
|
|
2007-04-24 20:44:52 +09:00
|
|
|
|
2008-10-08 10:33:50 -07:00
|
|
|
|
2008-10-08 10:33:06 -07:00
|
|
|
|
2007-04-24 20:44:52 +09:00
|
|
|
|
|
|
|
|
|
2011-07-27 21:13:03 +00:00
|
|
|
|
2007-04-24 20:44:52 +09:00
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
2007-04-24 20:44:52 +09:00
|
|
|
|
2015-09-22 18:57:13 +02:00
|
|
|
|
2013-08-31 13:44:36 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
[IPV6]: Make address arguments const.
- net/ipv6/addrconf.c:
ipv6_get_ifaddr(), ipv6_dev_get_saddr()
- net/ipv6/mcast.c:
ipv6_sock_mc_join(), ipv6_sock_mc_drop(),
inet6_mc_check(),
ipv6_dev_mc_inc(), __ipv6_dev_mc_dec(), ipv6_dev_mc_dec(),
ipv6_chk_mcast_addr()
- net/ipv6/route.c:
rt6_lookup(), icmp6_dst_alloc()
- net/ipv6/ip6_output.c:
ip6_nd_hdr()
- net/ipv6/ndisc.c:
ndisc_send_ns(), ndisc_send_rs(), ndisc_send_redirect(),
ndisc_get_neigh(), __ndisc_send()
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
2008-04-10 15:42:10 +09:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
2013-07-13 11:26:51 +03:00
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-08-14 15:33:21 -07:00
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2008-03-25 09:37:42 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2018-03-05 16:11:54 -06:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: make skb_put & friends return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions (skb_put, __skb_put and pskb_put) return void *
and remove all the casts across the tree, adding a (u8 *) cast only
where the unsigned char pointer was used directly, all done with the
following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_put, __skb_put };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_put, __skb_put };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
which actually doesn't cover pskb_put since there are only three
users overall.
A handful of stragglers were converted manually, notably a macro in
drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
instances in net/bluetooth/hci_sock.c. In the former file, I also
had to fix one whitespace problem spatch introduced.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:21 +02:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2026-03-25 13:08:46 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-04-15 13:46:02 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-25 20:16:29 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-22 18:57:13 +02:00
|
|
|
|
2011-04-15 13:46:02 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2013-07-13 11:26:51 +03:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
networking: make skb_put & friends return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions (skb_put, __skb_put and pskb_put) return void *
and remove all the casts across the tree, adding a (u8 *) cast only
where the unsigned char pointer was used directly, all done with the
following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_put, __skb_put };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_put, __skb_put };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
which actually doesn't cover pskb_put since there are only three
users overall.
A handful of stragglers were converted manually, notably a macro in
drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
instances in net/bluetooth/hci_sock.c. In the former file, I also
had to fix one whitespace problem spatch introduced.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:21 +02:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2022-02-21 13:54:53 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
[IPV6]: Make address arguments const.
- net/ipv6/addrconf.c:
ipv6_get_ifaddr(), ipv6_dev_get_saddr()
- net/ipv6/mcast.c:
ipv6_sock_mc_join(), ipv6_sock_mc_drop(),
inet6_mc_check(),
ipv6_dev_mc_inc(), __ipv6_dev_mc_dec(), ipv6_dev_mc_dec(),
ipv6_chk_mcast_addr()
- net/ipv6/route.c:
rt6_lookup(), icmp6_dst_alloc()
- net/ipv6/ip6_output.c:
ip6_nd_hdr()
- net/ipv6/ndisc.c:
ndisc_send_ns(), ndisc_send_rs(), ndisc_send_redirect(),
ndisc_get_neigh(), __ndisc_send()
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
2008-04-10 15:42:10 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-20 14:01:35 -08:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2008-01-10 22:44:09 -08:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
2007-02-28 23:13:20 +09:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
2007-02-28 23:13:20 +09:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: make skb_put & friends return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions (skb_put, __skb_put and pskb_put) return void *
and remove all the casts across the tree, adding a (u8 *) cast only
where the unsigned char pointer was used directly, all done with the
following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_put, __skb_put };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_put, __skb_put };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
which actually doesn't cover pskb_put since there are only three
users overall.
A handful of stragglers were converted manually, notably a macro in
drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
instances in net/bluetooth/hci_sock.c. In the former file, I also
had to fix one whitespace problem spatch introduced.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:21 +02:00
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:49:17 +00:00
|
|
|
|
2013-01-21 06:49:13 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-04 20:01:23 +09:00
|
|
|
|
2018-03-13 08:29:37 -07:00
|
|
|
|
2015-02-04 20:01:23 +09:00
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2014-11-23 21:28:43 +00:00
|
|
|
|
|
|
|
|
|
2023-03-13 20:17:31 +00:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
|
|
|
|
|
2008-03-24 14:48:59 -07:00
|
|
|
|
|
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
2008-03-24 14:48:59 -07:00
|
|
|
|
2025-07-16 22:08:17 +00:00
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
2025-07-16 22:08:17 +00:00
|
|
|
|
2008-03-24 14:48:59 -07:00
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
2008-03-24 14:48:59 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-19 22:01:28 -07:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-05-28 20:34:26 +00:00
|
|
|
|
2007-04-19 20:29:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
|
|
|
|
|
2013-01-18 02:05:03 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 07:39:00 +00:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:40 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ipv6: make DAD fail with enhanced DAD when nonce length differs
Commit adc176c54722 ("ipv6 addrconf: Implemented enhanced DAD (RFC7527)")
added enhanced DAD with a nonce length of 6 bytes. However, RFC7527
doesn't specify the length of the nonce, other than being 6 + 8*k bytes,
with integer k >= 0 (RFC3971 5.3.2). The current implementation simply
assumes that the nonce will always be 6 bytes, but others systems are
free to choose different sizes.
If another system sends a nonce of different length but with the same 6
bytes prefix, it shouldn't be considered as the same nonce. Thus, check
that the length of the received nonce is the same as the length we sent.
Ugly scapy test script running on veth0:
def loop():
pkt=sniff(iface="veth0", filter="icmp6", count=1)
pkt = pkt[0]
b = bytearray(pkt[Raw].load)
b[1] += 1
b += b'\xde\xad\xbe\xef\xde\xad\xbe\xef'
pkt[Raw].load = bytes(b)
pkt[IPv6].plen += 8
# fixup checksum after modifying the payload
pkt[IPv6].payload.cksum -= 0x3b44
if pkt[IPv6].payload.cksum < 0:
pkt[IPv6].payload.cksum += 0xffff
sendp(pkt, iface="veth0")
This should result in DAD failure for any address added to veth0's peer,
but is currently ignored.
Fixes: adc176c54722 ("ipv6 addrconf: Implemented enhanced DAD (RFC7527)")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-13 17:21:42 +02:00
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2008-03-07 11:14:49 -08:00
|
|
|
|
2015-10-12 11:47:10 -07:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2016-12-02 14:00:08 -08:00
|
|
|
|
|
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-30 19:38:52 -04:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-19 22:35:03 -07:00
|
|
|
|
|
|
|
|
|
2015-10-12 11:47:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-07-19 22:35:03 -07:00
|
|
|
|
2024-02-28 13:54:30 +00:00
|
|
|
|
2024-02-28 13:54:34 +00:00
|
|
|
|
|
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
2005-08-14 17:24:31 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-07-13 11:26:51 +03:00
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:41 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:41 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-03-28 13:37:58 +09:00
|
|
|
|
2024-02-28 13:54:30 +00:00
|
|
|
|
2006-09-22 14:43:19 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-09-22 18:57:13 +02:00
|
|
|
|
2013-01-20 07:39:18 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2007-10-09 01:40:57 -07:00
|
|
|
|
2015-09-22 18:57:13 +02:00
|
|
|
|
2013-01-20 07:39:18 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-07-13 16:40:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
2022-07-13 16:40:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2014-05-15 15:56:14 +08:00
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-05-28 20:34:26 +00:00
|
|
|
|
2007-04-19 20:29:13 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-02-04 13:31:20 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2016-02-04 13:31:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
2016-02-04 13:31:20 +01:00
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2016-02-04 13:31:20 +01:00
|
|
|
|
2023-02-16 16:28:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2008-03-07 11:14:49 -08:00
|
|
|
|
2011-04-13 21:09:25 +00:00
|
|
|
|
|
|
|
|
|
2017-10-30 19:38:52 -04:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-09 15:48:32 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-12-09 15:48:32 -08:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-15 08:34:02 +00:00
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-15 08:34:02 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
2024-02-28 13:54:30 +00:00
|
|
|
|
2022-07-13 16:40:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-19 22:35:03 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-03-13 20:17:31 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-09-22 14:42:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:30 +00:00
|
|
|
|
2024-02-28 13:54:34 +00:00
|
|
|
|
2025-07-16 22:08:10 +00:00
|
|
|
|
2012-11-07 05:05:38 +00:00
|
|
|
|
2006-09-22 14:42:46 -07:00
|
|
|
|
2006-09-22 14:43:49 -07:00
|
|
|
|
2006-09-22 14:42:46 -07:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2022-05-30 10:14:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-15 15:56:14 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-07-27 21:13:03 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:30 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:40 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-12 17:58:35 -08:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-25 00:49:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-29 16:59:25 +02:00
|
|
|
|
2012-04-01 20:27:33 -04:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
2009-02-24 23:18:28 -08:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-07 11:14:49 -08:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
|
|
|
|
|
2024-02-08 14:06:51 -08:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2006-03-20 17:04:53 -08:00
|
|
|
|
2015-08-31 15:59:22 +02:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-05-28 20:34:26 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2011-07-27 21:13:03 +00:00
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:40 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2009-08-29 00:04:09 -07:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2009-08-29 00:04:09 -07:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-31 15:59:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-31 15:59:22 +02:00
|
|
|
|
2015-09-01 01:57:30 +02:00
|
|
|
|
2015-08-31 15:59:22 +02:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2006-03-20 16:55:08 -08:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2006-03-20 16:55:08 -08:00
|
|
|
|
2023-07-26 16:07:01 -07:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2023-07-26 16:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-25 14:44:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:11 -07:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2018-04-17 17:33:11 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2011-10-24 19:13:15 -04:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2011-10-24 19:13:15 -04:00
|
|
|
|
2006-03-20 17:04:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 17:05:30 -08:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2006-03-20 17:04:53 -08:00
|
|
|
|
|
|
|
|
|
2019-06-03 20:19:52 -07:00
|
|
|
|
2018-04-17 17:33:11 -07:00
|
|
|
|
2012-01-27 15:07:56 -08:00
|
|
|
|
2019-05-22 20:27:59 -07:00
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:21 -07:00
|
|
|
|
2012-01-27 15:07:56 -08:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:25 -07:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2012-01-27 15:07:56 -08:00
|
|
|
|
|
|
|
|
|
net: allow user to set metric on default route learned via Router Advertisement
For IPv4, default route is learned via DHCPv4 and user is allowed to change
metric using config etc/network/interfaces. But for IPv6, default route can
be learned via RA, for which, currently a fixed metric value 1024 is used.
Ideally, user should be able to configure metric on default route for IPv6
similar to IPv4. This patch adds sysctl for the same.
Logs:
For IPv4:
Config in etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
metric 4261413864
IPv4 Kernel Route Table:
$ ip route list
default via 172.21.47.1 dev eth0 metric 4261413864
FRR Table, if a static route is configured:
[In real scenario, it is useful to prefer BGP learned default route over DHCPv4 default route.]
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
> - selected route, * - FIB route
S>* 0.0.0.0/0 [20/0] is directly connected, eth0, 00:00:03
K 0.0.0.0/0 [254/1000] via 172.21.47.1, eth0, 6d08h51m
i.e. User can prefer Default Router learned via Routing Protocol in IPv4.
Similar behavior is not possible for IPv6, without this fix.
After fix [for IPv6]:
sudo sysctl -w net.ipv6.conf.eth0.net.ipv6.conf.eth0.ra_defrtr_metric=1996489705
IP monitor: [When IPv6 RA is received]
default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489705 pref high
Kernel IPv6 routing table
$ ip -6 route list
default via fe80::be16:65ff:feb3:ce8e dev eth0 proto ra metric 1996489705 expires 21sec hoplimit 64 pref high
FRR Table, if a static route is configured:
[In real scenario, it is useful to prefer BGP learned default route over IPv6 RA default route.]
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
> - selected route, * - FIB route
S>* ::/0 [20/0] is directly connected, eth0, 00:00:06
K ::/0 [119/1001] via fe80::xx16:xxxx:feb3:ce8e, eth0, 6d07h43m
If the metric is changed later, the effect will be seen only when next IPv6
RA is received, because the default route must be fully controlled by RA msg.
Below metric is changed from 1996489705 to 1996489704.
$ sudo sysctl -w net.ipv6.conf.eth0.ra_defrtr_metric=1996489704
net.ipv6.conf.eth0.ra_defrtr_metric = 1996489704
IP monitor:
[On next IPv6 RA msg, Kernel deletes prev route and installs new route with updated metric]
Deleted default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489705 expires 3sec hoplimit 64 pref high
default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489704 pref high
Signed-off-by: Praveen Chaudhary <pchaudhary@linkedin.com>
Signed-off-by: Zhenggen Xu <zxu@linkedin.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210125214430.24079-1-pchaudhary@linkedin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 13:44:30 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-27 13:56:45 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-08-13 20:49:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:11 -07:00
|
|
|
|
2024-02-08 14:06:49 -08:00
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2019-05-22 20:27:59 -07:00
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:21 -07:00
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:25 -07:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-02-10 14:09:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-18 15:38:59 -07:00
|
|
|
|
2022-02-10 14:09:35 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2024-02-08 14:06:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:17 -07:00
|
|
|
|
2024-02-08 14:06:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2015-07-30 14:28:42 +08:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:16 -07:00
|
|
|
|
|
|
|
|
|
2015-03-25 09:28:15 +01:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2015-03-25 09:28:15 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-20 16:55:08 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-01 14:46:20 +08:00
|
|
|
|
|
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-09-01 01:57:30 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-07 19:26:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-22 05:39:46 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-09-01 01:57:30 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2009-08-29 00:04:09 -07:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2009-08-29 00:04:09 -07:00
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2014-07-10 18:02:46 +08:00
|
|
|
|
2015-12-23 22:44:37 +01:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2011-10-24 19:13:15 -04:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2011-10-24 19:13:15 -04:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-15 23:56:52 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-26 15:46:56 +08:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2013-11-26 15:46:56 +08:00
|
|
|
|
2023-07-26 16:07:01 -07:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2023-07-26 16:07:01 -07:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2017-03-22 18:19:04 +09:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2006-03-20 17:07:03 -08:00
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
|
|
|
|
|
2011-10-24 19:13:15 -04:00
|
|
|
|
|
|
|
|
|
2006-03-20 17:06:24 -08:00
|
|
|
|
|
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2014-06-25 14:44:52 -07:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-04 10:49:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:31 +00:00
|
|
|
|
2006-11-14 20:56:00 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
2006-11-14 20:56:00 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2026-01-18 15:29:41 +00:00
|
|
|
|
|
|
|
|
|
ipv6: add IFLA_INET6_RA_MTU to expose mtu value
The kernel provides a "/proc/sys/net/ipv6/conf/<iface>/mtu"
file, which can temporarily record the mtu value of the last
received RA message when the RA mtu value is lower than the
interface mtu, but this proc has following limitations:
(1) when the interface mtu (/sys/class/net/<iface>/mtu) is
updeated, mtu6 (/proc/sys/net/ipv6/conf/<iface>/mtu) will
be updated to the value of interface mtu;
(2) mtu6 (/proc/sys/net/ipv6/conf/<iface>/mtu) only affect
ipv6 connection, and not affect ipv4.
Therefore, when the mtu option is carried in the RA message,
there will be a problem that the user sometimes cannot obtain
RA mtu value correctly by reading mtu6.
After this patch set, if a RA message carries the mtu option,
you can send a netlink msg which nlmsg_type is RTM_GETLINK,
and then by parsing the attribute of IFLA_INET6_RA_MTU to
get the mtu value carried in the RA message received on the
inet6 device. In addition, you can also get a link notification
when ra_mtu is updated so it doesn't have to poll.
In this way, if the MTU values that the device receives from
the network in the PCO IPv4 and the RA IPv6 procedures are
different, the user can obtain the correct ipv6 ra_mtu value
and compare the value of ra_mtu and ipv4 mtu, then the device
can use the lower MTU value for both IPv4 and IPv6.
Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210827150412.9267-1-rocco.yue@mediatek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-27 23:04:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2024-02-28 13:54:28 +00:00
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:16 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
2008-01-22 17:32:53 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2008-01-22 17:32:53 +09:00
|
|
|
|
2007-10-10 21:22:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ipv6: add IFLA_INET6_RA_MTU to expose mtu value
The kernel provides a "/proc/sys/net/ipv6/conf/<iface>/mtu"
file, which can temporarily record the mtu value of the last
received RA message when the RA mtu value is lower than the
interface mtu, but this proc has following limitations:
(1) when the interface mtu (/sys/class/net/<iface>/mtu) is
updeated, mtu6 (/proc/sys/net/ipv6/conf/<iface>/mtu) will
be updated to the value of interface mtu;
(2) mtu6 (/proc/sys/net/ipv6/conf/<iface>/mtu) only affect
ipv6 connection, and not affect ipv4.
Therefore, when the mtu option is carried in the RA message,
there will be a problem that the user sometimes cannot obtain
RA mtu value correctly by reading mtu6.
After this patch set, if a RA message carries the mtu option,
you can send a netlink msg which nlmsg_type is RTM_GETLINK,
and then by parsing the attribute of IFLA_INET6_RA_MTU to
get the mtu value carried in the RA message received on the
inet6 device. In addition, you can also get a link notification
when ra_mtu is updated so it doesn't have to poll.
In this way, if the MTU values that the device receives from
the network in the PCO IPv4 and the RA IPv6 procedures are
different, the user can obtain the correct ipv6 ra_mtu value
and compare the value of ra_mtu and ipv4 mtu, then the device
can use the lower MTU value for both IPv4 and IPv6.
Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210827150412.9267-1-rocco.yue@mediatek.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-27 23:04:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-17 17:33:25 -07:00
|
|
|
|
2012-01-27 15:07:56 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-12-14 02:59:59 +00:00
|
|
|
|
2013-05-28 20:34:26 +00:00
|
|
|
|
2012-12-14 02:59:59 +00:00
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 02:59:59 +00:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2008-03-15 23:59:18 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2023-02-16 16:28:40 +00:00
|
|
|
|
2012-12-14 02:59:59 +00:00
|
|
|
|
2013-08-22 12:07:35 +08:00
|
|
|
|
2013-09-04 19:44:21 +08:00
|
|
|
|
2018-09-29 23:44:50 -07:00
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2013-08-22 12:07:35 +08:00
|
|
|
|
2012-12-14 02:59:59 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2012-12-14 02:59:59 +00:00
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:53 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:09 +00:00
|
|
|
|
2013-01-21 06:48:53 +00:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-08 17:00:02 +01:00
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:09 +00:00
|
|
|
|
|
|
|
|
|
2012-01-27 15:30:48 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
2025-02-14 14:07:05 +00:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
2013-01-21 06:48:49 +00:00
|
|
|
|
2012-06-08 23:24:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-05 16:34:51 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-12 16:22:43 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
2012-07-10 03:58:16 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-02-14 14:07:05 +00:00
|
|
|
|
|
|
|
|
|
2018-06-01 00:05:21 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 17:08:10 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2007-10-08 00:12:05 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
[IPV6]: fix BUG of ndisc_send_redirect()
When I tested IPv6 redirect function about kernel 2.6.19.1, and found
that the kernel can send redirect packets whose target address is global
address, and the target is not the actual endpoint of communication.
But the criteria conform to RFC2461, the target address defines as
following:
Target Address An IP address that is a better first hop to use for
he ICMP Destination Address. When the target is
the actual endpoint of communication, i.e., the
destination is a neighbor, the Target Address field
MUST contain the same value as the ICMP Destination
Address field. Otherwise the target is a better
first-hop router and the Target Address MUST be the
router's link-local address so that hosts can
uniquely identify routers.
According to this definition, when a router redirect to a host, the
target address either the better first-hop router's link-local address
or the same as the ICMP destination address field. But the function of
ndisc_send_redirect() in net/ipv6/ndisc.c, does not check the target
address correctly.
There is another definition about receive Redirect message in RFC2461:
8.1. Validation of Redirect Messages
A host MUST silently discard any received Redirect message that does
not satisfy all of the following validity checks:
......
- The ICMP Target Address is either a link-local address (when
redirected to a router) or the same as the ICMP Destination
Address (when redirected to the on-link destination).
......
And the receive redirect function of ndisc_redirect_rcv() implemented
this definition, checks the target address correctly.
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
} else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not link-local.\n");
return;
}
So, I think the send redirect function must check the target address
also.
Signed-off-by: Li Yewang <lyw@nanjing-fnst.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-01-30 14:33:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-12 16:22:43 -05:00
|
|
|
|
2016-09-10 12:09:57 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-03-12 16:22:43 -05:00
|
|
|
|
2012-02-21 22:10:49 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-02-21 22:10:49 +00:00
|
|
|
|
2011-03-12 16:22:43 -05:00
|
|
|
|
2011-03-02 13:27:41 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2024-04-26 15:19:52 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2009-02-06 23:47:37 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-12-15 17:56:29 +00:00
|
|
|
|
2024-12-15 17:56:26 +00:00
|
|
|
|
2012-07-10 03:58:16 -07:00
|
|
|
|
2024-12-15 17:56:29 +00:00
|
|
|
|
2012-07-10 03:58:16 -07:00
|
|
|
|
2009-02-06 23:47:37 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-01-27 15:30:48 -08:00
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2012-01-27 15:30:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-01-27 15:30:48 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:49 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:48:49 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-21 06:48:49 +00:00
|
|
|
|
2013-01-21 06:48:14 +00:00
|
|
|
|
2009-02-06 23:47:37 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
networking: make skb_put & friends return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions (skb_put, __skb_put and pskb_put) return void *
and remove all the casts across the tree, adding a (u8 *) cast only
where the unsigned char pointer was used directly, all done with the
following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_put, __skb_put };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_put, __skb_put };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
which actually doesn't cover pskb_put since there are only three
users overall.
A handful of stragglers were converted manually, notably a macro in
drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
instances in net/bluetooth/hci_sock.c. In the former file, I also
had to fix one whitespace problem spatch introduced.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:21 +02:00
|
|
|
|
2013-01-21 06:49:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-15 21:20:23 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-21 06:48:09 +00:00
|
|
|
|
2013-01-21 06:48:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-02 05:19:30 +00:00
|
|
|
|
2013-01-21 06:49:03 +00:00
|
|
|
|
2009-02-06 23:47:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2020-11-12 20:58:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-27 01:36:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
2013-08-27 01:36:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-08-27 01:36:51 +02:00
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2013-08-27 01:36:51 +02:00
|
|
|
|
2013-01-21 06:48:03 +00:00
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-25 17:54:47 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-24 14:37:21 +02:00
|
|
|
|
2023-02-16 16:28:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:36 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:37 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:38 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-16 16:28:39 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-20 17:09:22 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-02-10 18:47:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-28 01:30:21 +00:00
|
|
|
|
2015-07-29 12:01:41 +02:00
|
|
|
|
2008-03-25 21:47:49 +09:00
|
|
|
|
2012-11-06 16:46:20 +00:00
|
|
|
|
2021-11-01 10:36:29 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-01 10:04:14 +02:00
|
|
|
|
2020-03-12 15:50:22 -07:00
|
|
|
|
2017-04-12 11:49:04 -07:00
|
|
|
|
2012-11-06 16:46:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
|
|
|
|
|
2012-11-06 16:46:20 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-07-29 12:01:41 +02:00
|
|
|
|
2021-11-01 10:36:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-28 13:54:38 +00:00
|
|
|
|
|
|
|
|
|
2021-11-01 10:36:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-29 12:01:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-01 10:36:29 -07:00
|
|
|
|
2018-10-11 20:33:49 -07:00
|
|
|
|
2015-07-29 12:01:41 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-08-01 10:04:14 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-04-15 13:46:02 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-08 15:51:02 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-27 19:04:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-28 20:32:20 +08:00
|
|
|
|
2012-05-15 14:11:53 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sysctl: treewide: constify the ctl_table argument of proc_handlers
const qualify the struct ctl_table argument in the proc_handler function
signatures. This is a prerequisite to moving the static ctl_table
structs into .rodata data which will ensure that proc_handler function
pointers cannot be modified.
This patch has been generated by the following coccinelle script:
```
virtual patch
@r1@
identifier ctl, write, buffer, lenp, ppos;
identifier func !~ "appldata_(timer|interval)_handler|sched_(rt|rr)_handler|rds_tcp_skbuf_handler|proc_sctp_do_(hmac_alg|rto_min|rto_max|udp_port|alpha_beta|auth|probe_interval)";
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos);
@r2@
identifier func, ctl, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int write, void *buffer, size_t *lenp, loff_t *ppos)
{ ... }
@r3@
identifier func;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int , void *, size_t *, loff_t *);
@r4@
identifier func, ctl;
@@
int func(
- struct ctl_table *ctl
+ const struct ctl_table *ctl
,int , void *, size_t *, loff_t *);
@r5@
identifier func, write, buffer, lenp, ppos;
@@
int func(
- struct ctl_table *
+ const struct ctl_table *
,int write, void *buffer, size_t *lenp, loff_t *ppos);
```
* Code formatting was adjusted in xfs_sysctl.c to comply with code
conventions. The xfs_stats_clear_proc_handler,
xfs_panic_mask_proc_handler and xfs_deprecated_dointvec_minmax where
adjusted.
* The ctl_table argument in proc_watchdog_common was const qualified.
This is called from a proc_handler itself and is calling back into
another proc_handler, making it necessary to change it as part of the
proc_handler migration.
Co-developed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Co-developed-by: Joel Granados <j.granados@samsung.com>
Signed-off-by: Joel Granados <j.granados@samsung.com>
2024-07-24 20:59:29 +02:00
|
|
|
|
2020-04-24 08:43:38 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-18 03:05:25 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-10-18 03:05:25 -07:00
|
|
|
|
2013-12-07 19:26:54 +01:00
|
|
|
|
2007-10-18 03:05:25 -07:00
|
|
|
|
|
|
|
|
|
2013-12-07 19:26:54 +01:00
|
|
|
|
|
|
|
|
|
2007-10-18 03:05:25 -07:00
|
|
|
|
|
|
|
|
|
2007-10-29 01:32:23 -07:00
|
|
|
|
2013-12-07 19:26:54 +01:00
|
|
|
|
|
|
|
|
|
2007-10-18 03:05:25 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-22 05:39:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-22 10:50:09 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-17 03:35:32 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-03 14:31:03 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-07-08 11:33:42 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-03 14:31:03 -07:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-12 16:02:00 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-17 03:35:32 +00:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
2008-04-03 14:31:03 -07:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-10 15:59:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-12-07 19:26:55 +01:00
|
|
|
|
2014-07-25 01:49:37 +05:30
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-16 00:52:08 -02:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-09 21:45:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-10 15:59:36 -08:00
|
|
|
|
2008-03-07 11:15:34 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|