merge #132

A recent commit added new variables only used if CONFIG_NETDEVICES is set. A simple fix is to only declare these variables if the same condition is valid. Other solutions could be to move the code related to SO_BINDTODEVICE option from _bpf_setsockopt() function to a dedicated one or only declare these variables in the related "case" section. Fixes: 70c5899 ("bpf: Allow SO_BINDTODEVICE opt in bpf_setsockopt") Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>

The msk sk_shutdown flag is set by a workqueue, possibly introducing some delay in user-space notification. If the last subflow carries some data with the fin packet, the user space can wake-up before RCV_SHUTDOWN is set. If it executes unblocking recvmsg(), it may return with an error instead of eof. Address the issue explicitly checking for eof in recvmsg(), when no data is found. Fixes: 59832e2 ("mptcp: subflow: check parent mptcp socket on subflow state change") Signed-off-by: Paolo Abeni <pabeni@redhat.com>

When the left-over msk is freed by subflow_syn_recv_sock(), we don't invoke the proto->destroy() method, to the socket is not removed from the token container, leading to later UaF. Address the issue explicitly removing the token even in the above error path. Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Add the missing annotation in some setup-only functions. Signed-off-by: Paolo Abeni <pabeni@redhat.com> -- v1 -> v2 - move mptcp_token_init() into the next patch - added missing annotation for pm_netlink

Replace the radix tree with an hash table allocated at boot time. The radix tree has some short coming: a single lock is contented by all the mptcp operation, the lookup currently use such lock, and traversing all the items would require lock, too. With hash table instead we trade a little memory to address all the above - a per bucket lock is used. To hash the MPTCP sockets, we re-use the msk' sk_node entry: the MPTCP sockets are never hashed by the stack. Replace the existing hash proto callbacks with dummy implementation, annotating the above constraint. Additionally refactor the token creation to code to: - limit the number of consecutive attempts to a fixed maximum. Hitting an hash bucket with long chain is considered a failed attempt - accept() no longer can fail to to token management. - if token creation fails at connect() time, we do fallback to TCP (before the connection was closed) Signed-off-by: Paolo Abeni <pabeni@redhat.com>

This clean-up the code a bit, reduces the number of used hooks and indirect call requested, and allow better error reporting from __mptcp_subflow_connect() Signed-off-by: Paolo Abeni <pabeni@redhat.com>

currently MPTCP uses a custom hook to executed unit test at boot time. Let's use the KUNIT framework instead. Additionally move the relevant code to a separate file and export the function needed by the test when self-tests are build as a module. Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Unit tests for the internal MPTCP token APIs, using KUNIT Signed-off-by: Paolo Abeni <pabeni@redhat.com>

keep using MPTCP sockets and a "dummy mapping" in case of fallback to regular TCP. Skip adding DSS option on send, if TCP fallback has been done earlier. Notes: I'm unsure on what to do in mptcp_clean_una() to do a one-time flush of the retransmit queue, as per Mat's suggestion. Any advice? Changes since v1 - rebase on top of Paolo's fix for NULL dereference in mptcp_recvmsg() Changes since RFC v2: - use a bit in msk->flags, rather than a dedicated boolean in struct msk. This bit is going to be used in combination with another one, TCP_FALLBACK_ALLOWED, that is 1 at the first subflow creation and gets cleared once TCP fallback is no more allowed. - separate code that adds support for "infinite mapping", and use the term "dummy" instead of "infinite". Suggested by Mat - remove inappropriate call to __mptcp_do_fallback() in mptcp_accept() (Paolo) Changes since RFC v1: - use a dedicated member of struct msk to indicate that a fallback ha happened, use it in case of infinite mapping - don't delete skb_ext in case of infinite mapping (Mat) - test the value of pm.subflows on reception of an infinite map to ensure that no other subflow is currently opened (Mat) - in mptcp_established_options(), avoid adding TCP options in case of fallback indication; simplify sendmsg()/recvmsg()/poll() to keep using the MPTCP socket in case of TCP fallback. Set the fallback indication in case subflow is not mp_capable after successful 3-way handshake, instead of flipping 'is_mptcp' (Paolo/Mat) - remove deadcode in mptcp_finish_connect, and increment MPTCP_MIB_MPCAPABLEACTIVEFALLBACK in subflow_finish_connect (Paolo) BugLink: #11 BugLink: #22 Co-developed-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com>

