Re: [tcp] f859a44847: stderr.fastopen-client.pkt:#:runtime_error_in_sendto_call:Expected_result#but_got-#with_errno#(Operation_now_in_progress)

[Willem de Bruijn]

On Tue, Nov 12, 2019 at 10:04 PM kernel test robot
<rong.a.chen@xxxxxxxxx> wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: f859a448470304135f7a1af0083b99e188873bb4 ("tcp: allow zerocopy with fastopen")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: packetdrill
> with following parameters:
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):

The report shows the complete output of a complete packetdrill run.
>From that it is not immediately obvious which packetdrill test output
changed.

The subject line calls out tcp/zerocopy/fastopen-client.pkt. The
result of that test are expected to change with this commit
f859a4484703 ("tcp: allow zerocopy with fastopen"), because this test
was added exactly to verify the feature introduced with that commit.

The report shows this specific test passing for ipv4 and
ipv4-mapped-v6. I cannot explain why that run failed for ipv6. On my
runs all three pass at this commit:

  $ git clone https://github.com/google/packetdrill
  $ cd packetdrill/gtests/net
  $ (cd packetdrill; make)
  $ ./packetdrill/run_all.py tcp/zerocopy
  Ran   33 tests:   33 passing,    0 failing,    0 timed out (7.28
sec): tcp/zerocopy

and fail on the previous commit, along with all three versions of
fastopen-server.pkt and closed.pkt:

  $ ./packetdrill/run_all.py tcp/zerocopy
  Ran   33 tests:   24 passing,    9 failing,    0 timed out (7.22
sec): tcp/zerocopy

All this is expected, so there is nothing to fix for this report.

This was on a kernel built with `make defconfig; make kvmconfig` and
additionally CONFIG_TUN=y. Though those details should be immaterial
here.

Great that the test robot is running packetdrill tests, btw! Good to
know we upstreamed them for a reason.

But how did it end up testing such an old kernel? This commit was added in 5.1.