2019-05-19 13:08:55 +01:00
|
|
|
|
2012-05-16 19:58:40 +00:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-26 22:04:26 -07:00
|
|
|
|
2008-04-15 00:35:23 -07:00
|
|
|
|
2009-07-10 09:51:33 +00:00
|
|
|
|
2009-07-10 09:51:35 +00:00
|
|
|
|
2013-04-12 01:50:06 +01:00
|
|
|
|
|
|
|
|
|
2011-05-04 17:51:50 -07:00
|
|
|
|
2011-07-15 11:47:34 -04:00
|
|
|
|
2012-06-14 02:31:10 -07:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-02-06 10:57:33 +01:00
|
|
|
|
2018-07-20 21:56:53 +00:00
|
|
|
|
2020-09-30 17:18:16 +02:00
|
|
|
|
2022-05-15 18:16:54 -04:00
|
|
|
|
2017-02-06 10:57:33 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2008-04-15 00:36:08 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-08 11:35:06 +02:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-26 21:02:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-05 09:01:25 -08:00
|
|
|
|
2008-01-22 22:05:33 -08:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2016-08-10 14:36:00 -07:00
|
|
|
|
net: Introduce net_sem for protection of pernet_list
Currently, the mutex is mostly used to protect pernet operations
list. It orders setup_net() and cleanup_net() with parallel
{un,}register_pernet_operations() calls, so ->exit{,batch} methods
of the same pernet operations are executed for a dying net, as
were used to call ->init methods, even after the net namespace
is unlinked from net_namespace_list in cleanup_net().
But there are several problems with scalability. The first one
is that more than one net can't be created or destroyed
at the same moment on the node. For big machines with many cpus
running many containers it's very sensitive.
The second one is that it's need to synchronize_rcu() after net
is removed from net_namespace_list():
Destroy net_ns:
cleanup_net()
mutex_lock(&net_mutex)
list_del_rcu(&net->list)
synchronize_rcu() <--- Sleep there for ages
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_exit_list(ops, &net_exit_list)
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_free_list(ops, &net_exit_list)
mutex_unlock(&net_mutex)
This primitive is not fast, especially on the systems with many processors
and/or when preemptible RCU is enabled in config. So, all the time, while
cleanup_net() is waiting for RCU grace period, creation of new net namespaces
is not possible, the tasks, who makes it, are sleeping on the same mutex:
Create net_ns:
copy_net_ns()
mutex_lock_killable(&net_mutex) <--- Sleep there for ages
I observed 20-30 seconds hangs of "unshare -n" on ordinary 8-cpu laptop
with preemptible RCU enabled after CRIU tests round is finished.
The solution is to convert net_mutex to the rw_semaphore and add fine grain
locks to really small number of pernet_operations, what really need them.
Then, pernet_operations::init/::exit methods, modifying the net-related data,
will require down_read() locking only, while down_write() will be used
for changing pernet_list (i.e., when modules are being loaded and unloaded).
This gives signify performance increase, after all patch set is applied,
like you may see here:
%for i in {1..10000}; do unshare -n bash -c exit; done
*before*
real 1m40,377s
user 0m9,672s
sys 0m19,928s
*after*
real 0m17,007s
user 0m5,311s
sys 0m11,779
(5.8 times faster)
This patch starts replacing net_mutex to net_sem. It adds rw_semaphore,
describes the variables it protects, and makes to use, where appropriate.
net_mutex is still present, and next patches will kick it out step-by-step.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13 12:26:23 +03:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
net: Introduce net_sem for protection of pernet_list
Currently, the mutex is mostly used to protect pernet operations
list. It orders setup_net() and cleanup_net() with parallel
{un,}register_pernet_operations() calls, so ->exit{,batch} methods
of the same pernet operations are executed for a dying net, as
were used to call ->init methods, even after the net namespace
is unlinked from net_namespace_list in cleanup_net().
But there are several problems with scalability. The first one
is that more than one net can't be created or destroyed
at the same moment on the node. For big machines with many cpus
running many containers it's very sensitive.
The second one is that it's need to synchronize_rcu() after net
is removed from net_namespace_list():
Destroy net_ns:
cleanup_net()
mutex_lock(&net_mutex)
list_del_rcu(&net->list)
synchronize_rcu() <--- Sleep there for ages
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_exit_list(ops, &net_exit_list)
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_free_list(ops, &net_exit_list)
mutex_unlock(&net_mutex)
This primitive is not fast, especially on the systems with many processors
and/or when preemptible RCU is enabled in config. So, all the time, while
cleanup_net() is waiting for RCU grace period, creation of new net namespaces
is not possible, the tasks, who makes it, are sleeping on the same mutex:
Create net_ns:
copy_net_ns()
mutex_lock_killable(&net_mutex) <--- Sleep there for ages
I observed 20-30 seconds hangs of "unshare -n" on ordinary 8-cpu laptop
with preemptible RCU enabled after CRIU tests round is finished.
The solution is to convert net_mutex to the rw_semaphore and add fine grain
locks to really small number of pernet_operations, what really need them.
Then, pernet_operations::init/::exit methods, modifying the net-related data,
will require down_read() locking only, while down_write() will be used
for changing pernet_list (i.e., when modules are being loaded and unloaded).
This gives signify performance increase, after all patch set is applied,
like you may see here:
%for i in {1..10000}; do unshare -n bash -c exit; done
*before*
real 1m40,377s
user 0m9,672s
sys 0m19,928s
*after*
real 0m17,007s
user 0m5,311s
sys 0m11,779
(5.8 times faster)
This patch starts replacing net_mutex to net_sem. It adds rw_semaphore,
describes the variables it protects, and makes to use, where appropriate.
net_mutex is still present, and next patches will kick it out step-by-step.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13 12:26:23 +03:00
|
|
|
|
2018-03-27 18:02:32 +03:00
|
|
|
|
|
|
|
|
|
net: Introduce net_sem for protection of pernet_list
Currently, the mutex is mostly used to protect pernet operations
list. It orders setup_net() and cleanup_net() with parallel
{un,}register_pernet_operations() calls, so ->exit{,batch} methods
of the same pernet operations are executed for a dying net, as
were used to call ->init methods, even after the net namespace
is unlinked from net_namespace_list in cleanup_net().
But there are several problems with scalability. The first one
is that more than one net can't be created or destroyed
at the same moment on the node. For big machines with many cpus
running many containers it's very sensitive.
The second one is that it's need to synchronize_rcu() after net
is removed from net_namespace_list():
Destroy net_ns:
cleanup_net()
mutex_lock(&net_mutex)
list_del_rcu(&net->list)
synchronize_rcu() <--- Sleep there for ages
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_exit_list(ops, &net_exit_list)
list_for_each_entry_reverse(ops, &pernet_list, list)
ops_free_list(ops, &net_exit_list)
mutex_unlock(&net_mutex)
This primitive is not fast, especially on the systems with many processors
and/or when preemptible RCU is enabled in config. So, all the time, while
cleanup_net() is waiting for RCU grace period, creation of new net namespaces
is not possible, the tasks, who makes it, are sleeping on the same mutex:
Create net_ns:
copy_net_ns()
mutex_lock_killable(&net_mutex) <--- Sleep there for ages
I observed 20-30 seconds hangs of "unshare -n" on ordinary 8-cpu laptop
with preemptible RCU enabled after CRIU tests round is finished.
The solution is to convert net_mutex to the rw_semaphore and add fine grain
locks to really small number of pernet_operations, what really need them.
Then, pernet_operations::init/::exit methods, modifying the net-related data,
will require down_read() locking only, while down_write() will be used
for changing pernet_list (i.e., when modules are being loaded and unloaded).
This gives signify performance increase, after all patch set is applied,
like you may see here:
%for i in {1..10000}; do unshare -n bash -c exit; done
*before*
real 1m40,377s
user 0m9,672s
sys 0m19,928s
*after*
real 0m17,007s
user 0m5,311s
sys 0m11,779
(5.8 times faster)
This patch starts replacing net_mutex to net_sem. It adds rw_semaphore,
describes the variables it protects, and makes to use, where appropriate.
net_mutex is still present, and next patches will kick it out step-by-step.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-13 12:26:23 +03:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2016-08-10 14:36:00 -07:00
|
|
|
|
2016-12-02 04:21:32 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-15 00:36:08 -07:00
|
|
|
|
|
|
|
|
|
2012-01-26 00:41:38 +00:00
|
|
|
|
|
|
|
|
|
2020-09-30 17:18:16 +02:00
|
|
|
|
bpf: Add netns cookie and enable it for bpf cgroup hooks
In Cilium we're mainly using BPF cgroup hooks today in order to implement
kube-proxy free Kubernetes service translation for ClusterIP, NodePort (*),
ExternalIP, and LoadBalancer as well as HostPort mapping [0] for all traffic
between Cilium managed nodes. While this works in its current shape and avoids
packet-level NAT for inter Cilium managed node traffic, there is one major
limitation we're facing today, that is, lack of netns awareness.
In Kubernetes, the concept of Pods (which hold one or multiple containers)
has been built around network namespaces, so while we can use the global scope
of attaching to root BPF cgroup hooks also to our advantage (e.g. for exposing
NodePort ports on loopback addresses), we also have the need to differentiate
between initial network namespaces and non-initial one. For example, ExternalIP
services mandate that non-local service IPs are not to be translated from the
host (initial) network namespace as one example. Right now, we have an ugly
work-around in place where non-local service IPs for ExternalIP services are
not xlated from connect() and friends BPF hooks but instead via less efficient
packet-level NAT on the veth tc ingress hook for Pod traffic.
On top of determining whether we're in initial or non-initial network namespace
we also have a need for a socket-cookie like mechanism for network namespaces
scope. Socket cookies have the nice property that they can be combined as part
of the key structure e.g. for BPF LRU maps without having to worry that the
cookie could be recycled. We are planning to use this for our sessionAffinity
implementation for services. Therefore, add a new bpf_get_netns_cookie() helper
which would resolve both use cases at once: bpf_get_netns_cookie(NULL) would
provide the cookie for the initial network namespace while passing the context
instead of NULL would provide the cookie from the application's network namespace.
We're using a hole, so no size increase; the assignment happens only once.
Therefore this allows for a comparison on initial namespace as well as regular
cookie usage as we have today with socket cookies. We could later on enable
this helper for other program types as well as we would see need.
(*) Both externalTrafficPolicy={Local|Cluster} types
[0] https://github.com/cilium/cilium/blob/master/bpf/bpf_sock.c
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/c47d2346982693a9cf9da0e12690453aded4c788.1585323121.git.daniel@iogearbox.net
2020-03-27 16:58:52 +01:00
|
|
|
|
2012-01-26 00:41:38 +00:00
|
|
|
|
|
|
|
|
|
2024-05-02 10:20:06 -03:00
|
|
|
|
|
|
|
|
|
2012-01-26 00:41:38 +00:00
|
|
|
|
2024-05-02 10:20:06 -03:00
|
|
|
|
|
|
|
|
|
2012-01-26 00:41:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-02 10:20:06 -03:00
|
|
|
|
2012-01-26 00:41:38 +00: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
|
|
|
|
2010-04-23 01:40:47 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-02 04:21:32 +03:00
|
|
|
|
2010-04-23 01:40:47 +00:00
|
|
|
|
2010-10-25 03:20:11 +00:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2016-12-02 04:21:32 +03:00
|
|
|
|
|
|
|
|
|
2016-12-02 04:11:34 +03:00
|
|
|
|
|
|
|
|
|
2010-04-23 01:40:47 +00:00
|
|
|
|
2012-01-26 00:41:38 +00:00
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2010-04-23 01:40:47 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-02 04:21:32 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-23 01:40:47 +00:00
|
|
|
|
|
|
|
|
|
2016-12-02 04:12:58 +03:00
|
|
|
|
2010-04-23 01:40:47 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2022-10-20 10:42:13 +08:00
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:17 -07:00
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:17 -07:00
|
|
|
|
2022-10-20 10:42:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-19 19:55:45 +01:00
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2019-06-18 11:08:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-18 03:43:40 -08:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2022-01-18 03:43:40 -08:00
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:17 -07:00
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-13 22:39:22 +01:00
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:47 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2019-10-09 11:19:10 +02:00
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2020-08-19 14:06:36 +02:00
|
|
|
|
2016-11-16 10:27:02 -08:00
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
|
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-16 12:31:41 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2020-01-13 22:39:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-11-02 17:04:36 -02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
2020-01-16 21:16:46 +01:00
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-13 22:39:22 +01:00
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
2020-01-13 22:39:22 +01:00
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
|
|
|
|
|
2016-09-01 21:53:44 -07:00
|
|
|
|
2015-05-07 11:02:51 +02:00
|
|
|
|
2015-05-07 11:02:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-16 21:16:46 +01:00
|
|
|
|
2015-05-07 11:02:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-16 21:16:46 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: Fix double free and memory corruption in get_net_ns_by_id()
(I can trivially verify that that idr_remove in cleanup_net happens
after the network namespace count has dropped to zero --EWB)
Function get_net_ns_by_id() does not check for net::count
after it has found a peer in netns_ids idr.
It may dereference a peer, after its count has already been
finaly decremented. This leads to double free and memory
corruption:
put_net(peer) rtnl_lock()
atomic_dec_and_test(&peer->count) [count=0] ...
__put_net(peer) get_net_ns_by_id(net, id)
spin_lock(&cleanup_list_lock)
list_add(&net->cleanup_list, &cleanup_list)
spin_unlock(&cleanup_list_lock)
queue_work() peer = idr_find(&net->netns_ids, id)
| get_net(peer) [count=1]
| ...
| (use after final put)
v ...
cleanup_net() ...
spin_lock(&cleanup_list_lock) ...
list_replace_init(&cleanup_list, ..) ...
spin_unlock(&cleanup_list_lock) ...
... ...
... put_net(peer)
... atomic_dec_and_test(&peer->count) [count=0]
... spin_lock(&cleanup_list_lock)
... list_add(&net->cleanup_list, &cleanup_list)
... spin_unlock(&cleanup_list_lock)
... queue_work()
... rtnl_unlock()
rtnl_lock() ...
for_each_net(tmp) { ...
id = __peernet2id(tmp, peer) ...
spin_lock_irq(&tmp->nsid_lock) ...
idr_remove(&tmp->netns_ids, id) ...
... ...
net_drop_ns() ...
net_free(peer) ...
} ...
|
v
cleanup_net()
...
(Second free of peer)
Also, put_net() on the right cpu may reorder with left's cpu
list_replace_init(&cleanup_list, ..), and then cleanup_list
will be corrupted.
Since cleanup_net() is executed in worker thread, while
put_net(peer) can happen everywhere, there should be
enough time for concurrent get_net_ns_by_id() to pick
the peer up, and the race does not seem to be unlikely.
The patch fixes the problem in standard way.
(Also, there is possible problem in peernet2id_alloc(), which requires
check for net::count under nsid_lock and maybe_get_net(peer), but
in current stable kernel it's used under rtnl_lock() and it has to be
safe. Openswitch begun to use peernet2id_alloc(), and possibly it should
be fixed too. While this is not in stable kernel yet, so I'll send
a separate message to netdev@ later).
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Fixes: 0c7aecd4bde4 "netns: add rtnl cmd to add and get peer netns ids"
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-19 11:27:56 -06:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-14 22:09:49 +05:30
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2024-07-31 13:07:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-06 07:26:09 +09:00
|
|
|
|
2024-07-31 13:07:21 -07:00
|
|
|
|
|
|
|
|
|
2023-02-08 18:21:23 +00:00
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
2023-02-08 18:21:23 +00:00
|
|
|
|
2024-07-31 13:07:18 -07:00
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
|
|
|
|
|
2023-06-02 12:21:34 +02:00
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-04 15:10:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:21 -07:00
|
|
|
|
2023-02-08 18:21:23 +00:00
|
|
|
|
|
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2024-02-06 14:42:57 +00:00
|
|
|
|
|
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
2021-02-10 06:41:44 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
2018-02-13 12:26:02 +03:00
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2019-06-18 11:08:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-06 14:42:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-20 19:24:40 +08:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-23 15:37:35 -08:00
|
|
|
|
2016-09-23 18:06:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-24 21:20:33 +03:00
|
|
|
|
2009-02-23 15:37:35 -08:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-26 21:02:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-26 21:02:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2024-12-04 12:54:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-07 01:30:30 -08:00
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
|
|
|
|
|
2022-10-20 23:20:18 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-04 12:54:55 +00:00
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2007-11-07 01:30:30 -08:00
|
|
|
|
|
|
|
|
|
2011-06-08 21:13:01 -04:00
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-08 21:13:01 -04:00
|
|
|
|
|
|
|
|
|
2012-06-14 02:31:10 -07:00
|
|
|
|
|
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
2016-08-08 14:33:23 -05:00
|
|
|
|
2009-05-04 11:12:14 -07:00
|
|
|
|
|
|
|
|
|
2007-11-01 00:44:50 -07:00
|
|
|
|
2011-04-15 02:26:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-08 14:33:23 -05:00
|
|
|
|
|
|
|
|
|
2016-09-22 13:08:36 -05:00
|
|
|
|
2016-08-08 14:33:23 -05:00
|
|
|
|
2009-05-04 11:12:14 -07:00
|
|
|
|
2016-08-08 14:33:23 -05:00
|
|
|
|
2018-02-13 12:26:13 +03:00
|
|
|
|
|
|
|
|
|
2016-08-08 14:33:23 -05:00
|
|
|
|
2023-02-08 18:21:23 +00:00
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
2018-02-13 12:26:13 +03:00
|
|
|
|
2012-06-14 02:31:10 -07:00
|
|
|
|
2018-03-27 18:02:01 +03:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2018-02-13 12:26:13 +03:00
|
|
|
|
|
|
|
|
|
2018-02-19 12:58:38 +03:00
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
2018-02-19 12:58:38 +03:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2018-02-19 12:58:38 +03:00
|
|
|
|
2009-05-04 11:12:14 -07:00
|
|
|
|
2018-02-13 12:26:13 +03:00
|
|
|
|
2021-09-18 17:04:10 +08:00
|
|
|
|
2019-10-19 15:34:43 +09:00
|
|
|
|
2021-09-18 17:04:10 +08:00
|
|
|
|
2012-06-14 02:31:10 -07:00
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2018-02-13 12:26:13 +03:00
|
|
|
|
|
|
|
|
|
2009-05-04 11:12:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
2018-07-20 21:56:53 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
|
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
2018-02-19 12:58:45 +03:00
|
|
|
|
2009-11-29 22:25:27 +00:00
|
|
|
|
2025-01-14 20:55:27 +00:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
2018-02-19 12:58:45 +03:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2024-02-06 14:42:57 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2025-01-14 20:55:27 +00:00
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:27 +00:00
|
|
|
|
2018-02-19 12:58:45 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
2018-02-19 12:58:45 +03:00
|
|
|
|
2009-11-29 22:25:27 +00:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-02-19 12:58:45 +03:00
|
|
|
|
net: Move net:netns_ids destruction out of rtnl_lock() and document locking scheme
Currently, we unhash a dying net from netns_ids lists
under rtnl_lock(). It's a leftover from the time when
net::netns_ids was introduced. There was no net::nsid_lock,
and rtnl_lock() was mostly need to order modification
of alive nets nsid idr, i.e. for:
for_each_net(tmp) {
...
id = __peernet2id(tmp, net);
idr_remove(&tmp->netns_ids, id);
...
}
Since we have net::nsid_lock, the modifications are
protected by this local lock, and now we may introduce
better scheme of netns_ids destruction.
Let's look at the functions peernet2id_alloc() and
get_net_ns_by_id(). Previous commits taught these
functions to work well with dying net acquired from
rtnl unlocked lists. And they are the only functions
which can hash a net to netns_ids or obtain from there.
And as easy to check, other netns_ids operating functions
works with id, not with net pointers. So, we do not
need rtnl_lock to synchronize cleanup_net() with all them.
The another property, which is used in the patch,
is that net is unhashed from net_namespace_list
in the only place and by the only process. So,
we avoid excess rcu_read_lock() or rtnl_lock(),
when we'are iterating over the list in unhash_nsid().
All the above makes possible to keep rtnl_lock() locked
only for net->list deletion, and completely avoid it
for netns_ids unhashing and destruction. As these two
doings may take long time (e.g., memory allocation
to send skb), the patch should positively act on
the scalability and signify decrease the time, which
rtnl_lock() is held in cleanup_net().
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-19 19:14:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-18 11:08:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-10 09:51:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-18 11:08:59 -07:00
|
|
|
|
2009-07-10 09:51:33 +00:00
|
|
|
|
2024-02-09 15:31:00 +00:00
|
|
|
|
2009-07-10 09:51:33 +00:00
|
|
|
|
2024-02-06 14:42:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-04 12:54:55 +00:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
2016-08-08 14:33:23 -05:00
|
|
|
|
2021-09-18 17:04:10 +08:00
|
|
|
|
2019-06-26 21:02:33 +01:00
|
|
|
|
2021-09-18 17:04:10 +08:00
|
|
|
|
2012-06-14 02:31:10 -07:00
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2009-11-29 22:25:27 +00:00
|
|
|
|
2025-01-14 20:55:27 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2017-05-30 11:38:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
|
|
|
|
|
2017-05-30 11:38:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:27 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-09 23:44:21 -08:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-02-19 12:58:54 +03:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-11 22:29:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-14 21:13:02 +08:00
|
|
|
|
2021-06-11 22:29:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-14 21:13:02 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-11 22:29:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-12 13:51:13 +10:00
|
|
|
|
|
|
|
|
|
2024-07-19 20:17:58 -04:00
|
|
|
|
2011-05-12 13:51:13 +10:00
|
|
|
|
2024-07-19 20:17:58 -04:00
|
|
|
|
2022-05-15 18:16:54 -04:00
|
|
|
|
2011-05-12 13:51:13 +10:00
|
|
|
|
2024-05-31 14:12:01 -04:00
|
|
|
|
|
|
|
|
|
2022-05-15 18:16:54 -04:00
|
|
|
|
2024-07-19 20:17:58 -04:00
|
|
|
|
2022-05-15 18:16:54 -04:00
|
|
|
|
2011-05-12 13:51:13 +10:00
|
|
|
|
2024-07-19 20:17:58 -04:00
|
|
|
|
2011-05-12 13:51:13 +10:00
|
|
|
|
2015-01-12 16:34:05 +02:00
|
|
|
|
2021-06-15 07:52:43 +08:00
|
|
|
|
2007-09-26 22:04:26 -07:00
|
|
|
|
2009-07-10 09:51:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-03 19:13:49 -08:00
|
|
|
|
|
|
|
|
|
2009-07-10 09:51:35 +00:00
|
|
|
|
|
|
|
|
|
2014-02-03 19:13:49 -08:00
|
|
|
|
2009-07-10 09:51:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:21:48 -07:00
|
|
|
|
|
|
|
|
|
2014-11-01 02:32:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-01 00:45:45 -04:00
|
|
|
|
2011-06-15 10:21:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-01 00:45:45 -04:00
|
|
|
|
2011-06-15 10:21:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-31 15:17:49 -07:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2017-04-16 09:48:24 -07:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netlink: make validation more configurable for future strictness
We currently have two levels of strict validation:
1) liberal (default)
- undefined (type >= max) & NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
- garbage at end of message accepted
2) strict (opt-in)
- NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
Split out parsing strictness into four different options:
* TRAILING - check that there's no trailing data after parsing
attributes (in message or nested)
* MAXTYPE - reject attrs > max known type
* UNSPEC - reject attributes with NLA_UNSPEC policy entries
* STRICT_ATTRS - strictly validate attribute size
The default for future things should be *everything*.
The current *_strict() is a combination of TRAILING and MAXTYPE,
and is renamed to _deprecated_strict().
The current regular parsing has none of this, and is renamed to
*_parse_deprecated().
Additionally it allows us to selectively set one of the new flags
even on old policies. Notably, the UNSPEC flag could be useful in
this case, since it can be arranged (by filling in the policy) to
not be an incompatible userspace ABI change, but would then going
forward prevent forgetting attribute entries. Similar can apply
to the POLICY flag.
We end up with the following renames:
* nla_parse -> nla_parse_deprecated
* nla_parse_strict -> nla_parse_deprecated_strict
* nlmsg_parse -> nlmsg_parse_deprecated
* nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
* nla_parse_nested -> nla_parse_nested_deprecated
* nla_validate_nested -> nla_validate_nested_deprecated
Using spatch, of course:
@@
expression TB, MAX, HEAD, LEN, POL, EXT;
@@
-nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
+nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression TB, MAX, NLA, POL, EXT;
@@
-nla_parse_nested(TB, MAX, NLA, POL, EXT)
+nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
@@
expression START, MAX, POL, EXT;
@@
-nla_validate_nested(START, MAX, POL, EXT)
+nla_validate_nested_deprecated(START, MAX, POL, EXT)
@@
expression NLH, HDRLEN, MAX, POL, EXT;
@@
-nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
+nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
For this patch, don't actually add the strict, non-renamed versions
yet so that it breaks compile if I get it wrong.
Also, while at it, make nla_validate and nla_parse go down to a
common __nla_validate_parse() function to avoid code duplication.
Ultimately, this allows us to have very strict validation for every
new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
next patch, while existing things will continue to work as is.
In effect then, this adds fully strict validation for any new command.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-26 14:07:28 +02:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-07 15:54:41 +00:00
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2019-10-09 11:19:10 +02:00
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2017-06-09 14:41:57 +02:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
2015-05-07 11:02:50 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-18 10:46:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netlink: make validation more configurable for future strictness
We currently have two levels of strict validation:
1) liberal (default)
- undefined (type >= max) & NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
- garbage at end of message accepted
2) strict (opt-in)
- NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
Split out parsing strictness into four different options:
* TRAILING - check that there's no trailing data after parsing
attributes (in message or nested)
* MAXTYPE - reject attrs > max known type
* UNSPEC - reject attributes with NLA_UNSPEC policy entries
* STRICT_ATTRS - strictly validate attribute size
The default for future things should be *everything*.
The current *_strict() is a combination of TRAILING and MAXTYPE,
and is renamed to _deprecated_strict().
The current regular parsing has none of this, and is renamed to
*_parse_deprecated().
Additionally it allows us to selectively set one of the new flags
even on old policies. Notably, the UNSPEC flag could be useful in
this case, since it can be arranged (by filling in the policy) to
not be an incompatible userspace ABI change, but would then going
forward prevent forgetting attribute entries. Similar can apply
to the POLICY flag.
We end up with the following renames:
* nla_parse -> nla_parse_deprecated
* nla_parse_strict -> nla_parse_deprecated_strict
* nlmsg_parse -> nlmsg_parse_deprecated
* nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
* nla_parse_nested -> nla_parse_nested_deprecated
* nla_validate_nested -> nla_validate_nested_deprecated
Using spatch, of course:
@@
expression TB, MAX, HEAD, LEN, POL, EXT;
@@
-nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
+nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression TB, MAX, NLA, POL, EXT;
@@
-nla_parse_nested(TB, MAX, NLA, POL, EXT)
+nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
@@
expression START, MAX, POL, EXT;
@@
-nla_validate_nested(START, MAX, POL, EXT)
+nla_validate_nested_deprecated(START, MAX, POL, EXT)
@@
expression NLH, HDRLEN, MAX, POL, EXT;
@@
-nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
+nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
For this patch, don't actually add the strict, non-renamed versions
yet so that it breaks compile if I get it wrong.
Also, while at it, make nla_validate and nla_parse go down to a
common __nla_validate_parse() function to avoid code duplication.
Ultimately, this allows us to have very strict validation for every
new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
next patch, while existing things will continue to work as is.
In effect then, this adds fully strict validation for any new command.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-26 14:07:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-18 10:46:17 -08:00
|
|
|
|
netlink: make validation more configurable for future strictness
We currently have two levels of strict validation:
1) liberal (default)
- undefined (type >= max) & NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
- garbage at end of message accepted
2) strict (opt-in)
- NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
Split out parsing strictness into four different options:
* TRAILING - check that there's no trailing data after parsing
attributes (in message or nested)
* MAXTYPE - reject attrs > max known type
* UNSPEC - reject attributes with NLA_UNSPEC policy entries
* STRICT_ATTRS - strictly validate attribute size
The default for future things should be *everything*.
The current *_strict() is a combination of TRAILING and MAXTYPE,
and is renamed to _deprecated_strict().
The current regular parsing has none of this, and is renamed to
*_parse_deprecated().
Additionally it allows us to selectively set one of the new flags
even on old policies. Notably, the UNSPEC flag could be useful in
this case, since it can be arranged (by filling in the policy) to
not be an incompatible userspace ABI change, but would then going
forward prevent forgetting attribute entries. Similar can apply
to the POLICY flag.
We end up with the following renames:
* nla_parse -> nla_parse_deprecated
* nla_parse_strict -> nla_parse_deprecated_strict
* nlmsg_parse -> nlmsg_parse_deprecated
* nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
* nla_parse_nested -> nla_parse_nested_deprecated
* nla_validate_nested -> nla_validate_nested_deprecated
Using spatch, of course:
@@
expression TB, MAX, HEAD, LEN, POL, EXT;
@@
-nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
+nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression TB, MAX, NLA, POL, EXT;
@@
-nla_parse_nested(TB, MAX, NLA, POL, EXT)
+nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
@@
expression START, MAX, POL, EXT;
@@
-nla_validate_nested(START, MAX, POL, EXT)
+nla_validate_nested_deprecated(START, MAX, POL, EXT)
@@
expression NLH, HDRLEN, MAX, POL, EXT;
@@
-nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
+nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
For this patch, don't actually add the strict, non-renamed versions
yet so that it breaks compile if I get it wrong.
Also, while at it, make nla_validate and nla_parse go down to a
common __nla_validate_parse() function to avoid code duplication.
Ultimately, this allows us to have very strict validation for every
new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
next patch, while existing things will continue to work as is.
In effect then, this adds fully strict validation for any new command.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-26 14:07:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-18 10:46:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-16 09:48:24 -07:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2019-01-18 10:46:17 -08:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2018-11-26 15:42:05 +01:00
|
|
|
|
2019-04-11 16:45:57 +02:00
|
|
|
|
2018-11-26 15:42:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2017-06-09 14:41:56 +02:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
|
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2015-01-15 15:11:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-13 22:39:22 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netlink: make validation more configurable for future strictness
We currently have two levels of strict validation:
1) liberal (default)
- undefined (type >= max) & NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
- garbage at end of message accepted
2) strict (opt-in)
- NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
Split out parsing strictness into four different options:
* TRAILING - check that there's no trailing data after parsing
attributes (in message or nested)
* MAXTYPE - reject attrs > max known type
* UNSPEC - reject attributes with NLA_UNSPEC policy entries
* STRICT_ATTRS - strictly validate attribute size
The default for future things should be *everything*.
The current *_strict() is a combination of TRAILING and MAXTYPE,
and is renamed to _deprecated_strict().
The current regular parsing has none of this, and is renamed to
*_parse_deprecated().
Additionally it allows us to selectively set one of the new flags
even on old policies. Notably, the UNSPEC flag could be useful in
this case, since it can be arranged (by filling in the policy) to
not be an incompatible userspace ABI change, but would then going
forward prevent forgetting attribute entries. Similar can apply
to the POLICY flag.
We end up with the following renames:
* nla_parse -> nla_parse_deprecated
* nla_parse_strict -> nla_parse_deprecated_strict
* nlmsg_parse -> nlmsg_parse_deprecated
* nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
* nla_parse_nested -> nla_parse_nested_deprecated
* nla_validate_nested -> nla_validate_nested_deprecated
Using spatch, of course:
@@
expression TB, MAX, HEAD, LEN, POL, EXT;
@@
-nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
+nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression TB, MAX, NLA, POL, EXT;
@@
-nla_parse_nested(TB, MAX, NLA, POL, EXT)
+nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
@@
expression START, MAX, POL, EXT;
@@
-nla_validate_nested(START, MAX, POL, EXT)
+nla_validate_nested_deprecated(START, MAX, POL, EXT)
@@
expression NLH, HDRLEN, MAX, POL, EXT;
@@
-nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
+nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
For this patch, don't actually add the strict, non-renamed versions
yet so that it breaks compile if I get it wrong.
Also, while at it, make nla_validate and nla_parse go down to a
common __nla_validate_parse() function to avoid code duplication.
Ultimately, this allows us to have very strict validation for every
new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
next patch, while existing things will continue to work as is.
In effect then, this adds fully strict validation for any new command.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-26 14:07:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-07 20:16:38 -07:00
|
|
|
|
|
|
|
|
|
2020-01-13 22:39:22 +01:00
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2020-01-13 22:39:22 +01:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2018-11-26 15:42:06 +01:00
|
|
|
|
2018-11-26 15:42:04 +01:00
|
|
|
|
2024-04-16 14:07:39 +00:00
|
|
|
|
2015-04-07 11:51:54 +02:00
|
|
|
|
|
|
|
|
|
2019-10-09 11:19:10 +02:00
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
2015-04-07 11:51:53 +02:00
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2019-10-09 11:19:10 +02:00
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-07 11:51:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
2015-04-07 11:51:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-26 15:42:03 +01:00
|
|
|
|
2015-04-07 11:51:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
netns: fix GFP flags in rtnl_net_notifyid()
In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
but there are a few paths calling rtnl_net_notifyid() from atomic
context or from RCU critical sections. The later also precludes the use
of gfp_any() as it wouldn't detect the RCU case. Also, the nlmsg_new()
call is wrong too, as it uses GFP_KERNEL unconditionally.
Therefore, we need to pass the GFP flags as parameter and propagate it
through function calls until the proper flags can be determined.
In most cases, GFP_KERNEL is fine. The exceptions are:
* openvswitch: ovs_vport_cmd_get() and ovs_vport_cmd_dump()
indirectly call rtnl_net_notifyid() from RCU critical section,
* rtnetlink: rtmsg_ifinfo_build_skb() already receives GFP flags as
parameter.
Also, in ovs_vport_cmd_build_info(), let's change the GFP flags used
by nlmsg_new(). The function is allowed to sleep, so better make the
flags consistent with the ones used in the following
ovs_vport_cmd_fill_info() call.
Found by code inspection.
Fixes: 9a9634545c70 ("netns: notify netns id events")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-23 18:39:04 +02:00
|
|
|
|
2015-04-07 11:51:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-29 07:27:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-10 03:41:00 +00:00
|
|
|
|
|
|
|
|
|
2023-11-29 07:27:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-10 03:41:00 +00:00
|
|
|
|
2023-11-29 07:27:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-14 13:18:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-05 09:01:25 -08:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2007-11-01 00:46:50 -07:00
|
|
|
|
2023-11-29 07:27:54 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2018-03-01 15:23:28 +03:00
|
|
|
|
2007-11-19 23:18:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-01 00:46:50 -07:00
|
|
|
|
2007-11-19 23:18:16 -08:00
|
|
|
|
2009-02-22 00:07:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-30 17:18:16 +02:00
|
|
|
|
2022-02-05 09:01:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
2024-07-31 13:07:19 -07:00
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:20 -07:00
|
|
|
|
2009-05-21 15:10:31 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2016-08-10 14:36:00 -07:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-12-23 19:42:38 -06:00
|
|
|
|
|
|
|
|
|
2011-06-15 10:21:48 -07:00
|
|
|
|
2024-10-14 13:18:22 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-06 14:42:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2024-02-06 14:42:57 +00:00
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-13 03:23:21 -08:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:17 -07:00
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-01 00:42:43 -07:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2007-11-01 00:42:43 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2007-11-01 00:42:43 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
net: Introduce net_rwsem to protect net_namespace_list
rtnl_lock() is used everywhere, and contention is very high.
When someone wants to iterate over alive net namespaces,
he/she has no a possibility to do that without exclusive lock.
But the exclusive rtnl_lock() in such places is overkill,
and it just increases the contention. Yes, there is already
for_each_net_rcu() in kernel, but it requires rcu_read_lock(),
and this can't be sleepable. Also, sometimes it may be need
really prevent net_namespace_list growth, so for_each_net_rcu()
is not fit there.
This patch introduces new rw_semaphore, which will be used
instead of rtnl_mutex to protect net_namespace_list. It is
sleepable and allows not-exclusive iterations over net
namespaces list. It allows to stop using rtnl_lock()
in several places (what is made in next patches) and makes
less the time, we keep rtnl_mutex. Here we just add new lock,
while the explanation of we can remove rtnl_lock() there are
in next patches.
Fine grained locks generally are better, then one big lock,
so let's do that with net_namespace_list, while the situation
allows that.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-29 19:20:32 +03:00
|
|
|
|
2009-12-03 02:29:03 +00:00
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
|
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2007-11-13 03:23:21 -08:00
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-10 14:36:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-16 04:43:15 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-10 14:36:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-17 23:23:00 +08:00
|
|
|
|
2016-08-10 14:36:00 -07:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-13 03:23:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2024-07-31 13:07:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2018-06-17 05:37:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2018-06-17 05:37:08 -04:00
|
|
|
|
2024-05-02 10:20:06 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2009-12-03 02:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-17 05:37:08 -04:00
|
|
|
|
2009-12-03 02:29:06 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
|
|
|
|
|
2007-11-13 03:23:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2009-12-03 02:29:06 +00:00
|
|
|
|
2009-11-29 22:25:28 +00:00
|
|
|
|
2018-06-17 05:37:08 -04:00
|
|
|
|
2007-11-13 03:23:21 -08:00
|
|
|
|
2008-04-15 00:35:23 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 17:56:48 +02:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-25 00:49:56 -07:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2010-04-25 00:49:56 -07:00
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 17:56:48 +02:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-27 18:02:23 +03:00
|
|
|
|
2007-09-12 11:50:50 +02:00
|
|
|
|
|
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
|
|
|
|
|
2014-11-01 00:37:32 -04:00
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
2011-05-04 17:51:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-03 19:13:49 -08:00
|
|
|
|
|
|
|
|
|
2011-05-04 17:51:50 -07:00
|
|
|
|
|
|
|
|
|
2014-02-03 19:13:49 -08:00
|
|
|
|
2011-05-04 17:51:50 -07:00
|
|
|
|
2014-11-01 00:10:50 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
|
|
|
|
|
2014-11-01 00:37:32 -04:00
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
2014-11-01 00:10:50 -04:00
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
|
|
|
|
|
2020-05-05 16:04:30 +02:00
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
2020-05-05 16:04:30 +02:00
|
|
|
|
2014-11-01 00:10:50 -04:00
|
|
|
|
2012-07-26 01:13:20 -07:00
|
|
|
|
2012-12-14 07:55:36 -08:00
|
|
|
|
2020-05-05 16:04:30 +02:00
|
|
|
|
2012-07-26 01:13:20 -07:00
|
|
|
|
|
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
2012-07-26 01:13:20 -07:00
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-06 00:47:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-06 00:47:13 -07:00
|
|
|
|
2010-03-07 18:14:23 -08:00
|
|
|
|
|
|
|
|
|
