linux-kernel - Re: [PATCH v1 1/2] kunit, slub: Add test_kfree_rcu_wq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b97fdb00-6367-4eec-87cd-47f6765fd2cc@suse.cz>
Date: Fri, 28 Feb 2025 16:49:24 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: "Uladzislau Rezki (Sony)" <urezki@...il.com>, linux-mm@...ck.org,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: RCU <rcu@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
 Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
 David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>,
 Roman Gushchin <roman.gushchin@...ux.dev>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>,
 Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
 Keith Busch <kbusch@...nel.org>
Subject: Re: [PATCH v1 1/2] kunit, slub: Add test_kfree_rcu_wq_destroy use
 case

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.

> Reviewed-by: Keith Busch <kbusch@...nel.org>
> Co-developed-by: Vlastimil Babka <vbabka@...e.cz>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>

Pushed to slab/for-next, thanks.