On Fri, Feb 28, 2025 at 04:49:24PM +0100, Vlastimil Babka wrote: > On 2/28/25 13:13, Uladzislau Rezki (Sony) wrote: > > Add a test_kfree_rcu_wq_destroy test to verify a kmem_cache_destroy() > > from a workqueue context. The problem is that, before destroying any > > cache the kvfree_rcu_barrier() is invoked to guarantee that in-flight > > freed objects are flushed. > > > > The _barrier() function queues and flushes its own internal workers > > which might conflict with a workqueue type a kmem-cache gets destroyed > > from. > > > > One example is when a WQ_MEM_RECLAIM workqueue is flushing !WQ_MEM_RECLAIM > > events which leads to a kernel splat. See the check_flush_dependency() in > > the workqueue.c file. > > > > If this test does not emits any kernel warning, it is passed. > > Well the workqueue warning doesn't seem to make the test fail. But someone > will notice the warning, so that should be enough. We can't instrument > warnings in other subsystem's code for slub kunit context anyway. It would > have to be a generic kunit's hook for all warns. > I agree.
> > Reviewed-by: Keith Busch <kbu...@kernel.org> > > Co-developed-by: Vlastimil Babka <vba...@suse.cz> > > Signed-off-by: Uladzislau Rezki (Sony) <ure...@gmail.com> > > Pushed to slab/for-next, thanks. > Thanks! -- Uladzislau Rezki
