2019-05-29 07:12:43 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-06 16:48:38 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2022-02-03 10:44:30 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-21 09:31:04 -08:00
|
|
|
|
2013-10-03 18:16:47 -07:00
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
2021-06-22 10:02:33 -04:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-29 13:06:41 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
netns: make struct pernet_operations::id unsigned int
Make struct pernet_operations::id unsigned.
There are 2 reasons to do so:
1)
This field is really an index into an zero based array and
thus is unsigned entity. Using negative value is out-of-bound
access by definition.
2)
On x86_64 unsigned 32-bit data which are mixed with pointers
via array indexing or offsets added or subtracted to pointers
are preffered to signed 32-bit data.
"int" being used as an array index needs to be sign-extended
to 64-bit before being used.
void f(long *p, int i)
{
g(p[i]);
}
roughly translates to
movsx rsi, esi
mov rdi, [rsi+...]
call g
MOVSX is 3 byte instruction which isn't necessary if the variable is
unsigned because x86_64 is zero extending by default.
Now, there is net_generic() function which, you guessed it right, uses
"int" as an array index:
static inline void *net_generic(const struct net *net, int id)
{
...
ptr = ng->ptr[id - 1];
...
}
And this function is used a lot, so those sign extensions add up.
Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
messing with code generation):
add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
Unfortunately some functions actually grow bigger.
This is a semmingly random artefact of code generation with register
allocator being used differently. gcc decides that some variable
needs to live in new r8+ registers and every access now requires REX
prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
used which is longer than [r8]
However, overall balance is in negative direction:
add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
function old new delta
nfsd4_lock 3886 3959 +73
tipc_link_build_proto_msg 1096 1140 +44
mac80211_hwsim_new_radio 2776 2808 +32
tipc_mon_rcv 1032 1058 +26
svcauth_gss_legacy_init 1413 1429 +16
tipc_bcbase_select_primary 379 392 +13
nfsd4_exchange_id 1247 1260 +13
nfsd4_setclientid_confirm 782 793 +11
...
put_client_renew_locked 494 480 -14
ip_set_sockfn_get 730 716 -14
geneve_sock_add 829 813 -16
nfsd4_sequence_done 721 703 -18
nlmclnt_lookup_host 708 686 -22
nfsd4_lockt 1085 1063 -22
nfs_get_client 1077 1050 -27
tcf_bpf_init 1106 1076 -30
nfsd4_encode_fattr 5997 5930 -67
Total: Before=154856051, After=154854321, chg -0.00%
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-17 04:58:21 +03:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-07-16 11:25:52 -07:00
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2014-07-16 11:25:52 -07:00
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2014-07-16 11:25:52 -07:00
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
|
|
|
|
|
2014-09-18 10:31:04 +02:00
|
|
|
|
|
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
|
|
|
|
|
2014-12-22 18:56:36 +01:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
|
|
|
|
|
2013-11-19 15:19:38 +01:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2013-03-29 14:46:50 +01:00
|
|
|
|
2015-09-22 18:56:43 +02:00
|
|
|
|
2013-03-29 14:46:50 +01:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-12-13 15:22:20 +01:00
|
|
|
|
2014-11-06 06:57:27 -08:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:20 +01:00
|
|
|
|
2014-11-06 06:57:27 -08:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2020-07-15 14:09:28 +02:00
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-09-15 19:37:25 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2015-07-21 10:44:05 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-11-06 06:58:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-07-21 10:44:04 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 18:41:20 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
2021-07-23 10:24:14 -04:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 11:32:17 -07:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-19 01:28:02 +05:30
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-15 19:28:44 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-09-15 19:20:31 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-10-06 05:45:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2020-07-31 14:20:56 +02:00
|
|
|
|
2019-08-04 19:56:11 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-11-13 09:52:25 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2019-11-01 22:23:45 +08:00
|
|
|
|
2020-07-31 14:20:56 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-26 20:59:43 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
2021-07-23 10:24:13 -04:00
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2022-08-17 11:06:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-03 17:43:45 +08:00
|
|
|
|
2022-08-17 11:06:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 05:45:32 -07:00
|
|
|
|
|
|
|
|
|
2019-08-04 19:56:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-29 17:22:21 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-14 15:10:46 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2020-07-31 14:20:56 +02:00
|
|
|
|
2014-02-14 15:10:46 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-06 06:57:27 -08:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-22 10:02:33 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-13 09:52:25 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-02-14 15:10:46 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-02-14 15:10:46 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:20 +01:00
|
|
|
|
2014-11-06 06:57:27 -08:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2017-11-25 13:14:40 -06:00
|
|
|
|
net: accept UFO datagrams from tuntap and packet
Tuntap and similar devices can inject GSO packets. Accept type
VIRTIO_NET_HDR_GSO_UDP, even though not generating UFO natively.
Processes are expected to use feature negotiation such as TUNSETOFFLOAD
to detect supported offload types and refrain from injecting other
packets. This process breaks down with live migration: guest kernels
do not renegotiate flags, so destination hosts need to expose all
features that the source host does.
Partially revert the UFO removal from 182e0b6b5846~1..d9d30adf5677.
This patch introduces nearly(*) no new code to simplify verification.
It brings back verbatim tuntap UFO negotiation, VIRTIO_NET_HDR_GSO_UDP
insertion and software UFO segmentation.
It does not reinstate protocol stack support, hardware offload
(NETIF_F_UFO), SKB_GSO_UDP tunneling in SKB_GSO_SOFTWARE or reception
of VIRTIO_NET_HDR_GSO_UDP packets in tuntap.
To support SKB_GSO_UDP reappearing in the stack, also reinstate
logic in act_csum and openvswitch. Achieve equivalence with v4.13 HEAD
by squashing in commit 939912216fa8 ("net: skb_needs_check() removes
CHECKSUM_UNNECESSARY check for tx.") and reverting commit 8d63bee643f1
("net: avoid skb_warn_bad_offload false positives on UFO").
(*) To avoid having to bring back skb_shinfo(skb)->ip6_frag_id,
ipv6_proxy_select_ident is changed to return a __be32 and this is
assigned directly to the frag_hdr. Also, SKB_GSO_UDP is inserted
at the end of the enum to minimize code churn.
Tested
Booted a v4.13 guest kernel with QEMU. On a host kernel before this
patch `ethtool -k eth0` shows UFO disabled. After the patch, it is
enabled, same as on a v4.13 host kernel.
A UFO packet sent from the guest appears on the tap device:
host:
nc -l -p -u 8000 &
tcpdump -n -i tap0
guest:
dd if=/dev/zero of=payload.txt bs=1 count=2000
nc -u 192.16.1.1 8000 < payload.txt
Direct tap to tap transmission of VIRTIO_NET_HDR_GSO_UDP succeeds,
packets arriving fragmented:
./with_tap_pair.sh ./tap_send_ufo tap0 tap1
(from https://github.com/wdebruij/kerneltools/tree/master/tests)
Changes
v1 -> v2
- simplified set_offload change (review comment)
- documented test procedure
Link: http://lkml.kernel.org/r/<CAF=yD-LuUeDuL9YWPJD9ykOZ0QCjNeznPDr6whqZ9NGMNF12Mw@mail.gmail.com>
Fixes: fb652fdfe837 ("macvlan/macvtap: Remove NETIF_F_UFO advertisement.")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-21 10:22:25 -05:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 15:33:14 +08:00
|
|
|
|
2013-12-13 15:22:22 +01:00
|
|
|
|
2012-07-20 14:46:29 -07:00
|
|
|
|
|
|
|
|
|
2014-10-20 13:49:17 +02:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
net: accept UFO datagrams from tuntap and packet
Tuntap and similar devices can inject GSO packets. Accept type
VIRTIO_NET_HDR_GSO_UDP, even though not generating UFO natively.
Processes are expected to use feature negotiation such as TUNSETOFFLOAD
to detect supported offload types and refrain from injecting other
packets. This process breaks down with live migration: guest kernels
do not renegotiate flags, so destination hosts need to expose all
features that the source host does.
Partially revert the UFO removal from 182e0b6b5846~1..d9d30adf5677.
This patch introduces nearly(*) no new code to simplify verification.
It brings back verbatim tuntap UFO negotiation, VIRTIO_NET_HDR_GSO_UDP
insertion and software UFO segmentation.
It does not reinstate protocol stack support, hardware offload
(NETIF_F_UFO), SKB_GSO_UDP tunneling in SKB_GSO_SOFTWARE or reception
of VIRTIO_NET_HDR_GSO_UDP packets in tuntap.
To support SKB_GSO_UDP reappearing in the stack, also reinstate
logic in act_csum and openvswitch. Achieve equivalence with v4.13 HEAD
by squashing in commit 939912216fa8 ("net: skb_needs_check() removes
CHECKSUM_UNNECESSARY check for tx.") and reverting commit 8d63bee643f1
("net: avoid skb_warn_bad_offload false positives on UFO").
(*) To avoid having to bring back skb_shinfo(skb)->ip6_frag_id,
ipv6_proxy_select_ident is changed to return a __be32 and this is
assigned directly to the frag_hdr. Also, SKB_GSO_UDP is inserted
at the end of the enum to minimize code churn.
Tested
Booted a v4.13 guest kernel with QEMU. On a host kernel before this
patch `ethtool -k eth0` shows UFO disabled. After the patch, it is
enabled, same as on a v4.13 host kernel.
A UFO packet sent from the guest appears on the tap device:
host:
nc -l -p -u 8000 &
tcpdump -n -i tap0
guest:
dd if=/dev/zero of=payload.txt bs=1 count=2000
nc -u 192.16.1.1 8000 < payload.txt
Direct tap to tap transmission of VIRTIO_NET_HDR_GSO_UDP succeeds,
packets arriving fragmented:
./with_tap_pair.sh ./tap_send_ufo tap0 tap1
(from https://github.com/wdebruij/kerneltools/tree/master/tests)
Changes
v1 -> v2
- simplified set_offload change (review comment)
- documented test procedure
Link: http://lkml.kernel.org/r/<CAF=yD-LuUeDuL9YWPJD9ykOZ0QCjNeznPDr6whqZ9NGMNF12Mw@mail.gmail.com>
Fixes: fb652fdfe837 ("macvlan/macvtap: Remove NETIF_F_UFO advertisement.")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-21 10:22:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2020-01-13 18:42:29 -05:00
|
|
|
|
net: accept UFO datagrams from tuntap and packet
Tuntap and similar devices can inject GSO packets. Accept type
VIRTIO_NET_HDR_GSO_UDP, even though not generating UFO natively.
Processes are expected to use feature negotiation such as TUNSETOFFLOAD
to detect supported offload types and refrain from injecting other
packets. This process breaks down with live migration: guest kernels
do not renegotiate flags, so destination hosts need to expose all
features that the source host does.
Partially revert the UFO removal from 182e0b6b5846~1..d9d30adf5677.
This patch introduces nearly(*) no new code to simplify verification.
It brings back verbatim tuntap UFO negotiation, VIRTIO_NET_HDR_GSO_UDP
insertion and software UFO segmentation.
It does not reinstate protocol stack support, hardware offload
(NETIF_F_UFO), SKB_GSO_UDP tunneling in SKB_GSO_SOFTWARE or reception
of VIRTIO_NET_HDR_GSO_UDP packets in tuntap.
To support SKB_GSO_UDP reappearing in the stack, also reinstate
logic in act_csum and openvswitch. Achieve equivalence with v4.13 HEAD
by squashing in commit 939912216fa8 ("net: skb_needs_check() removes
CHECKSUM_UNNECESSARY check for tx.") and reverting commit 8d63bee643f1
("net: avoid skb_warn_bad_offload false positives on UFO").
(*) To avoid having to bring back skb_shinfo(skb)->ip6_frag_id,
ipv6_proxy_select_ident is changed to return a __be32 and this is
assigned directly to the frag_hdr. Also, SKB_GSO_UDP is inserted
at the end of the enum to minimize code churn.
Tested
Booted a v4.13 guest kernel with QEMU. On a host kernel before this
patch `ethtool -k eth0` shows UFO disabled. After the patch, it is
enabled, same as on a v4.13 host kernel.
A UFO packet sent from the guest appears on the tap device:
host:
nc -l -p -u 8000 &
tcpdump -n -i tap0
guest:
dd if=/dev/zero of=payload.txt bs=1 count=2000
nc -u 192.16.1.1 8000 < payload.txt
Direct tap to tap transmission of VIRTIO_NET_HDR_GSO_UDP succeeds,
packets arriving fragmented:
./with_tap_pair.sh ./tap_send_ufo tap0 tap1
(from https://github.com/wdebruij/kerneltools/tree/master/tests)
Changes
v1 -> v2
- simplified set_offload change (review comment)
- documented test procedure
Link: http://lkml.kernel.org/r/<CAF=yD-LuUeDuL9YWPJD9ykOZ0QCjNeznPDr6whqZ9NGMNF12Mw@mail.gmail.com>
Fixes: fb652fdfe837 ("macvlan/macvtap: Remove NETIF_F_UFO advertisement.")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-21 10:22:25 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-13 18:42:29 -05:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2020-01-13 18:42:29 -05:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-13 18:42:29 -05:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-06 06:51:24 -08:00
|
|
|
|
openvswitch: fix skb_panic due to the incorrect actions attrlen
For sw_flow_actions, the actions_len only represents the kernel part's
size, and when we dump the actions to the userspace, we will do the
convertions, so it's true size may become bigger than the actions_len.
But unfortunately, for OVS_PACKET_ATTR_ACTIONS, we use the actions_len
to alloc the skbuff, so the user_skb's size may become insufficient and
oops will happen like this:
skbuff: skb_over_panic: text:ffffffff8148fabf len:1749 put:157 head:
ffff881300f39000 data:ffff881300f39000 tail:0x6d5 end:0x6c0 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:129!
[...]
Call Trace:
<IRQ>
[<ffffffff8148be82>] skb_put+0x43/0x44
[<ffffffff8148fabf>] skb_zerocopy+0x6c/0x1f4
[<ffffffffa0290d36>] queue_userspace_packet+0x3a3/0x448 [openvswitch]
[<ffffffffa0292023>] ovs_dp_upcall+0x30/0x5c [openvswitch]
[<ffffffffa028d435>] output_userspace+0x132/0x158 [openvswitch]
[<ffffffffa01e6890>] ? ip6_rcv_finish+0x74/0x77 [ipv6]
[<ffffffffa028e277>] do_execute_actions+0xcc1/0xdc8 [openvswitch]
[<ffffffffa028e3f2>] ovs_execute_actions+0x74/0x106 [openvswitch]
[<ffffffffa0292130>] ovs_dp_process_packet+0xe1/0xfd [openvswitch]
[<ffffffffa0292b77>] ? key_extract+0x63c/0x8d5 [openvswitch]
[<ffffffffa029848b>] ovs_vport_receive+0xa1/0xc3 [openvswitch]
[...]
Also we can find that the actions_len is much little than the orig_len:
crash> struct sw_flow_actions 0xffff8812f539d000
struct sw_flow_actions {
rcu = {
next = 0xffff8812f5398800,
func = 0xffffe3b00035db32
},
orig_len = 1384,
actions_len = 592,
actions = 0xffff8812f539d01c
}
So as a quick fix, use the orig_len instead of the actions_len to alloc
the user_skb.
Last, this oops happened on our system running a relative old kernel, but
the same risk still exists on the mainline, since we use the wrong
actions_len from the beginning.
Fixes: ccea74457bbd ("openvswitch: include datapath actions with sampled-packet upcall to userspace")
Cc: Neil McKee <neil.mckee@inmon.com>
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-08-16 13:30:07 +08:00
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
2016-06-20 07:26:17 -07:00
|
|
|
|
net: openvswitch: add hash info to upcall
When using the kernel datapath, the upcall don't
include skb hash info relatived. That will introduce
some problem, because the hash of skb is important
in kernel stack. For example, VXLAN module uses
it to select UDP src port. The tx queue selection
may also use the hash in stack.
Hash is computed in different ways. Hash is random
for a TCP socket, and hash may be computed in hardware,
or software stack. Recalculation hash is not easy.
Hash of TCP socket is computed:
tcp_v4_connect
-> sk_set_txhash (is random)
__tcp_transmit_skb
-> skb_set_hash_from_sk
There will be one upcall, without information of skb
hash, to ovs-vswitchd, for the first packet of a TCP
session. The rest packets will be processed in Open vSwitch
modules, hash kept. If this tcp session is forward to
VXLAN module, then the UDP src port of first tcp packet
is different from rest packets.
TCP packets may come from the host or dockers, to Open vSwitch.
To fix it, we store the hash info to upcall, and restore hash
when packets sent back.
+---------------+ +-------------------------+
| Docker/VMs | | ovs-vswitchd |
+----+----------+ +-+--------------------+--+
| ^ |
| | |
| | upcall v restore packet hash (not recalculate)
| +-+--------------------+--+
| tap netdev | | vxlan module
+---------------> +--> Open vSwitch ko +-->
or internal type | |
+-------------------------+
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-13 23:04:49 +08:00
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
|
|
|
|
|
2014-11-06 06:51:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
2015-05-26 20:59:43 -07:00
|
|
|
|
|
|
|
|
|
openvswitch: fix skb_panic due to the incorrect actions attrlen
For sw_flow_actions, the actions_len only represents the kernel part's
size, and when we dump the actions to the userspace, we will do the
convertions, so it's true size may become bigger than the actions_len.
But unfortunately, for OVS_PACKET_ATTR_ACTIONS, we use the actions_len
to alloc the skbuff, so the user_skb's size may become insufficient and
oops will happen like this:
skbuff: skb_over_panic: text:ffffffff8148fabf len:1749 put:157 head:
ffff881300f39000 data:ffff881300f39000 tail:0x6d5 end:0x6c0 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:129!
[...]
Call Trace:
<IRQ>
[<ffffffff8148be82>] skb_put+0x43/0x44
[<ffffffff8148fabf>] skb_zerocopy+0x6c/0x1f4
[<ffffffffa0290d36>] queue_userspace_packet+0x3a3/0x448 [openvswitch]
[<ffffffffa0292023>] ovs_dp_upcall+0x30/0x5c [openvswitch]
[<ffffffffa028d435>] output_userspace+0x132/0x158 [openvswitch]
[<ffffffffa01e6890>] ? ip6_rcv_finish+0x74/0x77 [ipv6]
[<ffffffffa028e277>] do_execute_actions+0xcc1/0xdc8 [openvswitch]
[<ffffffffa028e3f2>] ovs_execute_actions+0x74/0x106 [openvswitch]
[<ffffffffa0292130>] ovs_dp_process_packet+0xe1/0xfd [openvswitch]
[<ffffffffa0292b77>] ? key_extract+0x63c/0x8d5 [openvswitch]
[<ffffffffa029848b>] ovs_vport_receive+0xa1/0xc3 [openvswitch]
[...]
Also we can find that the actions_len is much little than the orig_len:
crash> struct sw_flow_actions 0xffff8812f539d000
struct sw_flow_actions {
rcu = {
next = 0xffff8812f5398800,
func = 0xffffe3b00035db32
},
orig_len = 1384,
actions_len = 592,
actions = 0xffff8812f539d01c
}
So as a quick fix, use the orig_len instead of the actions_len to alloc
the user_skb.
Last, this oops happened on our system running a relative old kernel, but
the same risk still exists on the mainline, since we use the wrong
actions_len from the beginning.
Fixes: ccea74457bbd ("openvswitch: include datapath actions with sampled-packet upcall to userspace")
Cc: Neil McKee <neil.mckee@inmon.com>
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-08-16 13:30:07 +08:00
|
|
|
|
2015-05-26 20:59:43 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: convert many more places to skb_put_zero()
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_zero(skb, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_zero(skb, len);
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, len);
|
-memset(p, 0, len);
)
@@
type t, t2;
identifier p, p2;
expression skb;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, sizeof(*p));
|
-memset(p, 0, sizeof(*p));
)
@@
expression skb, len;
@@
-memset(skb_put(skb, len), 0, len);
+skb_put_zero(skb, len);
Apply it to the tree (with one manual fixup to keep the
comment in vxlan.c, which spatch removed.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:19 +02:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:20 +01:00
|
|
|
|
2014-11-06 06:57:27 -08:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-02 20:52:28 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-11-30 13:21:32 +01:00
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
2013-12-13 15:22:20 +01:00
|
|
|
|
net: openvswitch: add hash info to upcall
When using the kernel datapath, the upcall don't
include skb hash info relatived. That will introduce
some problem, because the hash of skb is important
in kernel stack. For example, VXLAN module uses
it to select UDP src port. The tx queue selection
may also use the hash in stack.
Hash is computed in different ways. Hash is random
for a TCP socket, and hash may be computed in hardware,
or software stack. Recalculation hash is not easy.
Hash of TCP socket is computed:
tcp_v4_connect
-> sk_set_txhash (is random)
__tcp_transmit_skb
-> skb_set_hash_from_sk
There will be one upcall, without information of skb
hash, to ovs-vswitchd, for the first packet of a TCP
session. The rest packets will be processed in Open vSwitch
modules, hash kept. If this tcp session is forward to
VXLAN module, then the UDP src port of first tcp packet
is different from rest packets.
TCP packets may come from the host or dockers, to Open vSwitch.
To fix it, we store the hash info to upcall, and restore hash
when packets sent back.
+---------------+ +-------------------------+
| Docker/VMs | | ovs-vswitchd |
+----+----------+ +-+--------------------+--+
| ^ |
| | |
| | upcall v restore packet hash (not recalculate)
| +-+--------------------+--+
| tap netdev | | vxlan module
+---------------> +--> Open vSwitch ko +-->
or internal type | |
+-------------------------+
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-13 23:04:49 +08:00
|
|
|
|
2013-12-13 15:22:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-01-13 17:13:44 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-19 14:04:59 +01:00
|
|
|
|
2012-05-13 08:44:18 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
|
|
|
|
|
2017-05-18 15:44:42 +02:00
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: fix skb_panic due to the incorrect actions attrlen
For sw_flow_actions, the actions_len only represents the kernel part's
size, and when we dump the actions to the userspace, we will do the
convertions, so it's true size may become bigger than the actions_len.
But unfortunately, for OVS_PACKET_ATTR_ACTIONS, we use the actions_len
to alloc the skbuff, so the user_skb's size may become insufficient and
oops will happen like this:
skbuff: skb_over_panic: text:ffffffff8148fabf len:1749 put:157 head:
ffff881300f39000 data:ffff881300f39000 tail:0x6d5 end:0x6c0 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:129!
[...]
Call Trace:
<IRQ>
[<ffffffff8148be82>] skb_put+0x43/0x44
[<ffffffff8148fabf>] skb_zerocopy+0x6c/0x1f4
[<ffffffffa0290d36>] queue_userspace_packet+0x3a3/0x448 [openvswitch]
[<ffffffffa0292023>] ovs_dp_upcall+0x30/0x5c [openvswitch]
[<ffffffffa028d435>] output_userspace+0x132/0x158 [openvswitch]
[<ffffffffa01e6890>] ? ip6_rcv_finish+0x74/0x77 [ipv6]
[<ffffffffa028e277>] do_execute_actions+0xcc1/0xdc8 [openvswitch]
[<ffffffffa028e3f2>] ovs_execute_actions+0x74/0x106 [openvswitch]
[<ffffffffa0292130>] ovs_dp_process_packet+0xe1/0xfd [openvswitch]
[<ffffffffa0292b77>] ? key_extract+0x63c/0x8d5 [openvswitch]
[<ffffffffa029848b>] ovs_vport_receive+0xa1/0xc3 [openvswitch]
[...]
Also we can find that the actions_len is much little than the orig_len:
crash> struct sw_flow_actions 0xffff8812f539d000
struct sw_flow_actions {
rcu = {
next = 0xffff8812f5398800,
func = 0xffffe3b00035db32
},
orig_len = 1384,
actions_len = 592,
actions = 0xffff8812f539d01c
}
So as a quick fix, use the orig_len instead of the actions_len to alloc
the user_skb.
Last, this oops happened on our system running a relative old kernel, but
the same risk still exists on the mainline, since we use the wrong
actions_len from the beginning.
Fixes: ccea74457bbd ("openvswitch: include datapath actions with sampled-packet upcall to userspace")
Cc: Neil McKee <neil.mckee@inmon.com>
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-08-16 13:30:07 +08:00
|
|
|
|
|
|
|
|
|
2016-02-18 15:03:25 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-14 23:20:16 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:48 -08:00
|
|
|
|
2019-05-02 16:12:38 -04:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-02-15 17:29:22 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-11-06 06:51:24 -08:00
|
|
|
|
2019-04-26 11:13:06 +02:00
|
|
|
|
|
|
|
|
|
2019-03-15 01:11:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-22 18:17:16 -07:00
|
|
|
|
|
|
|
|
|
2019-05-02 16:12:38 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-06 06:51:24 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-26 20:59:43 -07:00
|
|
|
|
2019-04-26 11:13:06 +02:00
|
|
|
|
2019-03-15 01:11:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-26 20:59:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2019-11-14 23:51:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
|
|
|
|
|
2016-06-20 07:26:17 -07:00
|
|
|
|
2019-11-14 23:51:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-20 07:26:17 -07:00
|
|
|
|
|
|
|
|
|
net: openvswitch: add hash info to upcall
When using the kernel datapath, the upcall don't
include skb hash info relatived. That will introduce
some problem, because the hash of skb is important
in kernel stack. For example, VXLAN module uses
it to select UDP src port. The tx queue selection
may also use the hash in stack.
Hash is computed in different ways. Hash is random
for a TCP socket, and hash may be computed in hardware,
or software stack. Recalculation hash is not easy.
Hash of TCP socket is computed:
tcp_v4_connect
-> sk_set_txhash (is random)
__tcp_transmit_skb
-> skb_set_hash_from_sk
There will be one upcall, without information of skb
hash, to ovs-vswitchd, for the first packet of a TCP
session. The rest packets will be processed in Open vSwitch
modules, hash kept. If this tcp session is forward to
VXLAN module, then the UDP src port of first tcp packet
is different from rest packets.
TCP packets may come from the host or dockers, to Open vSwitch.
To fix it, we store the hash info to upcall, and restore hash
when packets sent back.
+---------------+ +-------------------------+
| Docker/VMs | | ovs-vswitchd |
+----+----------+ +-+--------------------+--+
| ^ |
| | |
| | upcall v restore packet hash (not recalculate)
| +-+--------------------+--+
| tap netdev | | vxlan module
+---------------> +--> Open vSwitch ko +-->
or internal type | |
+-------------------------+
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-13 23:04:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2016-06-10 11:49:33 -07:00
|
|
|
|
2014-03-26 22:37:45 +00:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-01-14 16:27:49 +00:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-01-14 16:27:49 +00:00
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-12-13 15:22:21 +01:00
|
|
|
|
2014-09-02 20:52:28 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-03-26 22:37:45 +00:00
|
|
|
|
|
|
|
|
|
2022-08-17 11:06:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-06 05:45:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-09-15 19:20:31 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
net: openvswitch: add hash info to upcall
When using the kernel datapath, the upcall don't
include skb hash info relatived. That will introduce
some problem, because the hash of skb is important
in kernel stack. For example, VXLAN module uses
it to select UDP src port. The tx queue selection
may also use the hash in stack.
Hash is computed in different ways. Hash is random
for a TCP socket, and hash may be computed in hardware,
or software stack. Recalculation hash is not easy.
Hash of TCP socket is computed:
tcp_v4_connect
-> sk_set_txhash (is random)
__tcp_transmit_skb
-> skb_set_hash_from_sk
There will be one upcall, without information of skb
hash, to ovs-vswitchd, for the first packet of a TCP
session. The rest packets will be processed in Open vSwitch
modules, hash kept. If this tcp session is forward to
VXLAN module, then the UDP src port of first tcp packet
is different from rest packets.
TCP packets may come from the host or dockers, to Open vSwitch.
To fix it, we store the hash info to upcall, and restore hash
when packets sent back.
+---------------+ +-------------------------+
| Docker/VMs | | ovs-vswitchd |
+----+----------+ +-+--------------------+--+
| ^ |
| | |
| | upcall v restore packet hash (not recalculate)
| +-+--------------------+--+
| tap netdev | | vxlan module
+---------------> +--> Open vSwitch ko +-->
or internal type | |
+-------------------------+
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-13 23:04:49 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2015-01-14 13:56:19 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:47 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:48 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: openvswitch: add hash info to upcall
When using the kernel datapath, the upcall don't
include skb hash info relatived. That will introduce
some problem, because the hash of skb is important
in kernel stack. For example, VXLAN module uses
it to select UDP src port. The tx queue selection
may also use the hash in stack.
Hash is computed in different ways. Hash is random
for a TCP socket, and hash may be computed in hardware,
or software stack. Recalculation hash is not easy.
Hash of TCP socket is computed:
tcp_v4_connect
-> sk_set_txhash (is random)
__tcp_transmit_skb
-> skb_set_hash_from_sk
There will be one upcall, without information of skb
hash, to ovs-vswitchd, for the first packet of a TCP
session. The rest packets will be processed in Open vSwitch
modules, hash kept. If this tcp session is forward to
VXLAN module, then the UDP src port of first tcp packet
is different from rest packets.
TCP packets may come from the host or dockers, to Open vSwitch.
To fix it, we store the hash info to upcall, and restore hash
when packets sent back.
+---------------+ +-------------------------+
| Docker/VMs | | ovs-vswitchd |
+----+----------+ +-+--------------------+--+
| ^ |
| | |
| | upcall v restore packet hash (not recalculate)
| +-+--------------------+--+
| tap netdev | | vxlan module
+---------------> +--> Open vSwitch ko +-->
or internal type | |
+-------------------------+
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-13 23:04:49 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-03-27 12:35:23 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:52 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2013-06-17 17:50:12 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-10-03 15:35:33 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-11-26 11:24:11 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-15 19:20:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-09-15 19:20:31 -07:00
|
|
|
|
2014-10-06 05:45:32 -07:00
|
|
|
|
2014-09-15 19:20:31 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-10-06 05:45:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:47 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2015-01-14 13:56:19 +00:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2020-03-02 21:05:18 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:05 +02:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
genetlink: make policy common to family
Since maxattr is common, the policy can't really differ sanely,
so make it common as well.
The only user that did in fact manage to make a non-common policy
is taskstats, which has to be really careful about it (since it's
still using a common maxattr!). This is no longer supported, but
we can fake it using pre_doit.
This reduces the size of e.g. nl80211.o (which has lots of commands):
text data bss dec hex filename
398745 14323 2240 415308 6564c net/wireless/nl80211.o (before)
397913 14331 2240 414484 65314 net/wireless/nl80211.o (after)
--------------------------------
-832 +8 0 -824
Which is obviously just 8 bytes for each command, and an added 8
bytes for the new policy pointer. I'm not sure why the ops list is
counted as .text though.
Most of the code transformations were done using the following spatch:
@ops@
identifier OPS;
expression POLICY;
@@
struct genl_ops OPS[] = {
...,
{
- .policy = POLICY,
},
...
};
@@
identifier ops.OPS;
expression ops.POLICY;
identifier fam;
expression M;
@@
struct genl_family fam = {
.ops = OPS,
.maxattr = M,
+ .policy = POLICY,
...
};
This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
the cb->data as ops, which we want to change in a later genl patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-21 22:51:02 +01:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
|
|
|
|
|
2022-08-24 17:18:30 -07:00
|
|
|
|
2016-10-24 14:40:03 +02:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2014-11-06 06:58:52 -08:00
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
|
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-13 21:26:42 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-03-13 21:26:42 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2020-07-31 14:20:56 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-26 12:55:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2019-11-26 12:55:50 +01:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:44 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-29 17:22:21 -07:00
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
2012-03-29 23:20:48 -04:00
|
|
|
|
2016-04-25 10:25:17 +02:00
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-03-29 23:20:48 -04:00
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-29 17:22:21 -07:00
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 11:13:06 +02:00
|
|
|
|
2013-06-17 17:50:12 -07:00
|
|
|
|
2013-07-30 15:39:39 -07:00
|
|
|
|
|
|
|
|
|
2013-12-03 10:58:53 -08:00
|
|
|
|
2013-10-03 18:16:47 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
2013-06-17 17:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
2013-06-17 17:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2015-01-21 16:42:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-08 13:09:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-01-16 22:09:00 +01:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-09-18 10:31:04 +02:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2016-02-18 15:03:25 +01:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-07-27 12:37:46 +05:30
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2019-12-01 18:41:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-10-06 05:08:38 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-10-06 05:08:38 -07:00
|
|
|
|
|
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-10-06 05:08:38 -07:00
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-02 00:02:18 +03:00
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:52 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2023-02-02 00:02:18 +03:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2023-02-02 00:02:18 +03:00
|
|
|
|
2013-06-17 17:50:12 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2023-02-02 00:02:18 +03:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2013-10-04 00:17:42 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2013-10-04 00:17:42 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-30 20:30:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2015-07-21 10:44:03 +02:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2015-07-21 10:44:03 +02:00
|
|
|
|
openvswitch: Fix flow lookup to use unmasked key
[ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
The commit mentioned below causes the ovs_flow_tbl_lookup() function
to be called with the masked key. However, it's supposed to be called
with the unmasked key. This due to the fact that the datapath supports
installing wider flows, and OVS relies on this behavior. For example
if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
128.0.0.0) is allowed to be added.
However, if we try to add a wildcard rule, the installation fails:
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
$ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
ovs-vswitchd: updating flow table (File exists)
The reason is that the key used to determine if the flow is already
present in the system uses the original key ANDed with the mask.
This results in the IP address not being part of the (miniflow) key,
i.e., being substituted with an all-zero value. When doing the actual
lookup, this results in the key wrongfully matching the first flow,
and therefore the flow does not get installed.
This change reverses the commit below, but rather than having the key
on the stack, it's allocated.
Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-15 15:46:33 +01:00
|
|
|
|
|
|
|
|
|
2023-02-02 00:02:18 +03:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-10-19 11:19:51 -07:00
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-03 15:35:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-21 20:21:20 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-10-03 15:35:32 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
|
|
|
|
|
2014-10-03 15:35:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-22 17:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-11 21:56:20 +02:00
|
|
|
|
|
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
2014-10-03 15:35:32 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2016-03-10 17:14:59 +01:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
2016-03-10 17:14:59 +01:00
|
|
|
|
|
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
2016-03-10 17:14:59 +01:00
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 17:27:44 -07:00
|
|
|
|
2014-10-19 11:19:51 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 09:59:40 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2015-08-26 11:31:48 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-06-30 20:30:29 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2015-08-12 15:59:47 +05:30
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-21 10:44:03 +02:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 15:22:25 -07:00
|
|
|
|
|
|
|
|
|
2015-07-21 10:44:03 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2016-09-19 13:51:00 -07:00
|
|
|
|
2015-08-26 11:31:52 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-30 20:30:29 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-26 11:31:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2016-09-19 13:51:00 -07:00
|
|
|
|
2015-08-26 11:31:52 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
2013-08-07 20:01:00 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-30 20:30:29 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2019-06-05 23:06:40 +02:00
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2019-12-01 18:41:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2014-05-05 13:13:14 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-12-01 18:41:25 +01:00
|
|
|
|
2014-05-05 14:40:13 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2015-01-21 16:42:52 -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
|
|
|
|
|
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-07-30 15:39:39 -07:00
|
|
|
|
2014-09-08 13:14:22 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2013-07-30 15:39:39 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:28:07 -07:00
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-30 15:39:39 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2014-11-06 07:03:05 -08:00
|
|
|
|
2015-01-21 16:42:52 -08:00
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2014-05-05 14:53:51 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:05 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
genetlink: make policy common to family
Since maxattr is common, the policy can't really differ sanely,
so make it common as well.
The only user that did in fact manage to make a non-common policy
is taskstats, which has to be really careful about it (since it's
still using a common maxattr!). This is no longer supported, but
we can fake it using pre_doit.
This reduces the size of e.g. nl80211.o (which has lots of commands):
text data bss dec hex filename
398745 14323 2240 415308 6564c net/wireless/nl80211.o (before)
397913 14331 2240 414484 65314 net/wireless/nl80211.o (after)
--------------------------------
-832 +8 0 -824
Which is obviously just 8 bytes for each command, and an added 8
bytes for the new policy pointer. I'm not sure why the ops list is
counted as .text though.
Most of the code transformations were done using the following spatch:
@ops@
identifier OPS;
expression POLICY;
@@
struct genl_ops OPS[] = {
...,
{
- .policy = POLICY,
},
...
};
@@
identifier ops.OPS;
expression ops.POLICY;
identifier fam;
expression M;
@@
struct genl_family fam = {
.ops = OPS,
.maxattr = M,
+ .policy = POLICY,
...
};
This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
the cb->data as ops, which we want to change in a later genl patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-21 22:51:02 +01:00
|
|
|
|
2013-04-23 07:48:48 +00:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
|
|
|
|
|
2022-08-24 17:18:30 -07:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:03 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
|
|
|
|
|
2014-01-23 10:47:35 -08:00
|
|
|
|
2020-07-31 14:21:34 +02:00
|
|
|
|
2022-08-25 05:04:50 +03:00
|
|
|
|
2013-03-29 14:46:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 15:55:16 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2022-08-25 05:04:50 +03:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
|
|
|
|
|
2013-10-22 10:42:46 -07:00
|
|
|
|
|
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 23:20:48 -04:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-12-13 15:22:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-31 14:21:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-25 05:04:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-16 22:09:00 +01:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-18 15:03:26 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2016-02-18 15:03:25 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 11:32:17 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2014-11-06 06:58:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
|
|
|
|
|
2014-02-14 11:42:36 +01:00
|
|
|
|
2013-12-13 15:22:19 +01:00
|
|
|
|
|
|
|
|
|
2022-10-25 06:50:17 -04:00
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-23 10:24:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
2021-07-23 10:24:13 -04:00
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
2013-12-13 15:22:18 +01:00
|
|
|
|
2022-02-03 10:44:30 +02:00
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-31 14:21:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
|
|
|
|
|
openvswitch: Introduce per-cpu upcall dispatch
The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.
This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:
* On systems with a large number of vports, there is a correspondingly
large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)
This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.
In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:
a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.
The corresponding user space code can be found at:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385139.html
Bugzilla: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray <mark.d.gray@redhat.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-15 08:27:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 10:44:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:18 +01:00
|
|
|
|
|
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-18 15:03:26 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2015-03-11 23:04:08 -05:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-10-04 00:14:23 -07:00
|
|
|
|
|
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
|
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-17 15:14:13 -07:00
|
|
|
|
2022-08-25 05:04:49 +03:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-03 09:25:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-25 05:03:26 +03:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2013-07-30 15:42:19 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2022-08-25 05:03:26 +03:00
|
|
|
|
|
|
|
|
|
2020-11-03 09:25:49 +01:00
|
|
|
|
|
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-06 18:41:20 -07:00
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-11-01 22:23:54 +08:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2020-08-12 17:56:39 +08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2022-02-03 10:44:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-07-30 15:42:19 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-01-21 09:31:04 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2020-08-12 17:56:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-18 15:03:26 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-18 15:03:26 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-13 15:22:18 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2016-02-18 15:03:26 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 15:55:16 -08:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2014-11-11 15:55:16 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2014-11-11 15:55:16 -08:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 15:55:16 -08:00
|
|
|
|
|
|
|
|
|
2012-01-17 13:33:39 +00:00
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2018-09-26 11:40:14 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-11 15:55:16 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-31 14:21:34 +02:00
|
|
|
|
|
|
|
|
|
2022-08-25 05:04:49 +03:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:05 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
genetlink: make policy common to family
Since maxattr is common, the policy can't really differ sanely,
so make it common as well.
The only user that did in fact manage to make a non-common policy
is taskstats, which has to be really careful about it (since it's
still using a common maxattr!). This is no longer supported, but
we can fake it using pre_doit.
This reduces the size of e.g. nl80211.o (which has lots of commands):
text data bss dec hex filename
398745 14323 2240 415308 6564c net/wireless/nl80211.o (before)
397913 14331 2240 414484 65314 net/wireless/nl80211.o (after)
--------------------------------
-832 +8 0 -824
Which is obviously just 8 bytes for each command, and an added 8
bytes for the new policy pointer. I'm not sure why the ops list is
counted as .text though.
Most of the code transformations were done using the following spatch:
@ops@
identifier OPS;
expression POLICY;
@@
struct genl_ops OPS[] = {
...,
{
- .policy = POLICY,
},
...
};
@@
identifier ops.OPS;
expression ops.POLICY;
identifier fam;
expression M;
@@
struct genl_family fam = {
.ops = OPS,
.maxattr = M,
+ .policy = POLICY,
...
};
This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
the cb->data as ops, which we want to change in a later genl patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-21 22:51:02 +01:00
|
|
|
|
2013-04-23 07:48:48 +00:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
|
|
|
|
|
2022-08-24 17:18:30 -07:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:03 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2017-11-02 17:04:37 -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
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 23:20:48 -04:00
|
|
|
|
|
|
|
|
|
2014-07-17 15:14:13 -07:00
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
|
|
|
|
|
2012-03-29 23:20:48 -04:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2017-11-02 17:04:37 -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
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2016-04-26 10:06:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 23:20:48 -04:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-07-17 15:14:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-16 22:09:00 +01:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07: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
|
|
|
|
2011-10-25 19:26:31 -07: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
|
|
|
|
|
|
|
|
|
2013-03-26 15:48:38 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2014-11-06 06:58:52 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2012-03-06 15:04:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-01-09 14:27:35 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-19 01:28:02 +05:30
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2020-02-19 01:28:02 +05:30
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2022-08-25 05:04:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-17 15:14:13 -07:00
|
|
|
|
2022-08-25 05:04:49 +03:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2017-11-02 17:04:37 -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
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
2013-03-29 14:46:50 +01:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2013-05-13 08:15:26 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-03-26 15:48:38 -07:00
|
|
|
|
|
|
|
|
|
2013-05-13 08:15:26 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-05-13 08:15:26 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-05-13 08:15:26 -07:00
|
|
|
|
2013-03-26 15:48:38 -07:00
|
|
|
|
2014-07-17 15:14:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2017-11-02 17:04:37 -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
|
|
|
|
2013-03-26 15:48:38 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2017-11-02 17:04:37 -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
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
|
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2016-02-26 10:45:39 +01:00
|
|
|
|
2019-07-06 01:08:09 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2013-11-19 15:19:39 +01:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2017-11-02 17:04:37 -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
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-05-05 14:13:32 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-02-15 17:42:29 -08:00
|
|
|
|
2014-09-08 13:14:22 -07:00
|
|
|
|
2014-02-15 17:42:29 -08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2014-02-15 17:42:29 -08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
2012-09-07 20:12:54 +00:00
|
|
|
|
2012-08-23 12:40:54 -07: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
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-08-23 12:40:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2020-07-15 14:09:28 +02:00
|
|
|
|
|
|
|
|
|
2020-07-24 10:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-15 14:09:28 +02:00
|
|
|
|
|
|
|
|
|
2020-07-24 10:20:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-15 14:09:28 +02:00
|
|
|
|
|
|
|
|
|
2020-07-24 10:20:59 +02:00
|
|
|
|
2020-07-15 14:09:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-24 19:11:52 +08:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
2017-11-02 17:04:37 -02:00
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-26 14:07:31 +02:00
|
|
|
|
2016-02-05 09:20:52 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:05 +02:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
genetlink: make policy common to family
Since maxattr is common, the policy can't really differ sanely,
so make it common as well.
The only user that did in fact manage to make a non-common policy
is taskstats, which has to be really careful about it (since it's
still using a common maxattr!). This is no longer supported, but
we can fake it using pre_doit.
This reduces the size of e.g. nl80211.o (which has lots of commands):
text data bss dec hex filename
398745 14323 2240 415308 6564c net/wireless/nl80211.o (before)
397913 14331 2240 414484 65314 net/wireless/nl80211.o (after)
--------------------------------
-832 +8 0 -824
Which is obviously just 8 bytes for each command, and an added 8
bytes for the new policy pointer. I'm not sure why the ops list is
counted as .text though.
Most of the code transformations were done using the following spatch:
@ops@
identifier OPS;
expression POLICY;
@@
struct genl_ops OPS[] = {
...,
{
- .policy = POLICY,
},
...
};
@@
identifier ops.OPS;
expression ops.POLICY;
identifier fam;
expression M;
@@
struct genl_family fam = {
.ops = OPS,
.maxattr = M,
+ .policy = POLICY,
...
};
This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
the cb->data as ops, which we want to change in a later genl patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-03-21 22:51:02 +01:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2020-10-02 14:49:54 -07:00
|
|
|
|
|
|
|
|
|
2022-10-27 20:25:01 -07:00
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:03 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
openvswitch: Support conntrack zone limit
Currently, nf_conntrack_max is used to limit the maximum number of
conntrack entries in the conntrack table for every network namespace.
For the VMs and containers that reside in the same namespace,
they share the same conntrack table, and the total # of conntrack entries
for all the VMs and containers are limited by nf_conntrack_max. In this
case, if one of the VM/container abuses the usage the conntrack entries,
it blocks the others from committing valid conntrack entries into the
conntrack table. Even if we can possibly put the VM in different network
namespace, the current nf_conntrack_max configuration is kind of rigid
that we cannot limit different VM/container to have different # conntrack
entries.
To address the aforementioned issue, this patch proposes to have a
fine-grained mechanism that could further limit the # of conntrack entries
per-zone. For example, we can designate different zone to different VM,
and set conntrack limit to each zone. By providing this isolation, a
mis-behaved VM only consumes the conntrack entries in its own zone, and
it will not influence other well-behaved VMs. Moreover, the users can
set various conntrack limit to different zone based on their preference.
The proposed implementation utilizes Netfilter's nf_conncount backend
to count the number of connections in a particular zone. If the number of
connection is above a configured limitation, ovs will return ENOMEM to the
userspace. If userspace does not configure the zone limit, the limit
defaults to zero that is no limitation, which is backward compatible to
the behavior without this patch.
The following high leve APIs are provided to the userspace:
- OVS_CT_LIMIT_CMD_SET:
* set default connection limit for all zones
* set the connection limit for a particular zone
- OVS_CT_LIMIT_CMD_DEL:
* remove the connection limit for a particular zone
- OVS_CT_LIMIT_CMD_GET:
* get the default connection limit for all zones
* get the connection limit for a particular zone
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-24 17:56:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2016-10-24 14:40:05 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-06 16:44:50 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-31 11:57:57 +02:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2020-07-24 10:20:59 +02:00
|
|
|
|
2020-08-31 11:57:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-24 10:20:59 +02:00
|
|
|
|
|
|
|
|
|
2020-08-31 11:57:57 +02:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2015-02-17 11:23:10 -08:00
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2015-02-17 11:23:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-21 10:44:04 +02:00
|
|
|
|
2015-02-17 11:23:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2020-04-17 02:57:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2015-02-17 11:23:10 -08: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
|
|
|
|
2015-02-17 11:23:10 -08: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
|
|
|
|
2015-02-17 11:23:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
|
|
|
|
|
2020-07-24 10:20:59 +02:00
|
|
|
|
2013-04-15 13:23:03 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-01 20:26:12 +08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-15 19:37:25 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-15 19:37:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-26 09:58:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-26 09:58:26 +02:00
|
|
|
|
|
|
|
|
|
2014-09-15 19:37:25 -07:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-22 17:29:06 +02:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
2012-02-22 19:58:59 -08:00
|
|
|
|
|
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
2014-06-26 09:58:26 +02:00
|
|
|
|
2014-09-15 19:37:25 -07:00
|
|
|
|
2011-10-25 19:26:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-09 17:42:30 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-10 12:09:42 -08:00
|
|
|
|
openvswitch: Support conntrack zone limit
Currently, nf_conntrack_max is used to limit the maximum number of
conntrack entries in the conntrack table for every network namespace.
For the VMs and containers that reside in the same namespace,
they share the same conntrack table, and the total # of conntrack entries
for all the VMs and containers are limited by nf_conntrack_max. In this
case, if one of the VM/container abuses the usage the conntrack entries,
it blocks the others from committing valid conntrack entries into the
conntrack table. Even if we can possibly put the VM in different network
namespace, the current nf_conntrack_max configuration is kind of rigid
that we cannot limit different VM/container to have different # conntrack
entries.
To address the aforementioned issue, this patch proposes to have a
fine-grained mechanism that could further limit the # of conntrack entries
per-zone. For example, we can designate different zone to different VM,
and set conntrack limit to each zone. By providing this isolation, a
mis-behaved VM only consumes the conntrack entries in its own zone, and
it will not influence other well-behaved VMs. Moreover, the users can
set various conntrack limit to different zone based on their preference.
The proposed implementation utilizes Netfilter's nf_conncount backend
to count the number of connections in a particular zone. If the number of
connection is above a configured limitation, ovs will return ENOMEM to the
userspace. If userspace does not configure the zone limit, the limit
defaults to zero that is no limitation, which is backward compatible to
the behavior without this patch.
The following high leve APIs are provided to the userspace:
- OVS_CT_LIMIT_CMD_SET:
* set default connection limit for all zones
* set the connection limit for a particular zone
- OVS_CT_LIMIT_CMD_DEL:
* remove the connection limit for a particular zone
- OVS_CT_LIMIT_CMD_GET:
* get the default connection limit for all zones
* get the connection limit for a particular zone
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-24 17:56:43 -07:00
|
|
|
|
