When the selftest got added, sendfile() on mptcp sockets returned
-EOPNOTSUPP, so running 'mptcp_connect.sh -m sendfile' failed
immediately.

This is no longer the case, but the script fails anyway due to timeout.
Let the receiver know once the sender has sent all data, just like
with '-m mmap' mode.

Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
Signed-off-by: Florian Westphal <fw@strlen.de>
---
 tools/testing/selftests/net/mptcp/mptcp_connect.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/testing/selftests/net/mptcp/mptcp_connect.c
index e2ea6c126c99..6e429b88f911 100644
--- a/tools/testing/selftests/net/mptcp/mptcp_connect.c
+++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c
@@ -791,6 +791,9 @@ static int copyfd_io_sendfile(int infd, int peerfd, int outfd,
 		err = do_sendfile(infd, peerfd, size);
 		if (err)
 			return err;
+
+		shutdown(peerfd, SHUT_WR);
+
 		err = do_recvfile(peerfd, outfd);
 		*in_closed_after_out = true;
 	}
-- 
2.35.1

On Thu, 28 Jul 2022, Florian Westphal wrote:

> When the selftest got added, sendfile() on mptcp sockets returned
> -EOPNOTSUPP, so running 'mptcp_connect.sh -m sendfile' failed
> immediately.
>
> This is no longer the case, but the script fails anyway due to timeout.
> Let the receiver know once the sender has sent all data, just like
> with '-m mmap' mode.
>

Hi Florian -

I could duplicate the timeout, and confirm that this patch fixes the 
behavior for 'mptcp_connect.sh -m sendfile'.

Unfortunately it breaks userspace_pm.sh, which also uses the mptcp_connect 
binary and deliberately keeps the connection open. userspace_pm.sh uses 
the '-w' flag with sendfile, though. See below.

> Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> tools/testing/selftests/net/mptcp/mptcp_connect.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/testing/selftests/net/mptcp/mptcp_connect.c
> index e2ea6c126c99..6e429b88f911 100644
> --- a/tools/testing/selftests/net/mptcp/mptcp_connect.c
> +++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c
> @@ -791,6 +791,9 @@ static int copyfd_io_sendfile(int infd, int peerfd, int outfd,
> 		err = do_sendfile(infd, peerfd, size);
> 		if (err)
> 			return err;
> +

Adding

 		if (cfg_wait)
 			usleep(cfg_wait);

here (matching with what's in copyfd_io_poll()) seems to keep both 
userspace_pm.sh and 'mptcp_connect.sh -m sendfile' happy. copyfd_io_mmap() 
could probably use the usleep() call too.


Thanks,
Mat

> +		shutdown(peerfd, SHUT_WR);
> +
> 		err = do_recvfile(peerfd, outfd);
> 		*in_closed_after_out = true;
> 	}
> -- 
> 2.35.1
>
>

--
Mat Martineau
Intel

Hi Florian,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal:
  - Unstable: 2 failed test(s): selftest_mptcp_join selftest_userspace_pm 🔴:
  - Task: https://cirrus-ci.com/task/5906818701459456
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5906818701459456/summary/summary.txt

- KVM Validation: debug:
  - Unstable: 1 failed test(s): selftest_userspace_pm 🔴:
  - Task: https://cirrus-ci.com/task/5343868748038144
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5343868748038144/summary/summary.txt

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/d7be8baa6225


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-debug

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (Tessares)