Re: [PATCH v5 13/17] rv: Add KUnit mock for current

Wen Yang <[email protected]> Sun, 2 Aug 2026 13:26:06 +0800
Newsgroups org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 8/2/26 12:55, Wen Yang wrote:
> 
> 
> On 7/30/26 13:13, Gabriele Monaco wrote:
>>
>>
>> Il 29 luglio 2026 18:17:31 UTC, Wen Yang <[email protected]> ha scritto:
>>
>>>> +#define rv_get_current() (unlikely(kunit_get_current_test()) ? 
>>>> rv_get_mock_current() : current)
>> ...
>>
>>>> +/*
>>>> + * rv_get_mock_current() is called only if we are running from a 
>>>> KUnit test.
>>>> + * This can occur from a legitimate RV test or any unrelated test 
>>>> running when
>>>> + * a real RV monitor is active and triggering events.
>>>> + * We assume the former case is the only one where mock_current is 
>>>> not NULL and
>>>> + * can occur only sequentially (KUnit doesn't run tests in parallel).
>>>> + * We cannot rely on the test's context because there is no way to 
>>>> safely
>>>> + * understand from which test we are running and KUnit utilities 
>>>> require
>>>> + * locking, which is unsafe from NMI or scheduling context.
>>>> + * Note that it is not possible for a real RV monitor to run when 
>>>> the RV KUnit
>>>> + * tests are running (see rv_set_testing()).
>>>> + */
>>>> +static struct task_struct *mock_current;
>>>> +
>>>> +void rv_mock_current(struct task_struct *tsk)
>>>> +{
>>>> +    mock_current = tsk;
>>>> +}
>>>> +EXPORT_SYMBOL_IF_KUNIT(rv_mock_current);
>>>> +
>>>> +struct task_struct *rv_get_mock_current(void)
>>>> +{
>>>> +    return mock_current ?: current;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(rv_get_mock_current);
>>>>    #endif
>>>
>>> rv_mock_current() uses EXPORT_SYMBOL_IF_KUNIT, but 
>>> rv_get_mock_current() uses EXPORT_SYMBOL_GPL. Both are defined inside 
>>> the same CONFIG_RV_MONITORS_KUNIT_TEST block, so rv_get_mock_current 
>>> should use EXPORT_SYMBOL_IF_KUNIT as well, otherwise it leaks a 
>>> test-only symbol into production builds.
>>>
>>> With that fixed:
>>> Reviewed-by: Wen Yang <[email protected]>
>>
>> Thanks for the review.
>> This was intentional however: rv_get_current() can be called by any 
>> monitor, those don't have to be KUnit.
>> Since rv_get_current() is a macro also calling rv_get_mock_current() 
>> we need to be able to link that too.
>>
>> The idea is that a "real" (non-kunit) monitor handler could be run 
>> when interrupting a KUnit test (not an RV one, we make sure of that). 
>> In that case we do call rv_get_mock_current() and return current after 
>> the function call.
>>
>> rv_mock_current() CANNOT be called outside of the RV KUnit test cases, 
>> it uses a global variable (for problems I tried to explain in the 
>> comment), so should be exported only to KUnit and called directly from 
>> the test case.
>>
>> Does it make sense to you?
>>
> 
> Thanks for the explanation.
> That does make sense.
> 
> One small thought though -- the kernel already provides 
> KUNIT_STATIC_STUB_REDIRECT as the idiomatic way to handle this kind of 
> pattern. It allows a production function to be transparently redirected 
> to a stub during KUnit tests, with zero overhead when no test is running 
> (since it uses the same static_branch_unlikely(&kunit_running) path as 
> kunit_get_current_test()).
> 
> This might be a cleaner fit here, since it avoids exporting 
> rv_mock_current() beyond KUnit and keeps the redirection logic internal 
> to the test harness.
> 
> Just wanted to throw that out there -- what do you think?
> 

I apologize for the noise.  After reading the V5 commit notes more 
carefully:

   * Drop static stub from current to avoid issues with unrelated KUnit 
tests

it is clear that KUNIT_STATIC_STUB_REDIRECT was already considered and 
deliberately dropped.  Kunit_find_resource() may acquires 
spin_lock_irqsave, which does not mask NMIs; using the static stub in an 
NMI-reachable path would risk deadlock.

This patch is the correct choice, and the comment in rv.c explains 
exactly why.


Reviewed-by: Wen Yang <[email protected]>


--
Best wishes,
Wen


> 
> 
> -- 
> Best wishes,
> Wen
> 
> 
> 
> 
>