Re: [RFC PATCH 10/12] rv: Add KUnit tests for some DA/HA monitors

[Gabriele Monaco]

On Mon, 2026-05-04 at 15:33 +0200, Nam Cao wrote:
> I added that missing RV_KUNIT_EXPECT_REACTION(), but I still see a test
> failure:
> 
> [    1.070721]     # module: rv_monitors_test
> [    1.073512]     1..7
> [    1.077641] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     2.5+
> PQ: 0 ANSI: 5
> [    1.078494]     ok 1 rv_test_sco
> [    1.083256]     ok 2 rv_test_sssw
> [    1.085783]     ok 3 rv_test_sts # SKIP Monitor not enabled
> [    1.092365]     ok 4 rv_test_opid
> [    1.093462]     # rv_test_nomiss: EXPECTATION FAILED at
> kernel/trace/rv/monitors/nomiss/nomiss.c:306
> [    1.093462]     Expected ctx->reactions == ++ctx->expected, but
> [    1.093462]         ctx->reactions == 2 (0x2)
> [    1.093462]         ++ctx->expected == 1 (0x1)
> [    1.095699]     not ok 5 rv_test_nomiss
> [    1.109418]     ok 6 rv_test_pagefault # SKIP Monitor not enabled
> [    1.115146]     ok 7 rv_test_sleep # SKIP Monitor not enabled
> [    1.118050] # rv_trigger: pass:3 fail:1 skip:3 total:7
> [    1.118053] # Totals: pass:3 fail:1 skip:3 total:7
> [    1.120622] not ok 1 rv_trigger
> 
> Any idea why?

The nomiss test is broken, it was not failing by sheer luck, maybe your run was
not lucky.

Basically a few silly mistakes like using deadline instead of dl_deadline (which
is left uninitialised) and doing udelay(10 / 1000) (which is 0).

I'm going to fix it in V2.

> > So I'm actually thinking of defining yet another macro that fundamentally
> > does
> > 
> > RV_KUNIT_EXPECT_NO_REACTION()
> > handle_event()
> > RV_KUNIT_EXPECT_REACTION()
> > 
> > which would make sure the reaction happens exactly there, plus I'd add an
> > RV_KUNIT_EXPECT_NO_REACTION() in the cleanup sequence to ensure no
> > unexpected
> > reaction occurred (or nobody forgot to expect a reaction like I did above).
> 
> Sounds nice, go for it.
> 
> > Yeah that should be neater, but weren't you the one not liking macros? ;)
> 
> It's not black and white, I like whatever makes the code clean and easy
> to read. Sometimes macros are nice, other times not so much. I have
> spent hours reading the tracepoints' macros and they are still black
> magic to me (but to be fair, macros are probably the best we can do for
> that case). I hope we can rewrite those in Rust's generic one day.

Yeah makes sense, tracepoints are a fun one indeed.
Rust would probably be black magic to me but I'm going to have to learn it for
good one day!

Thanks,
Gabriele