From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D0E6C021B3 for ; Fri, 21 Feb 2025 17:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90A2628001A; Fri, 21 Feb 2025 12:28:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 89203280016; Fri, 21 Feb 2025 12:28:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BDCE28001A; Fri, 21 Feb 2025 12:28:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4A5C3280016 for ; Fri, 21 Feb 2025 12:28:56 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E9608C1B0E for ; Fri, 21 Feb 2025 17:28:55 +0000 (UTC) X-FDA: 83144637030.26.30B7A8D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf11.hostedemail.com (Postfix) with ESMTP id 547274001A for ; Fri, 21 Feb 2025 17:28:53 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=GNkqfTTI; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="C/Wjbu4m"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=AFnBheAX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=jsiLccSJ; spf=pass (imf11.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740158933; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CsRD3Ev6tUSwaFtN40VJ1v7re9buaBfAHoPVv5PtZKo=; b=qW9NSSj33g4hfXbq0lscx9Hq1/82HQxYcdEnqdp7rOihH7e5vN9UY0AYSwfGqCAgum10Tf Y7Q6GWwZ05ZjAdL06jxZU6bE2Xh01Xqj4V8KXoycomD9DgMGmRAU6LEYVhK8vYVRupKM9d q4+2Cuu1pmw4IS/mxVoLOzxCdJph+gI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=GNkqfTTI; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="C/Wjbu4m"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=AFnBheAX; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=jsiLccSJ; spf=pass (imf11.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740158933; a=rsa-sha256; cv=none; b=erKTebUihVCBafNJsHtAcU5t+J5LwQ4DZd+4Hx8/abjQG3Smk1K2p22UcXNsWCCyjrZIFB 9OkQ0nPzFL9x7Edqwj8oF76EH5R2XZyQZzK8wAFRfujGjDcrjLlPAHkDNFVkjkcZgq7pMO q1Og7ZoOplLoBIM5VvoFdY8nxZWlltY= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 91FCC21E2C; Fri, 21 Feb 2025 17:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740158931; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=CsRD3Ev6tUSwaFtN40VJ1v7re9buaBfAHoPVv5PtZKo=; b=GNkqfTTIr1MHiz493ajnjU8qFBKIb/4EwDHWeZJox7iJZLKDXJ1EuFQ+HZ1hnKmevtDdlz aHivrFGMwrAZccfpN6JJ9A9bzXjotkA4Fa+5epDGxY9B3WXF0h2Sp6N9R+9+etqwd0HoZ8 kOcWY29E95X1I/nE67m7OuGm7InmZ/c= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740158931; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=CsRD3Ev6tUSwaFtN40VJ1v7re9buaBfAHoPVv5PtZKo=; b=C/Wjbu4mbSFAKVoh9ZwOhpbIdhVFUd/MPjcPd4keEoT2cjtsXfdSxU3JurhK3sPtPbHD/Y WyKaDCRYKuRXtjAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740158930; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=CsRD3Ev6tUSwaFtN40VJ1v7re9buaBfAHoPVv5PtZKo=; b=AFnBheAXjBhOwgouqq1t851ELXa4GB+F1xRIZpSgbLT6OzcKo/rbmvxT2D5JCm7EPbaN1U VV/OMdPkVQQuSHH9b/ivhYCBaNt/L4r1JDiAWVi9Y0cQzrS+GDBM0qWYN3ghpckLuxa7Sj 7c/oRg+CU3j2TZWDKJSKLbrv4+YMfb8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740158930; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=CsRD3Ev6tUSwaFtN40VJ1v7re9buaBfAHoPVv5PtZKo=; b=jsiLccSJTnHLjfOLDWAMM6mqN8f52arpaURKXMqMqNmQV1zEJAi9DYo+UddOcZkeZJ6/Tj JucGgdgh0hOOoPDg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 5391E13806; Fri, 21 Feb 2025 17:28:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id RDZvE9K3uGekQgAAD6G6ig (envelope-from ); Fri, 21 Feb 2025 17:28:50 +0000 Message-ID: <2811463a-751f-4443-9125-02628dc315d9@suse.cz> Date: Fri, 21 Feb 2025 18:28:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 6/7] mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy() Content-Language: en-US To: Keith Busch Cc: "Paul E. McKenney" , Joel Fernandes , Josh Triplett , Boqun Feng , Christoph Lameter , David Rientjes , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Julia Lawall , Jakub Kicinski , "Jason A. Donenfeld" , "Uladzislau Rezki (Sony)" , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, Alexander Potapenko , Marco Elver , Dmitry Vyukov , kasan-dev@googlegroups.com, Jann Horn , Mateusz Guzik , linux-nvme@lists.infradead.org, leitao@debian.org References: <20240807-b4-slab-kfree_rcu-destroy-v2-0-ea79102f428c@suse.cz> <20240807-b4-slab-kfree_rcu-destroy-v2-6-ea79102f428c@suse.cz> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 547274001A X-Stat-Signature: 416t6nuhg7h8cgh3y8dpintdf5t8taqa X-Rspam-User: X-HE-Tag: 1740158933-598500 X-HE-Meta: U2FsdGVkX1/JhI/QLSxv3N0/237iJEfkXFkObYTjUxj0IvnQd/5sW+qgaNXoQsH4Hp2lRcGn9rQvGla2V7nVku7Zmn49d5y+m6k8u1Fnalrrv/h+YG5yj/7HJlJh1abfHtJ3rsNSQoPU0FlrdigNhU7PVHgtJAHmnhVWilaWpNsAK4yNgSey3U2pBYeqsezu2yNvLrykNdVSBhNpZQRGLpC76SDStMdIhbW2fyUWEYrnEsAGpsRRr9LX5pevjWMc397P/l2REw4/Sn20+jiDAJQ6RVg2cinWpGHpFHpIxsJOOQTa57CyLg0Os02Sk3JanMEq4qIn03ogD7fwpe7QAQP37J7xnnkeKqoxn4Ty9T5z8HEDJkIMH/lXAijcXSSdGSdDio1Iev/hMmiOKenUSdFoObUzORw7KF/NXddaYx9YWp5lEkLsPrF2QHlY8572wQXrorwHBe3wx07grOsmjad09+3FBEa7+2M5d2KZMHTnPkoKYrk7ZcQjpQZQ2cKoJPIBXH66xtHafDV4oh1BE99fVaRUTTbD975CboqgZHRtWzXHh2M99dksG3IX3sGfRBONgXniXcdLTePiLUIfoH0hVPzYXqx+Rh1nRO2tPJbNRTiaGLyBfLqObIFFCiREXN4AY1zg98xaRtgcechaid5UYVajAzx4AUGbrFJ13T3LM6MI7lLVqqg7xldwGpHTZS+aUvY9fYV4K3Lu/18CiT5aOaH06TcmDrMvlkheBwEi9pkoqEWw5mDT1SOfQ0ktA0336OKxMXz4CZNkHkfjNo+UJHRrOaLO0n3b6cKs3lzbbcDYxTJk8EdiV/BwcMOnRgNuYETiFKgbosEc1tjDW+Ic/I6hmsHnu6yyWTyTXdIwpBQIjmrhHXf1kXirNhRYc8NnFWAu7gNTwSmvFOK6/xxo2uR5Kuk7RBHWaLsGm4WswK29hw7ZGAUIjBrXyv9sMXxq2xWiKfj9KfegxWG 2FZ4s4b4 Egyn+ky0tCOWlLSmmryoW/cDeUeKzaHLtJ/KywlIPEtOaAyRiK7ozoWADeg85Pwu22O8Xg8IdAmdmAcbJF98GyzCf6urP29I2wFdh+K7cFPKrmMtrOalzIXllLyycF07DDkCx4gtc98YA5nVZueEfaCm6NcT6QOOPUN/XofOrMDe4CpKZnE40R2fYoEpMNKCOjp6rpIV+bBHqnehau3cdn5CLpRsGci+poKgIxjogNGFYVBscK4c3Hd1rMRmXshX3hPPo02lT20/O8xUFA9kOORYgLZ8p9fI6hFFvZmNFPWX088zm6iO7wmWec4grX+9Nl1oczkuBUqVUXE+n/HhwGv6bkQHChtuhnjQiZhlD31YEzkweG8vAe7hVJYSNkiJ12IO57gBhAOWlIw/yqUFNDD5pEg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2/21/25 17:30, Keith Busch wrote: > On Wed, Aug 07, 2024 at 12:31:19PM +0200, Vlastimil Babka wrote: >> We would like to replace call_rcu() users with kfree_rcu() where the >> existing callback is just a kmem_cache_free(). However this causes >> issues when the cache can be destroyed (such as due to module unload). >> >> Currently such modules should be issuing rcu_barrier() before >> kmem_cache_destroy() to have their call_rcu() callbacks processed first. >> This barrier is however not sufficient for kfree_rcu() in flight due >> to the batching introduced by a35d16905efc ("rcu: Add basic support for >> kfree_rcu() batching"). >> >> This is not a problem for kmalloc caches which are never destroyed, but >> since removing SLOB, kfree_rcu() is allowed also for any other cache, >> that might be destroyed. >> >> In order not to complicate the API, put the responsibility for handling >> outstanding kfree_rcu() in kmem_cache_destroy() itself. Use the newly >> introduced kvfree_rcu_barrier() to wait before destroying the cache. >> This is similar to how we issue rcu_barrier() for SLAB_TYPESAFE_BY_RCU >> caches, but has to be done earlier, as the latter only needs to wait for >> the empty slab pages to finish freeing, and not objects from the slab. >> >> Users of call_rcu() with arbitrary callbacks should still issue >> rcu_barrier() before destroying the cache and unloading the module, as >> kvfree_rcu_barrier() is not a superset of rcu_barrier() and the >> callbacks may be invoking module code or performing other actions that >> are necessary for a successful unload. >> >> Signed-off-by: Vlastimil Babka >> --- >> mm/slab_common.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/mm/slab_common.c b/mm/slab_common.c >> index c40227d5fa07..1a2873293f5d 100644 >> --- a/mm/slab_common.c >> +++ b/mm/slab_common.c >> @@ -508,6 +508,9 @@ void kmem_cache_destroy(struct kmem_cache *s) >> if (unlikely(!s) || !kasan_check_byte(s)) >> return; >> >> + /* in-flight kfree_rcu()'s may include objects from our cache */ >> + kvfree_rcu_barrier(); >> + >> cpus_read_lock(); >> mutex_lock(&slab_mutex); > > This patch appears to be triggering a new warning in certain conditions > when tearing down an nvme namespace's block device. Stack trace is at > the end. > > The warning indicates that this shouldn't be called from a > WQ_MEM_RECLAIM workqueue. This workqueue is responsible for bringing up > and tearing down block devices, so this is a memory reclaim use AIUI. > I'm a bit confused why we can't tear down a disk from within a memory > reclaim workqueue. Is the recommended solution to simply remove the WQ > flag when creating the workqueue? I think it's reasonable to expect a memory reclaim related action would destroy a kmem cache. Mateusz's suggestion would work around the issue, but then we could get another surprising warning elsewhere. Also making the kmem_cache destroys async can be tricky when a recreation happens immediately under the same name (implications with sysfs/debugfs etc). We managed to make the destroying synchronous as part of this series and it would be great to keep it that way. > ------------[ cut here ]------------ > workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work Maybe instead kfree_rcu_work should be using a WQ_MEM_RECLAIM workqueue? It is after all freeing memory. Ulad, what do you think? > WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 > Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) skx_edac_common(E) nfit(E) libnvdimm(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) iTCO_wdt(E) xhci_pci(E) mlx5_ib(E) ipmi_si(E) iTCO_vendor_support(E) i2c_i801(E) ipmi_devintf(E) evdev(E) kvm(E) xhci_hcd(E) ib_uverbs(E) acpi_cpufreq(E) wmi(E) i2c_smbus(E) ipmi_msghandler(E) button(E) efivarfs(E) autofs4(E) > CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G E 6.13.2-0_g925d379822da #1 > Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023 > Workqueue: nvme-wq nvme_scan_work > RIP: 0010:check_flush_dependency+0x112/0x120 > Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 c7 c7 90 64 5a 82 49 89 d8 e8 7e 4f 88 ff <0f> 0b eb 8c cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 41 57 41 > RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 > RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 > RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 > RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd > R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 > R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000 > FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 > CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 > PKRU: 55555554 > Call Trace: > > ? __warn+0xa4/0x140 > ? check_flush_dependency+0x112/0x120 > ? report_bug+0xe1/0x140 > ? check_flush_dependency+0x112/0x120 > ? handle_bug+0x5e/0x90 > ? exc_invalid_op+0x16/0x40 > ? asm_exc_invalid_op+0x16/0x20 > ? timer_recalc_next_expiry+0x190/0x190 > ? check_flush_dependency+0x112/0x120 > ? check_flush_dependency+0x112/0x120 > __flush_work.llvm.1643880146586177030+0x174/0x2c0 > flush_rcu_work+0x28/0x30 > kvfree_rcu_barrier+0x12f/0x160 > kmem_cache_destroy+0x18/0x120 > bioset_exit+0x10c/0x150 > disk_release.llvm.6740012984264378178+0x61/0xd0 > device_release+0x4f/0x90 > kobject_put+0x95/0x180 > nvme_put_ns+0x23/0xc0 > nvme_remove_invalid_namespaces+0xb3/0xd0 > nvme_scan_work+0x342/0x490 > process_scheduled_works+0x1a2/0x370 > worker_thread+0x2ff/0x390 > ? pwq_release_workfn+0x1e0/0x1e0 > kthread+0xb1/0xe0 > ? __kthread_parkme+0x70/0x70 > ret_from_fork+0x30/0x40 > ? __kthread_parkme+0x70/0x70 > ret_from_fork_asm+0x11/0x20 > > ---[ end trace 0000000000000000 ]---