The script generates two random files that are then sent via tcp and mptcp connections. In order to compare throughput over consecutive runs add an option to provide the file size on the command line: "-f 128000". Also add an option, -t, to enable tcp tests. This is useful to compare throughput of mptcp connections and tcp connections. Example: run tests with a 4mb file size, 300ms delay 0.01% loss, default gso/tso/gro settings and with large write/blocking io: mptcp_connect.sh -t -f $((4 * 1024 * 1024)) -d 300 -l 0.01% -r 0 -e "" -m mmap Signed-off-by: Florian Westphal <fw@strlen.de>

When mptcp is used, userspace doesn't read from the tcp (subflow) socket but from the parent (mptcp) socket receive queue. skbs are moved from the subflow socket to the mptcp rx queue either from 'data_ready' callback (if mptcp socket can be locked), a work queue, or the socket receive function. This means tcp_rcv_space_adjust() is never called and thus no receive buffer size auto-tuning is done. An earlier (not merged) patch added tcp_rcv_space_adjust() calls to the function that moves skbs from subflow to mptcp socket. While this enabled autotuning, it also meant tuning was done even if userspace was reading the mptcp socket very slowly. This adds mptcp_rcv_space_adjust() and calls it after userspace has read data from the mptcp socket rx queue. Its very similar to tcp_rcv_space_adjust, with two differences: 1. The rtt estimate is the largest one observed on a subflow 2. The rcvbuf size and window clamp of all subflows is adjusted to the mptcp-level rcvbuf. Otherwise, we get spurious drops at tcp (subflow) socket level if the skbs are not moved to the mptcp socket fast enough and reduced throughput.. Before: time mptcp_connect.sh -t -f $((4*1024*1024)) -d 300 -l 0.01% -r 0 -e "" -m mmap [..] ns4 MPTCP -> ns3 (10.0.3.2:10108 ) MPTCP (duration 40562ms) [ OK ] ns4 MPTCP -> ns3 (10.0.3.2:10109 ) TCP (duration 5415ms) [ OK ] ns4 TCP -> ns3 (10.0.3.2:10110 ) MPTCP (duration 5413ms) [ OK ] ns4 MPTCP -> ns3 (dead:beef:3::2:10111) MPTCP (duration 41331ms) [ OK ] ns4 MPTCP -> ns3 (dead:beef:3::2:10112) TCP (duration 5415ms) [ OK ] ns4 TCP -> ns3 (dead:beef:3::2:10113) MPTCP (duration 5714ms) [ OK ] Time: 846 seconds After: ns4 MPTCP -> ns3 (10.0.3.2:10108 ) MPTCP (duration 5417ms) [ OK ] ns4 MPTCP -> ns3 (10.0.3.2:10109 ) TCP (duration 5429ms) [ OK ] ns4 TCP -> ns3 (10.0.3.2:10110 ) MPTCP (duration 5418ms) [ OK ] ns4 MPTCP -> ns3 (dead:beef:3::2:10111) MPTCP (duration 5423ms) [ OK ] ns4 MPTCP -> ns3 (dead:beef:3::2:10112) TCP (duration 5715ms) [ OK ] ns4 TCP -> ns3 (dead:beef:3::2:10113) MPTCP (duration 5415ms) [ OK ] Time: 275 seconds Signed-off-by: Florian Westphal <fw@strlen.de>

Helps detection UaF, which apparently kasan misses with kmem_cache allocator. We also need to always set the SOCK_RCU_FREE flag, to preserved the current code leveraging SLAB_TYPESAFE_BY_RCU. This latter change will make unreachable some existing errors path, but I don't see other options. Signed-off-by: Paolo Abeni <pabeni@redhat.com>

This commit is useful for automated builds, e.g. from Intel's kbuild. Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

merge #132

merge #132

Commits on Jun 10, 2020