From: Bobby Eshleman <bobbyeshleman@meta.com>
Add wrapper functions vm_vsock_test() and host_vsock_test() to invoke
the vsock_test binary. This encapsulates several items of repeat logic,
such as waiting for the server to reach listening state and
enabling/disabling the bash option pipefail to avoid pipe-style logging
from hiding failures.
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
---
tools/testing/selftests/vsock/vmtest.sh | 131 ++++++++++++++++++++++----------
1 file changed, 92 insertions(+), 39 deletions(-)
diff --git a/tools/testing/selftests/vsock/vmtest.sh b/tools/testing/selftests/vsock/vmtest.sh
index ec3ff443f49a..29b36b4d301d 100755
--- a/tools/testing/selftests/vsock/vmtest.sh
+++ b/tools/testing/selftests/vsock/vmtest.sh
@@ -283,7 +283,78 @@ EOF
host_wait_for_listener() {
wait_for_listener "${TEST_HOST_PORT_LISTENER}" "${WAIT_PERIOD}" "${WAIT_PERIOD_MAX}"
+}
+
+vm_vsock_test() {
+ local host=$1
+ local cid=$2
+ local port=$3
+ local rc
+
+ set -o pipefail
+ if [[ "${host}" != server ]]; then
+ # log output and use pipefail to respect vsock_test errors
+ vm_ssh -- "${VSOCK_TEST}" \
+ --mode=client \
+ --control-host="${host}" \
+ --peer-cid="${cid}" \
+ --control-port="${port}" \
+ 2>&1 | log_guest
+ rc=$?
+ else
+ # log output and use pipefail to respect vsock_test errors
+ vm_ssh -- "${VSOCK_TEST}" \
+ --mode=server \
+ --peer-cid="${cid}" \
+ --control-port="${port}" \
+ 2>&1 | log_guest &
+ rc=$?
+
+ if [[ $rc -ne 0 ]]; then
+ set +o pipefail
+ return $rc
+ fi
+
+ vm_wait_for_listener "${port}"
+ rc=$?
+ fi
+ set +o pipefail
+ return $rc
+}
+
+host_vsock_test() {
+ local host=$1
+ local cid=$2
+ local port=$3
+ local rc
+
+ # log output and use pipefail to respect vsock_test errors
+ set -o pipefail
+ if [[ "${host}" != server ]]; then
+ ${VSOCK_TEST} \
+ --mode=client \
+ --peer-cid="${cid}" \
+ --control-host="${host}" \
+ --control-port="${port}" 2>&1 | log_host
+ rc=$?
+ else
+ ${VSOCK_TEST} \
+ --mode=server \
+ --peer-cid="${cid}" \
+ --control-port="${port}" 2>&1 | log_host &
+ rc=$?
+
+ if [[ $rc -ne 0 ]]; then
+ return $rc
+ fi
+
+ host_wait_for_listener "${port}" "${WAIT_PERIOD}" "${WAIT_PERIOD_MAX}"
+ rc=$?
+ fi
+ set +o pipefail
+
+ return $rc
}
log() {
@@ -322,59 +393,41 @@ log_guest() {
}
test_vm_server_host_client() {
+ if ! vm_vsock_test "server" 2 "${TEST_GUEST_PORT}"; then
+ return "${KSFT_FAIL}"
+ fi
- vm_ssh -- "${VSOCK_TEST}" \
- --mode=server \
- --control-port="${TEST_GUEST_PORT}" \
- --peer-cid=2 \
- 2>&1 | log_guest &
-
- vm_wait_for_listener "${TEST_GUEST_PORT}"
-
- ${VSOCK_TEST} \
- --mode=client \
- --control-host=127.0.0.1 \
- --peer-cid="${VSOCK_CID}" \
- --control-port="${TEST_HOST_PORT}" 2>&1 | log_host
+ if ! host_vsock_test "127.0.0.1" "${VSOCK_CID}" "${TEST_HOST_PORT}"; then
+ return "${KSFT_FAIL}"
+ fi
- return $?
+ return "${KSFT_PASS}"
}
test_vm_client_host_server() {
+ if ! host_vsock_test "server" "${VSOCK_CID}" "${TEST_HOST_PORT_LISTENER}"; then
+ return "${KSFT_FAIL}"
+ fi
- ${VSOCK_TEST} \
- --mode "server" \
- --control-port "${TEST_HOST_PORT_LISTENER}" \
- --peer-cid "${VSOCK_CID}" 2>&1 | log_host &
-
- host_wait_for_listener
-
- vm_ssh -- "${VSOCK_TEST}" \
- --mode=client \
- --control-host=10.0.2.2 \
- --peer-cid=2 \
- --control-port="${TEST_HOST_PORT_LISTENER}" 2>&1 | log_guest
+ if ! vm_vsock_test "10.0.2.2" 2 "${TEST_HOST_PORT_LISTENER}"; then
+ return "${KSFT_FAIL}"
+ fi
- return $?
+ return "${KSFT_PASS}"
}
test_vm_loopback() {
local port=60000 # non-forwarded local port
- vm_ssh -- "${VSOCK_TEST}" \
- --mode=server \
- --control-port="${port}" \
- --peer-cid=1 2>&1 | log_guest &
-
- vm_wait_for_listener "${port}"
+ if ! vm_vsock_test "server" 1 "${port}"; then
+ return "${KSFT_FAIL}"
+ fi
- vm_ssh -- "${VSOCK_TEST}" \
- --mode=client \
- --control-host="127.0.0.1" \
- --control-port="${port}" \
- --peer-cid=1 2>&1 | log_guest
+ if ! vm_vsock_test "127.0.0.1" 1 "${port}"; then
+ return "${KSFT_FAIL}"
+ fi
- return $?
+ return "${KSFT_PASS}"
}
run_test() {
--
2.47.3On Wed, Oct 22, 2025 at 06:00:07PM -0700, Bobby Eshleman wrote: > From: Bobby Eshleman <bobbyeshleman@meta.com> > > Add wrapper functions vm_vsock_test() and host_vsock_test() to invoke > the vsock_test binary. This encapsulates several items of repeat logic, > such as waiting for the server to reach listening state and > enabling/disabling the bash option pipefail to avoid pipe-style logging > from hiding failures. > > Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> shellcheck has some (new) things to say about this patch too. Could you take a look over them? ...
On Mon, Oct 27, 2025 at 04:58:02PM +0000, Simon Horman wrote: > On Wed, Oct 22, 2025 at 06:00:07PM -0700, Bobby Eshleman wrote: > > From: Bobby Eshleman <bobbyeshleman@meta.com> > > > > Add wrapper functions vm_vsock_test() and host_vsock_test() to invoke > > the vsock_test binary. This encapsulates several items of repeat logic, > > such as waiting for the server to reach listening state and > > enabling/disabling the bash option pipefail to avoid pipe-style logging > > from hiding failures. > > > > Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com> > > shellcheck has some (new) things to say about this patch too. > Could you take a look over them? > > ... No problem, will do. Thanks for the reviews! Best, Bobby
On Mon, Oct 27, 2025 at 11:01:36AM -0700, Bobby Eshleman wrote:
> On Mon, Oct 27, 2025 at 04:58:02PM +0000, Simon Horman wrote:
> > On Wed, Oct 22, 2025 at 06:00:07PM -0700, Bobby Eshleman wrote:
> > > From: Bobby Eshleman <bobbyeshleman@meta.com>
> > >
> > > Add wrapper functions vm_vsock_test() and host_vsock_test() to invoke
> > > the vsock_test binary. This encapsulates several items of repeat logic,
> > > such as waiting for the server to reach listening state and
> > > enabling/disabling the bash option pipefail to avoid pipe-style logging
> > > from hiding failures.
> > >
> > > Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
> >
> > shellcheck has some (new) things to say about this patch too.
> > Could you take a look over them?
> >
> > ...
>
It looks like the errors are SC2317 and SC2119, but are false-positives.
Invoking a program as a variable (e.g., "${VSOCK_TEST}") is tripping
SC2317 (command unreachable), and SC2119 is due to log_{guest,host}()
being passed zero arguments (logging its stdin instead).
I also see that SC2317 has many other false positives elsewhere in the
file (80+), reporting even lines like `rm "${QEMU_PIDFILE}"` as
unreachable. I wonder if we should add a patch to this series to disable
this check at the file-level?
Best,
Bobby
On Mon, Oct 27, 2025 at 12:08:48PM -0700, Bobby Eshleman wrote:
> On Mon, Oct 27, 2025 at 11:01:36AM -0700, Bobby Eshleman wrote:
> > On Mon, Oct 27, 2025 at 04:58:02PM +0000, Simon Horman wrote:
> > > On Wed, Oct 22, 2025 at 06:00:07PM -0700, Bobby Eshleman wrote:
> > > > From: Bobby Eshleman <bobbyeshleman@meta.com>
> > > >
> > > > Add wrapper functions vm_vsock_test() and host_vsock_test() to invoke
> > > > the vsock_test binary. This encapsulates several items of repeat logic,
> > > > such as waiting for the server to reach listening state and
> > > > enabling/disabling the bash option pipefail to avoid pipe-style logging
> > > > from hiding failures.
> > > >
> > > > Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
> > >
> > > shellcheck has some (new) things to say about this patch too.
> > > Could you take a look over them?
> > >
> > > ...
> >
>
> It looks like the errors are SC2317 and SC2119, but are false-positives.
> Invoking a program as a variable (e.g., "${VSOCK_TEST}") is tripping
> SC2317 (command unreachable), and SC2119 is due to log_{guest,host}()
> being passed zero arguments (logging its stdin instead).
Sorry about that, I thought I saw something meaningful in there.
I guess I was mistaken.
>
> I also see that SC2317 has many other false positives elsewhere in the
> file (80+), reporting even lines like `rm "${QEMU_PIDFILE}"` as
> unreachable. I wonder if we should add a patch to this series to disable
> this check at the file-level?
>
> Best,
> Bobby
>
On Wed, Oct 29, 2025 at 04:58:05PM +0000, Simon Horman wrote:
> On Mon, Oct 27, 2025 at 12:08:48PM -0700, Bobby Eshleman wrote:
> > On Mon, Oct 27, 2025 at 11:01:36AM -0700, Bobby Eshleman wrote:
> > > On Mon, Oct 27, 2025 at 04:58:02PM +0000, Simon Horman wrote:
> > > > On Wed, Oct 22, 2025 at 06:00:07PM -0700, Bobby Eshleman wrote:
> > > > > From: Bobby Eshleman <bobbyeshleman@meta.com>
> > > > >
> > > > > Add wrapper functions vm_vsock_test() and host_vsock_test() to invoke
> > > > > the vsock_test binary. This encapsulates several items of repeat logic,
> > > > > such as waiting for the server to reach listening state and
> > > > > enabling/disabling the bash option pipefail to avoid pipe-style logging
> > > > > from hiding failures.
> > > > >
> > > > > Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
> > > >
> > > > shellcheck has some (new) things to say about this patch too.
> > > > Could you take a look over them?
> > > >
> > > > ...
> > >
> >
> > It looks like the errors are SC2317 and SC2119, but are false-positives.
> > Invoking a program as a variable (e.g., "${VSOCK_TEST}") is tripping
> > SC2317 (command unreachable), and SC2119 is due to log_{guest,host}()
> > being passed zero arguments (logging its stdin instead).
>
> Sorry about that, I thought I saw something meaningful in there.
> I guess I was mistaken.
>
No problem at all, it brought my attention to shellcheck and the need
for exclusions, which I honestly did not know we used formally upstream.
Best,
Bobby
On Mon, 27 Oct 2025 12:08:48 -0700 Bobby Eshleman wrote:
> > > shellcheck has some (new) things to say about this patch too.
> > > Could you take a look over them?
>
> It looks like the errors are SC2317 and SC2119, but are false-positives.
> Invoking a program as a variable (e.g., "${VSOCK_TEST}") is tripping
> SC2317 (command unreachable), and SC2119 is due to log_{guest,host}()
> being passed zero arguments (logging its stdin instead).
>
> I also see that SC2317 has many other false positives elsewhere in the
> file (80+), reporting even lines like `rm "${QEMU_PIDFILE}"` as
> unreachable. I wonder if we should add a patch to this series to disable
> this check at the file-level?
Yes, FWIW, don't hesitate to disable things at the file level.
We should probably revisit which of the checks need to be disabled
globally. But file level is also useful for manual testing.
On Mon, Oct 27, 2025 at 04:22:44PM -0700, Jakub Kicinski wrote:
> On Mon, 27 Oct 2025 12:08:48 -0700 Bobby Eshleman wrote:
> > > > shellcheck has some (new) things to say about this patch too.
> > > > Could you take a look over them?
> >
> > It looks like the errors are SC2317 and SC2119, but are false-positives.
> > Invoking a program as a variable (e.g., "${VSOCK_TEST}") is tripping
> > SC2317 (command unreachable), and SC2119 is due to log_{guest,host}()
> > being passed zero arguments (logging its stdin instead).
> >
> > I also see that SC2317 has many other false positives elsewhere in the
> > file (80+), reporting even lines like `rm "${QEMU_PIDFILE}"` as
> > unreachable. I wonder if we should add a patch to this series to disable
> > this check at the file-level?
>
> Yes, FWIW, don't hesitate to disable things at the file level.
> We should probably revisit which of the checks need to be disabled
> globally. But file level is also useful for manual testing.
Got it, will do!
Thanks,
Bobby
© 2016 - 2026 Red Hat, Inc.