Re: [PATCH for-next v3 2/9] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs
Pedro Falcato <[email protected]>
| Newsgroups | org.kernel.vger.rcu,dev.linux.lists.linux-rt-devel,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <ajvczSpMOGWFhe30@pedro-suse> |
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