From nobody Mon Apr 6 09:48:17 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B069BC38145 for ; Thu, 8 Sep 2022 09:11:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230377AbiIHJLD (ORCPT ); Thu, 8 Sep 2022 05:11:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231737AbiIHJKv (ORCPT ); Thu, 8 Sep 2022 05:10:51 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C698A99B7D; Thu, 8 Sep 2022 02:10:41 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 67D6622AE9; Thu, 8 Sep 2022 09:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1662628240; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=TxW0nswTE1xcIJ8762DBIkIeOfhvNnUbpYK3mr2ADcA=; b=omOTbZnG7ZtT/+msLgPFiupSzqzfz6PWf0ZQzyxsFvr+2w41Ovp5KbqnsO2nSPmK5atgqf XA1PeM6WBHR8k7y3u9CIY2NRE5GCUZCn7O2NG5RoI9/NM88Kzoy0RW9PSNY0ZBICwGc0Ii byZwKXbeOzfsDd2ogPZTwt/lotlKJ3w= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1662628240; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=TxW0nswTE1xcIJ8762DBIkIeOfhvNnUbpYK3mr2ADcA=; b=mBBSmJSDnX2+tMF/6jNewVNM2OLQE8EZ3WWhaspIV6rFaUTlJLnckb3cZlzzmveU/7aKLN 3E6QQBa8KKatrfBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 5BDAA13A6D; Thu, 8 Sep 2022 09:10:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ualkFpCxGWPWPwAAMHmgww (envelope-from ); Thu, 08 Sep 2022 09:10:40 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id E48C1A067E; Thu, 8 Sep 2022 11:10:39 +0200 (CEST) From: Jan Kara To: Ted Tso Cc: , Mike Galbraith , Sebastian Andrzej Siewior , LKML , Jan Kara Subject: [PATCH] mbcache: Avoid nesting of cache->c_list_lock under bit locks Date: Thu, 8 Sep 2022 11:10:32 +0200 Message-Id: <20220908091032.10513-1-jack@suse.cz> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2089; h=from:subject; bh=dRJj3j9qfjEl6wYp/YsGfWVb12vOG36l+ern9zbLpCQ=; b=owEBbQGS/pANAwAIAZydqgc/ZEDZAcsmYgBjGbGC9duuau5H/8u1XvR/jnI288SB12rOUZo41awT Mr3qGX+JATMEAAEIAB0WIQSrWdEr1p4yirVVKBycnaoHP2RA2QUCYxmxggAKCRCcnaoHP2RA2VC4CA DSr6mnDQ+GmRI+9UKxbEX6oPTOMrtelKFNhJ6dGLD/AuClpviLsxHcQrJFTSSKfOQb9jHpD/f4mQbB 9hmkpA6NnNaOVxkooLs8khFseUVaH2m3q/sND/Lxh2e705O429Tmt1i+5wp175Y3anzV6V7IA+cdm0 U963MgZusPasmH78DdAXEC32I5Z3TcQnbVSR0jSB4hH8sTVvYm1mJ5q++sVcuaWUSP/vO4HA8zMOqT t+jwOULBptCfgsx3jGM2/y8NGBMAE6Xvu42d3jlWLcqX1dKxcffgIaWIXXNewVWJ59gt6hGI8uUo7k Pwuqt7qw86iRm9BkGYo+hZu/ZhSZuC X-Developer-Key: i=jack@suse.cz; a=openpgp; fpr=93C6099A142276A28BBE35D815BC833443038D8C Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Commit 307af6c87937 ("mbcache: automatically delete entries from cache on freeing") started nesting cache->c_list_lock under the bit locks protecting hash buckets of the mbcache hash table in mb_cache_entry_create(). This causes problems for real-time kernels because there spinlocks are sleeping locks while bitlocks stay atomic. Luckily the nesting is easy to avoid by holding entry reference until the entry is added to the LRU list. This makes sure we cannot race with entry deletion. Fixes: 307af6c87937 ("mbcache: automatically delete entries from cache on f= reeing") Reported-by: Mike Galbraith Signed-off-by: Jan Kara --- fs/mbcache.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/fs/mbcache.c b/fs/mbcache.c index 47ccfcbe0a22..e272ad738faf 100644 --- a/fs/mbcache.c +++ b/fs/mbcache.c @@ -90,8 +90,14 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t = mask, u32 key, return -ENOMEM; =20 INIT_LIST_HEAD(&entry->e_list); - /* Initial hash reference */ - atomic_set(&entry->e_refcnt, 1); + /* + * We create entry with two references. One reference is kept by the + * hash table, the other reference is used to protect us from + * mb_cache_entry_delete_or_get() until the entry is fully setup. This + * avoids nesting of cache->c_list_lock into hash table bit locks which + * is problematic for RT. + */ + atomic_set(&entry->e_refcnt, 2); entry->e_key =3D key; entry->e_value =3D value; entry->e_reusable =3D reusable; @@ -106,15 +112,12 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp= _t mask, u32 key, } } hlist_bl_add_head(&entry->e_hash_list, head); - /* - * Add entry to LRU list before it can be found by - * mb_cache_entry_delete() to avoid races - */ + hlist_bl_unlock(head); spin_lock(&cache->c_list_lock); list_add_tail(&entry->e_list, &cache->c_list); cache->c_entry_count++; spin_unlock(&cache->c_list_lock); - hlist_bl_unlock(head); + mb_cache_entry_put(cache, entry); =20 return 0; } --=20 2.35.3