Page MenuHomeFreeBSD

tftpd: Address flaky tests
ClosedPublic

Authored by markj on Nov 2 2024, 4:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 12, 3:06 AM
Unknown Object (File)
Sun, Dec 8, 11:39 PM
Unknown Object (File)
Sat, Nov 30, 7:49 PM
Unknown Object (File)
Tue, Nov 26, 8:44 PM
Unknown Object (File)
Thu, Nov 21, 7:43 PM
Unknown Object (File)
Sat, Nov 16, 10:57 AM
Unknown Object (File)
Nov 9 2024, 12:48 PM
Unknown Object (File)
Nov 9 2024, 12:45 PM
Subscribers

Details

Summary

The tftpd tests all follow the same pattern:

  1. open a udp socket
  2. fork a child to exec tftpd, which subsequently handles requests on the socket
  3. use a client socket to send some message to the tftpd daemon

However, tftpd's first action is to mark its socket as non-blocking and
then read a request from it. If no data is present in the socket, tftpd
exits immediately with an error. So, there is a race; we often see
tftpd test timeouts when running tests in parallel. These timeouts also
arise periodically in CI.

One solution is to restructure the tests to create the server socket,
then write the request to the client socket, then fork tftpd. This
closes the race. However, this involves a lot of churn.

This patch fixes the problem a different way, by adding a new -b flag to
tftpd which makes it block for the initial request. I think this may be
acceptable as an alternative, and does not require extensive
restructuring of each tftpd test.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Nov 2 2024, 4:58 PM

Kinda ugly, but fine given our test suite runs tftpd in an unusual way.

This revision is now accepted and ready to land.Nov 2 2024, 5:06 PM

I agree. I can see a couple of other ways to fix this problem, but none are as easy as Mark's.

This revision was automatically updated to reflect the committed changes.