Skip to content

test_net_shortwrite: Ensure connection can succeed

The attached patch allows Knot's test suite to complete on Linux on Aarch64 (and perhaps elsewhere) by modifying tests/contrib/test_net_shortwrite.c to ensure the connection it makes between a client and server can succeed, by deepening the server's pending-connection queue from 0 to 1.

0001-test_net_shortwrite-ensure-connection-can-succeed.patch

On my x86_64 Linux machine, Knot 3.0.0 builds and tests without issue. On my Aarch64 machine, the code builds but the test_net_shortwrite test suite fails:

ok 1 - server: bind socket
ok 2 - server: start listening
ok 3 - server: get bound address
ok 4 - client: connect to server
ok 5 - client: configure small send buffer
ok 6 - server: start receiver thread
not ok 7 - client: net_dns_tcp_send() with short-write
ok 8 - server: wait for receiver thread to terminate
not ok 9 - server: net_dns_tcp_recv() complete and valid data
1..9
# Looks like you failed 2 tests of 9

It turns out the connection never completes between the client and server, leading to a timeout while the client waits to send data. The fix is to change the second, "backlog" argument of the call to listen() on line 91 from zero to one:

r = listen(server, 1);

Intuitively, it seems 1 is the correct value here. The documentation for listen() says

The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow.

So a value of zero would seem to prevent any connection attempt from succeeding, and this is the behaviour I'm seeing on Aarch64. On the other hand, POSIX says

A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may be set to an implementation-defined minimum value.

So Linux seems inconsistent on this point: On some platforms or in some configurations, a backlog value of zero disallows any connections; elsewhere, it allows an arbitrary, minimum number of simultaneous connection attempts to succeed, per POSIX's suggestion.

In either case, allowing a single pending connection request makes sense in the context of this test suite, and should prevent the test from failing arbitrarily on non-Intel platforms.