It looks like your main goal is to just clean up the lock? A more complete solution would need to run the cleanup stuff around test_hpts_free_tcpcb, right? I'm fine you prefer that be done in a follow up PR though.

BTW, does the fact that you are finding this problem mean this test case is failing for you somehow?

This revision is now accepted and ready to land.Mon, May 11, 2:18 PM

In D56943#1304269, @nickbanks_netflix.com wrote:

It looks like your main goal is to just clean up the lock? A more complete solution would need to run the cleanup stuff around test_hpts_free_tcpcb, right? I'm fine you prefer that be done in a follow up PR though.

Yeah, the immediately problem is that I occasionally get a kernel panic since witness detects that a thread returned to usermode while still holding a lock. Kernel panics during a test run are rather disruptive, so fixing that is my main goal.

BTW, does the fact that you are finding this problem mean this test case is failing for you somehow?

Very occasionally, it seems so. I haven't really dug into the failures: I run the test suite in parallel and that tends to cause some flakiness in timing-dependent tests. As a workaround I will re-run failed tests serially after the main test run, but I'm also trying to fix flaky tests when I have time.

Do more cleanup after a failure.

This revision now requires review to proceed.Mon, May 11, 2:42 PM

Harbormaster completed remote builds in B72981: Diff 177584.Mon, May 11, 2:42 PM

In D56943#1304273, @markj wrote:

Do more cleanup after a failure.

Eh, well, now I realize that the other KTEST macros don't handle this cleanup of the tcpcb etc., so it's kind of strange to do that in the _GOTO case.