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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-05-15 14:11:53 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-11 12:17:47 -08: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
|
|
|
|
2016-12-24 11:46:01 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-05 16:35:42 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 14:49:35 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
|
|
|
|
|
2025-03-07 10:30:06 -08:00
|
|
|
|
2024-08-29 09:54:56 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-10 11:03:35 +02:00
|
|
|
|
2006-11-14 20:56:00 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-27 03:07:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
netns: make struct pernet_operations::id unsigned int
Make struct pernet_operations::id unsigned.
There are 2 reasons to do so:
1)
This field is really an index into an zero based array and
thus is unsigned entity. Using negative value is out-of-bound
access by definition.
2)
On x86_64 unsigned 32-bit data which are mixed with pointers
via array indexing or offsets added or subtracted to pointers
are preffered to signed 32-bit data.
"int" being used as an array index needs to be sign-extended
to 64-bit before being used.
void f(long *p, int i)
{
g(p[i]);
}
roughly translates to
movsx rsi, esi
mov rdi, [rsi+...]
call g
MOVSX is 3 byte instruction which isn't necessary if the variable is
unsigned because x86_64 is zero extending by default.
Now, there is net_generic() function which, you guessed it right, uses
"int" as an array index:
static inline void *net_generic(const struct net *net, int id)
{
...
ptr = ng->ptr[id - 1];
...
}
And this function is used a lot, so those sign extensions add up.
Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
messing with code generation):
add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
Unfortunately some functions actually grow bigger.
This is a semmingly random artefact of code generation with register
allocator being used differently. gcc decides that some variable
needs to live in new r8+ registers and every access now requires REX
prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
used which is longer than [r8]
However, overall balance is in negative direction:
add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
function old new delta
nfsd4_lock 3886 3959 +73
tipc_link_build_proto_msg 1096 1140 +44
mac80211_hwsim_new_radio 2776 2808 +32
tipc_mon_rcv 1032 1058 +26
svcauth_gss_legacy_init 1413 1429 +16
tipc_bcbase_select_primary 379 392 +13
nfsd4_exchange_id 1247 1260 +13
nfsd4_setclientid_confirm 782 793 +11
...
put_client_renew_locked 494 480 -14
ip_set_sockfn_get 730 716 -14
geneve_sock_add 829 813 -16
nfsd4_sequence_done 721 703 -18
nlmclnt_lookup_host 708 686 -22
nfsd4_lockt 1085 1063 -22
nfs_get_client 1077 1050 -27
tcf_bpf_init 1106 1076 -30
nfsd4_encode_fattr 5997 5930 -67
Total: Before=154856051, After=154854321, chg -0.00%
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17 04:58:21 +03:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
2016-08-10 11:03:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:16:38 -07:00
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-23 17:52:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-01 07:49:01 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-16 01:16:38 -07:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-11 21:52:34 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
|
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-11-11 21:52:34 +00:00
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
|
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-11-11 21:52:34 +00:00
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
|
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-23 17:52:14 +00:00
|
|
|
|
2015-03-29 14:00:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-04-24 20:44:47 +09:00
|
|
|
|
|
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-16 01:16:38 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
2008-04-16 01:15:39 -07:00
|
|
|
|
2007-04-24 20:44:47 +09:00
|
|
|
|
2008-04-16 01:15:39 -07:00
|
|
|
|
2007-04-24 20:44:47 +09:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:15:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-12 04:41:32 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-16 01:15:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-12 04:41:32 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-11 03:31:34 +00:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
2009-10-11 03:31:34 +00:00
|
|
|
|
|
|
|
|
|
net: do not create fallback tunnels for non-default namespaces
fallback tunnels (like tunl0, gre0, gretap0, erspan0, sit0,
ip6tnl0, ip6gre0) are automatically created when the corresponding
module is loaded.
These tunnels are also automatically created when a new network
namespace is created, at a great cost.
In many cases, netns are used for isolation purposes, and these
extra network devices are a waste of resources. We are using
thousands of netns per host, and hit the netns creation/delete
bottleneck a lot. (Many thanks to Kirill for recent work on this)
Add a new sysctl so that we can opt-out from this automatic creation.
Note that these tunnels are still created for the initial namespace,
to be the least intrusive for typical setups.
Tested:
lpk43:~# cat add_del_unshare.sh
for i in `seq 1 40`
do
(for j in `seq 1 100` ; do unshare -n /bin/true >/dev/null ; done) &
done
wait
lpk43:~# echo 0 >/proc/sys/net/core/fb_tunnels_only_for_init_net
lpk43:~# time ./add_del_unshare.sh
real 0m37.521s
user 0m0.886s
sys 7m7.084s
lpk43:~# echo 1 >/proc/sys/net/core/fb_tunnels_only_for_init_net
lpk43:~# time ./add_del_unshare.sh
real 0m4.761s
user 0m0.851s
sys 1m8.343s
lpk43:~#
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-08 12:51:41 -08:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-19 20:50:34 +08:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
2021-10-12 09:06:34 -07:00
|
|
|
|
2014-11-03 09:19:29 +01:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
ip_tunnel: convert __be16 tunnel flags to bitmaps
Historically, tunnel flags like TUNNEL_CSUM or TUNNEL_ERSPAN_OPT
have been defined as __be16. Now all of those 16 bits are occupied
and there's no more free space for new flags.
It can't be simply switched to a bigger container with no
adjustments to the values, since it's an explicit Endian storage,
and on LE systems (__be16)0x0001 equals to
(__be64)0x0001000000000000.
We could probably define new 64-bit flags depending on the
Endianness, i.e. (__be64)0x0001 on BE and (__be64)0x00010000... on
LE, but that would introduce an Endianness dependency and spawn a
ton of Sparse warnings. To mitigate them, all of those places which
were adjusted with this change would be touched anyway, so why not
define stuff properly if there's no choice.
Define IP_TUNNEL_*_BIT counterparts as a bit number instead of the
value already coded and a fistful of <16 <-> bitmap> converters and
helpers. The two flags which have a different bit position are
SIT_ISATAP_BIT and VTI_ISVTI_BIT, as they were defined not as
__cpu_to_be16(), but as (__force __be16), i.e. had different
positions on LE and BE. Now they both have strongly defined places.
Change all __be16 fields which were used to store those flags, to
IP_TUNNEL_DECLARE_FLAGS() -> DECLARE_BITMAP(__IP_TUNNEL_FLAG_NUM) ->
unsigned long[1] for now, and replace all TUNNEL_* occurrences to
their bitmap counterparts. Use the converters in the places which talk
to the userspace, hardware (NFP) or other hosts (GRE header). The rest
must explicitly use the new flags only. This must be done at once,
otherwise there will be too many conversions throughout the code in
the intermediate commits.
Finally, disable the old __be16 flags for use in the kernel code
(except for the two 'irregular' flags mentioned above), to prevent
any accidental (mis)use of them. For the userspace, nothing is
changed, only additions were made.
Most noticeable bloat-o-meter difference (.text):
vmlinux: 307/-1 (306)
gre.ko: 62/0 (62)
ip_gre.ko: 941/-217 (724) [*]
ip_tunnel.ko: 390/-900 (-510) [**]
ip_vti.ko: 138/0 (138)
ip6_gre.ko: 534/-18 (516) [*]
ip6_tunnel.ko: 118/-10 (108)
[*] gre_flags_to_tnl_flags() grew, but still is inlined
[**] ip_tunnel_find() got uninlined, hence such decrease
The average code size increase in non-extreme case is 100-200 bytes
per module, mostly due to sizeof(long) > sizeof(__be16), as
%__IP_TUNNEL_FLAG_NUM is less than %BITS_PER_LONG and the compilers
are able to expand the majority of bitmap_*() calls here into direct
operations on scalars.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-03-27 16:23:53 +01:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
2016-01-25 11:29:19 -02:00
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-03 09:19:29 +01:00
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-11-14 20:56:00 -08:00
|
|
|
|
|
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:15:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-19 12:56:48 +00:00
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
|
|
|
|
|
2009-05-19 12:56:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-05 06:39:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-18 23:02:20 +02:00
|
|
|
|
2018-04-05 06:39:28 -07:00
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2018-04-05 06:39:28 -07:00
|
|
|
|
net: set name_assign_type in alloc_netdev()
Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
all users to pass NET_NAME_UNKNOWN.
Coccinelle patch:
@@
expression sizeof_priv, name, setup, txqs, rxqs, count;
@@
(
-alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
+alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
|
-alloc_netdev_mq(sizeof_priv, name, setup, count)
+alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
|
-alloc_netdev(sizeof_priv, name, setup)
+alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
)
v9: move comments here from the wrong commit
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-14 16:37:24 +02:00
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:17:18 -07:00
|
|
|
|
|
|
|
|
|
2006-01-08 22:05:26 -08:00
|
|
|
|
2008-11-20 20:33:56 -08:00
|
|
|
|
2025-02-19 20:50:33 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
[INET]: Don't create tunnels with '%' in name.
Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can receive a
pre-defined name for a device from the userspace. Since these drivers
call the register_netdevice() (rtnl_lock, is held), which does _not_
generate the device's name, this name may contain a '%' character.
Not sure how bad is this to have a device with a '%' in its name, but
all the other places either use the register_netdev(), which call the
dev_alloc_name(), or explicitly call the dev_alloc_name() before
registering, i.e. do not allow for such names.
This had to be prior to the commit 34cc7b, but I forgot to number the
patches and this one got lost, sorry.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-26 23:51:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-06-02 18:36:26 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
[INET]: Don't create tunnels with '%' in name.
Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can receive a
pre-defined name for a device from the userspace. Since these drivers
call the register_netdevice() (rtnl_lock, is held), which does _not_
generate the device's name, this name may contain a '%' character.
Not sure how bad is this to have a device with a '%' in its name, but
all the other places either use the register_netdev(), which call the
dev_alloc_name(), or explicitly call the dev_alloc_name() before
registering, i.e. do not allow for such names.
This had to be prior to the commit 34cc7b, but I forgot to number the
patches and this one got lost, sorry.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-02-26 23:51:04 -08: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
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
2008-06-16 16:48:20 -07:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-16 16:48:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
2021-03-27 10:29:32 +01:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
|
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-28 11:50:30 +08:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2009-09-29 11:27:05 +00:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
2008-06-16 16:48:20 -07:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-16 16:48:20 -07:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
2022-06-28 11:50:30 +08:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
2008-06-16 16:48:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
2022-06-28 11:50:30 +08:00
|
|
|
|
2008-06-16 16:48:20 -07:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
|
|
|
|
|
2008-03-22 17:50:59 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-01 00:26:58 -07:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
|
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2012-01-12 04:41:32 +00:00
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-20 07:16:24 +00:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-20 07:16:24 +00:00
|
|
|
|
|
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
|
|
|
|
|
2010-06-01 00:26:58 -07:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2008-03-22 17:50:59 +09:00
|
|
|
|
2011-01-20 07:16:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2011-05-02 00:56:57 -07:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2011-01-20 07:16:24 +00:00
|
|
|
|
|
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
2009-05-19 12:56:50 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2008-03-22 17:42:57 +09:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
|
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
2008-03-15 22:54:23 -04:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:15:39 -07:00
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
2011-08-01 16:19:00 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2022-06-07 21:39:55 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
2007-03-13 14:43:18 -03:00
|
|
|
|
|
|
|
|
|
2016-06-18 21:52:06 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2016-06-18 21:52:06 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-12 00:25:15 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
|
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-29 14:00:04 +01:00
|
|
|
|
2012-06-14 22:21:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-25 20:56:26 -07:00
|
|
|
|
2012-06-14 22:21:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-12 00:25:15 -07:00
|
|
|
|
2018-09-25 20:56:27 -07:00
|
|
|
|
|
|
|
|
|
2012-07-12 00:25:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-14 22:21:46 -07:00
|
|
|
|
2016-06-18 21:52:04 -07:00
|
|
|
|
2019-02-07 18:36:11 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2016-06-18 21:52:04 -07:00
|
|
|
|
2013-11-22 16:23:20 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-24 23:37:19 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-23 23:04:19 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-01-18 09:18:17 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
2012-11-27 03:07:11 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
2009-05-19 12:56:49 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
2015-03-29 14:00:05 +01:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-10 21:21:55 -07:00
|
|
|
|
2007-04-10 20:45:18 -07:00
|
|
|
|
2006-01-06 23:04:01 -08:00
|
|
|
|
2016-03-19 09:32:02 -07:00
|
|
|
|
2007-11-29 22:11:40 +11:00
|
|
|
|
2013-09-23 23:04:19 +03:00
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2013-09-23 23:04:19 +03:00
|
|
|
|
2012-11-27 03:07:11 +00:00
|
|
|
|
|
|
|
|
|
2016-03-19 09:32:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-27 03:07:11 +00:00
|
|
|
|
2019-04-04 16:37:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-25 15:33:08 +02:00
|
|
|
|
|
|
|
|
|
2012-11-27 03:07:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
|
|
|
|
|
2012-11-27 03:07:11 +00:00
|
|
|
|
|
|
|
|
|
2007-11-29 22:11:40 +11:00
|
|
|
|
2010-05-17 22:36:55 -07:00
|
|
|
|
2022-06-08 08:46:34 -07:00
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2010-09-30 21:06:55 +00:00
|
|
|
|
2010-09-20 00:12:11 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-29 19:32:34 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-05-08 23:40:26 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2013-06-17 17:50:02 -07:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2013-06-17 17:50:02 -07:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2017-10-30 10:07:17 -07:00
|
|
|
|
2015-03-29 14:00:05 +01:00
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 11:54:50 +02:00
|
|
|
|
2021-06-25 15:33:08 +02:00
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-15 11:35:10 +00:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-11 16:29:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-11 03:44:45 +00:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-09 23:24:49 +09:00
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-01 19:48:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-31 19:50:41 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-08 22:05:26 -08:00
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-09 08:42:01 +00:00
|
|
|
|
2014-08-24 21:53:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-14 20:56:00 -08:00
|
|
|
|
2011-05-03 20:25:42 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-17 17:49:56 -07:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-08-13 14:04:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-29 22:11:40 +11:00
|
|
|
|
2025-09-01 19:48:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-29 22:11:40 +11:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-29 08:24:25 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2025-09-01 19:48:57 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2024-08-29 09:54:56 +03:00
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
|
|
|
|
|
2019-07-14 21:31:22 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2019-07-14 21:31:22 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-07-14 21:31:22 +08:00
|
|
|
|
2022-01-07 12:38:42 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-06-10 23:31:35 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-18 09:06:10 -07:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2016-04-14 15:33:37 -04:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
2009-11-09 08:42:01 +00:00
|
|
|
|
2026-01-30 21:03:02 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-06-02 09:50:39 +08:00
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2009-11-09 08:42:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-09 08:42:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-25 19:03:03 +01:00
|
|
|
|
2019-12-22 10:51:15 +08:00
|
|
|
|
2009-11-09 08:42:01 +00:00
|
|
|
|
2013-12-16 06:31:23 -08:00
|
|
|
|
2021-02-27 01:40:19 +01:00
|
|
|
|
2009-11-09 08:42:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-24 23:37:19 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-09 15:33:40 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2013-11-25 17:21:24 +08:00
|
|
|
|
2009-06-23 06:03:08 +00: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
|
|
|
|
2013-06-17 17:49:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-04-07 15:38:53 +02:00
|
|
|
|
2013-12-20 17:20:12 +08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2013-12-20 17:20:12 +08:00
|
|
|
|
2013-08-18 13:46:52 +02:00
|
|
|
|
2014-09-29 20:22:30 -07:00
|
|
|
|
|
|
|
|
|
2015-12-24 14:34:54 -08:00
|
|
|
|
2025-06-17 00:44:09 +02:00
|
|
|
|
2009-06-23 06:03:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-25 17:21:24 +08:00
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2009-06-23 06:03:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-18 09:06:10 -07:00
|
|
|
|
2016-04-14 15:33:37 -04:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2014-09-29 20:22:30 -07:00
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2016-04-14 15:33:37 -04:00
|
|
|
|
|
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2013-10-20 20:47:30 -07:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-30 17:24:36 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-15 08:53:56 +00:00
|
|
|
|
2013-11-25 17:21:24 +08:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
|
|
|
|
|
2023-04-26 23:00:06 -07:00
|
|
|
|
|
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
2023-04-26 23:00:06 -07:00
|
|
|
|
2011-04-22 04:53:02 +00:00
|
|
|
|
2011-05-03 20:25:42 -07:00
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
|
|
|
|
|
2011-03-12 00:00:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-03 16:53:27 +03:00
|
|
|
|
2011-03-12 00:00:52 -05:00
|
|
|
|
2011-03-02 14:31:35 -08:00
|
|
|
|
|
|
|
|
|
2010-06-10 23:31:35 -07:00
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
2019-05-06 15:00:01 -04:00
|
|
|
|
2022-10-23 19:01:24 -07:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2022-10-23 19:01:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-26 23:00:06 -07:00
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
2023-04-26 23:00:06 -07:00
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 09:06:34 -07:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-30 10:41:14 +08:00
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
2016-08-13 01:54:15 +00:00
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2008-03-24 18:28:39 +09:00
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2008-03-11 18:35:59 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2009-09-22 23:43:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-05-19 15:03:15 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-20 20:33:56 -08:00
|
|
|
|
2014-11-03 09:19:29 +01:00
|
|
|
|
2008-11-20 20:33:56 -08:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2021-07-27 15:45:06 +02:00
|
|
|
|
2015-04-02 17:07:02 +02:00
|
|
|
|
2020-05-19 15:03:16 +02:00
|
|
|
|
2008-11-20 20:33:56 -08:00
|
|
|
|
|
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
|
|
|
|
|
2014-02-20 10:19:31 +01:00
|
|
|
|
|
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
|
|
|
|
|
2013-10-20 20:47:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-20 20:33:56 -08:00
|
|
|
|
2020-06-29 19:06:24 -06: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
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2016-10-20 13:55:24 -04:00
|
|
|
|
2018-05-31 10:59:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-10-05 18:38:35 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-08-29 14:33:37 +02:00
|
|
|
|
2013-10-20 20:47:30 -07:00
|
|
|
|
|
|
|
|
|
2024-02-21 08:17:32 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-11-20 20:33:56 -08:00
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-11-03 09:19:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-12-13 09:47:00 -08:00
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2024-02-21 08:17:32 -08:00
|
|
|
|
2016-02-12 15:43:55 +01:00
|
|
|
|
2024-02-21 08:17:32 -08:00
|
|
|
|
2022-06-07 21:39:55 -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
|
|
|
|
2010-09-27 00:38:18 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-11-02 17:08:19 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-08 22:05:26 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-16 01:16:38 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-12 04:41:32 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-06-25 23:56:01 +02:00
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-19 12:03:13 +02:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-29 21:52:03 +08:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-29 16:59:26 +02:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rtnetlink: Pack newlink() params into struct
There are 4 net namespaces involved when creating links:
- source netns - where the netlink socket resides,
- target netns - where to put the device being created,
- link netns - netns associated with the device (backend),
- peer netns - netns of peer device.
Currently, two nets are passed to newlink() callback - "src_net"
parameter and "dev_net" (implicitly in net_device). They are set as
follows, depending on netlink attributes in the request.
+------------+-------------------+---------+---------+
| peer netns | IFLA_LINK_NETNSID | src_net | dev_net |
+------------+-------------------+---------+---------+
| | absent | source | target |
| absent +-------------------+---------+---------+
| | present | link | link |
+------------+-------------------+---------+---------+
| | absent | peer | target |
| present +-------------------+---------+---------+
| | present | peer | link |
+------------+-------------------+---------+---------+
When IFLA_LINK_NETNSID is present, the device is created in link netns
first and then moved to target netns. This has some side effects,
including extra ifindex allocation, ifname validation and link events.
These could be avoided if we create it in target netns from
the beginning.
On the other hand, the meaning of src_net parameter is ambiguous. It
varies depending on how parameters are passed. It is the effective
link (or peer netns) by design, but some drivers ignore it and use
dev_net instead.
To provide more netns context for drivers, this patch packs existing
newlink() parameters, along with the source netns, link netns and peer
netns, into a struct. The old "src_net" is renamed to "net" to avoid
confusion with real source netns, and will be deprecated later. The use
of src_net are converted to params->net trivially.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20250219125039.18024-3-shaw.leon@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-19 20:50:28 +08:00
|
|
|
|
|
|
|
|
|
2017-06-25 23:55:59 +02:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
rtnetlink: Pack newlink() params into struct
There are 4 net namespaces involved when creating links:
- source netns - where the netlink socket resides,
- target netns - where to put the device being created,
- link netns - netns associated with the device (backend),
- peer netns - netns of peer device.
Currently, two nets are passed to newlink() callback - "src_net"
parameter and "dev_net" (implicitly in net_device). They are set as
follows, depending on netlink attributes in the request.
+------------+-------------------+---------+---------+
| peer netns | IFLA_LINK_NETNSID | src_net | dev_net |
+------------+-------------------+---------+---------+
| | absent | source | target |
| absent +-------------------+---------+---------+
| | present | link | link |
+------------+-------------------+---------+---------+
| | absent | peer | target |
| present +-------------------+---------+---------+
| | present | peer | link |
+------------+-------------------+---------+---------+
When IFLA_LINK_NETNSID is present, the device is created in link netns
first and then moved to target netns. This has some side effects,
including extra ifindex allocation, ifname validation and link events.
These could be avoided if we create it in target netns from
the beginning.
On the other hand, the meaning of src_net parameter is ambiguous. It
varies depending on how parameters are passed. It is the effective
link (or peer netns) by design, but some drivers ignore it and use
dev_net instead.
To provide more netns context for drivers, this patch packs existing
newlink() parameters, along with the source netns, link netns and peer
netns, into a struct. The old "src_net" is renamed to "net" to avoid
confusion with real source netns, and will be deprecated later. The use
of src_net are converted to params->net trivially.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20250219125039.18024-3-shaw.leon@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-19 20:50:28 +08:00
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-19 20:50:34 +08:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2025-02-19 20:50:34 +08:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2025-02-19 20:50:33 +08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2022-09-29 21:52:02 +08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-27 19:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-31 10:59:33 +02:00
|
|
|
|
|
|
|
|
|
2018-02-27 19:19:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
2021-01-13 17:29:47 -08:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
2021-01-13 17:29:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 23:56:00 +02:00
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2013-07-03 17:00:34 +02:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2013-07-03 17:00:34 +02:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-29 21:52:02 +08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:06 +00:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:05 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:06 +00:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
2024-03-27 16:23:52 +01:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
2015-03-29 16:59:25 +02:00
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
2012-11-14 05:14:05 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
ip_tunnel: convert __be16 tunnel flags to bitmaps
Historically, tunnel flags like TUNNEL_CSUM or TUNNEL_ERSPAN_OPT
have been defined as __be16. Now all of those 16 bits are occupied
and there's no more free space for new flags.
It can't be simply switched to a bigger container with no
adjustments to the values, since it's an explicit Endian storage,
and on LE systems (__be16)0x0001 equals to
(__be64)0x0001000000000000.
We could probably define new 64-bit flags depending on the
Endianness, i.e. (__be64)0x0001 on BE and (__be64)0x00010000... on
LE, but that would introduce an Endianness dependency and spawn a
ton of Sparse warnings. To mitigate them, all of those places which
were adjusted with this change would be touched anyway, so why not
define stuff properly if there's no choice.
Define IP_TUNNEL_*_BIT counterparts as a bit number instead of the
value already coded and a fistful of <16 <-> bitmap> converters and
helpers. The two flags which have a different bit position are
SIT_ISATAP_BIT and VTI_ISVTI_BIT, as they were defined not as
__cpu_to_be16(), but as (__force __be16), i.e. had different
positions on LE and BE. Now they both have strongly defined places.
Change all __be16 fields which were used to store those flags, to
IP_TUNNEL_DECLARE_FLAGS() -> DECLARE_BITMAP(__IP_TUNNEL_FLAG_NUM) ->
unsigned long[1] for now, and replace all TUNNEL_* occurrences to
their bitmap counterparts. Use the converters in the places which talk
to the userspace, hardware (NFP) or other hosts (GRE header). The rest
must explicitly use the new flags only. This must be done at once,
otherwise there will be too many conversions throughout the code in
the intermediate commits.
Finally, disable the old __be16 flags for use in the kernel code
(except for the two 'irregular' flags mentioned above), to prevent
any accidental (mis)use of them. For the userspace, nothing is
changed, only additions were made.
Most noticeable bloat-o-meter difference (.text):
vmlinux: 307/-1 (306)
gre.ko: 62/0 (62)
ip_gre.ko: 941/-217 (724) [*]
ip_tunnel.ko: 390/-900 (-510) [**]
ip_vti.ko: 138/0 (138)
ip6_gre.ko: 534/-18 (516) [*]
ip6_tunnel.ko: 118/-10 (108)
[*] gre_flags_to_tnl_flags() grew, but still is inlined
[**] ip_tunnel_find() got uninlined, hence such decrease
The average code size increase in non-extreme case is 100-200 bytes
per module, mostly due to sizeof(long) > sizeof(__be16), as
%__IP_TUNNEL_FLAG_NUM is less than %BITS_PER_LONG and the compilers
are able to expand the majority of bitmap_*() calls here into direct
operations on scalars.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2024-03-27 16:23:53 +01:00
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
2015-03-29 16:59:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
2015-02-04 15:12:04 -08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
2015-02-04 15:12:04 -08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
2014-11-05 16:49:38 -08:00
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2012-11-19 22:41:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-17 12:25:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-19 12:30:54 -04:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
2013-11-13 21:27:38 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2012-11-14 05:14:07 +00:00
|
|
|
|
|
|
|
|
|
2012-11-14 05:14:06 +00:00
|
|
|
|
|
|
|
|
|
2013-11-13 21:27:38 -05:00
|
|
|
|
2015-01-15 15:11:17 +01:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
2010-08-30 07:04:14 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-11 13:52:36 -07:00
|
|
|
|
2005-07-30 17:46:44 -07:00
|
|
|
|
2013-11-13 21:27:38 -05:00
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
2005-07-30 17:46:44 -07:00
|
|
|
|
|
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-12 20:41:16 +03:00
|
|
|
|
2005-07-30 17:46:44 -07:00
|
|
|
|
2021-04-12 20:41:16 +03:00
|
|
|
|
2011-01-20 07:16:24 +00:00
|
|
|
|
2009-10-28 04:37:43 +00:00
|
|
|
|
2025-04-11 13:52:36 -07:00
|
|
|
|
2015-03-29 14:00:05 +01:00
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-13 17:51:10 +02:00
|
|
|
|
2025-04-11 13:52:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-28 04:37:43 +00:00
|
|
|
|
2005-07-30 17:46:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-17 03:35:32 +00:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
2009-11-29 15:46:16 +00:00
|
|
|
|
2011-12-08 00:46:21 +00:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:16:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: do not create fallback tunnels for non-default namespaces
fallback tunnels (like tunl0, gre0, gretap0, erspan0, sit0,
ip6tnl0, ip6gre0) are automatically created when the corresponding
module is loaded.
These tunnels are also automatically created when a new network
namespace is created, at a great cost.
In many cases, netns are used for isolation purposes, and these
extra network devices are a waste of resources. We are using
thousands of netns per host, and hit the netns creation/delete
bottleneck a lot. (Many thanks to Kirill for recent work on this)
Add a new sysctl so that we can opt-out from this automatic creation.
Note that these tunnels are still created for the initial namespace,
to be the least intrusive for typical setups.
Tested:
lpk43:~# cat add_del_unshare.sh
for i in `seq 1 40`
do
(for j in `seq 1 100` ; do unshare -n /bin/true >/dev/null ; done) &
done
wait
lpk43:~# echo 0 >/proc/sys/net/core/fb_tunnels_only_for_init_net
lpk43:~# time ./add_del_unshare.sh
real 0m37.521s
user 0m0.886s
sys 7m7.084s
lpk43:~# echo 1 >/proc/sys/net/core/fb_tunnels_only_for_init_net
lpk43:~# time ./add_del_unshare.sh
real 0m4.761s
user 0m0.851s
sys 1m8.343s
lpk43:~#
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-08 12:51:41 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
net: set name_assign_type in alloc_netdev()
Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
all users to pass NET_NAME_UNKNOWN.
Coccinelle patch:
@@
expression sizeof_priv, name, setup, txqs, rxqs, count;
@@
(
-alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
+alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
|
-alloc_netdev_mq(sizeof_priv, name, setup, count)
+alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
|
-alloc_netdev(sizeof_priv, name, setup)
+alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
)
v9: move comments here from the wrong commit
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-14 16:37:24 +02:00
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-23 17:26:26 -08:00
|
|
|
|
2013-10-01 18:04:59 +02:00
|
|
|
|
2013-06-26 16:11:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-28 11:20:56 +01:00
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
2025-02-19 20:50:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-23 21:28:43 +00:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
|
|
|
|
|
2015-11-02 17:08:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-08 00:46:21 +00:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
2019-03-01 23:06:40 +08:00
|
|
|
|
2008-04-16 01:16:18 -07:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-11 13:52:36 -07:00
|
|
|
|
2009-11-29 15:46:16 +00:00
|
|
|
|
|
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
|
|
|
|
|
2006-11-20 16:56:48 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
2007-02-13 12:55:25 -08:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-30 17:46:44 -07:00
|
|
|
|
2009-11-29 15:46:16 +00:00
|
|
|
|
2009-10-23 17:51:26 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-11-20 16:56:48 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-11-29 15:46:16 +00:00
|
|
|
|
2008-04-16 01:15:17 -07:00
|
|
|
|
2010-02-16 09:05:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
2010-02-16 09:05:04 +00:00
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
2016-07-07 07:56:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-27 23:48:16 +00:00
|
|
|
|
|
|
|
|
|
2012-11-09 06:10:00 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-10-10 14:47:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-08 08:42:40 -08:00
|
|
|
|
2006-10-13 15:05:53 -07:00
|
|
|
|
2014-05-15 23:21:30 +02:00
|
|
|
|
2011-03-02 00:33:13 +03:00
|
|
|
|