Re: [PATCH for-next v3 2/9] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs

[Pedro Falcato <pfalcato@suse.de>]

On Mon, Jun 15, 2026 at 08:05:56PM +0900, Harry Yoo (Oracle) wrote:
> Since kmalloc_nolock() always fails in NMI and hardirq contexts on
> PREEMPT_RT, slub_kunit cannot properly test _nolock() APIs.
> 
> Register a kprobe pre-handler to invoke kmalloc_nolock() and
> kfree_nolock() in the middle of the slab allocator. However, do not
> register the handler on UP kernels [1].

Maybe explain in the commit message why that is?
 
> To attach the pre-handler while s->cpu_sheaves->lock or n->list_lock
> is held, add a wrapper function for lockdep_assert_held() that calls
> a no-op function slab_attach_kprobe_locked() on debug builds. The

Why lockdep? Wouldn't it make more sense to add these triggers after
locking these locks?

> function is optimized away when neither CONFIG_PROVE_LOCKING nor
> CONFIG_DEBUG_VM is selected and register_kprobe() fails.
> 
> The function calls barrier() to prevent the compiler from optimizing
> away its callsites. Otherwise, the compiler may consider the function
> does not have any side effect and remove callsites.

My wider comment is the following: this looks very useful but perhaps should
be lifted to Kunit itself? There's already function redirection (which could
be used for this as well). I don't know if that suits your purposes?
Choosing to say "I want to hook this random function using kprobe and give
it custom behavior" sounds lovely for all sorts of testing.

-- 
Pedro