Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9f593b8ac1b731cbbf92dc1c7b497b668752b325.camel@gmx.de>
Subject: 307af6c879377 "mbcache: automatically delete entries from cache on
 freeing" ==> PREEMPT_RT grumble
From:   Mike Galbraith <efault@gmx.de>
To:     Jan Kara <jack@suse.cz>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue, 06 Sep 2022 18:21:37 +0200
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Jan,

diff --git a/fs/mbcache.c b/fs/mbcache.c
index d1ebb5df2856..96f1d49d30a5 100644
=2D-- a/fs/mbcache.c
+++ b/fs/mbcache.c
@ -106,21 +106,28 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp=
_t mask, u32 key,
 		}
 	}
 	hlist_bl_add_head(&entry->e_hash_list, head);
-	hlist_bl_unlock(head);
-
+	/*
+	 * Add entry to LRU list before it can be found by
+	 * mb_cache_entry_delete() to avoid races
+	 */
 	spin_lock(&cache->c_list_lock);
 	list_add_tail(&entry->e_list, &cache->c_list);
-	/* Grab ref for LRU list */
-	atomic_inc(&entry->e_refcnt);
 	cache->c_entry_count++;
 	spin_unlock(&cache->c_list_lock);
+	hlist_bl_unlock(head);

 	return 0;
 }
 EXPORT_SYMBOL(mb_cache_entry_create);

The above movement of hlist_bl_unlock() is a problem for RT wrt both
taking and releasing of ->c_list_lock, it becoming an rtmutex in RT and
hlist_bl_unlock() taking a preemption blocking bit spinlock.

Is that scope increase necessary?  If so, looks like ->c_list_lock
could probably become a raw_spinlock_t without anyone noticing.

	-Mike