On Tue, Jul 29, 2025 at 01:48:02AM +0200, Pablo Neira Ayuso wrote:
> Would you rework this to a more elaborated torture test that exercises
> both commit and abort path?
>
> It would be great to have something similar to
> nftables/tests/shell/testcases/transactions/30s-stress
> but to exercise loop detection.
I can, but I would see it as an additional stress test, where as the
existing test are more unit like, and test the sysctl for discrete
behavior.
Regarding the commit/abort paths, I ended up (in my testing, not the
final code) temporarily changing:
if (status & NFNL_BATCH_FAILURE)
abort_action = NFNL_ABORT_NONE;
else
abort_action = NFNL_ABORT_VALIDATE;
to
if (status & NFNL_BATCH_FAILURE)
abort_action = NFNL_ABORT_VALIDATE;
else
abort_action = NFNL_ABORT_VALIDATE;
to run over the validate path during an abort (as above, a batch failure
won't do it). Would the else path be caused by an abort message from
the client, as in a Ctrl+C? Is there a prescribed way to inject this
kind of fault as to naturally run over the path?
Further, are you wanting to test/stress the ability of transactions
(both committing and aborting) to intermingle/coexist/coordinate (at a
glance I don't see tests for that in the kernel tree), or specifically
the validation code in those paths?
Assuming it's just the validation code, roughly, would the following be
what you're thinking:
create N random nft input files, one part being valid commits, the
other with aborts injected.
Set the jump sysctl limit
Loop over the randon input files
if valid
we can or can not add jumps as expected by the limit (and included jumps)
else (abort)
we should be able not not add jumps as per the LAST file (we rolled back successfully)
Want to make sure I'm not imagining the wrong thing.
Thanks!
SB
