[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190730112452.871257694@linutronix.de>
Date: Tue, 30 Jul 2019 13:24:52 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Sebastian Siewior <bigeasy@...utronix.de>,
Anna-Maria Gleixner <anna-maria@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Julia Cartwright <julia@...com>,
"Theodore Tso" <tytso@....edu>,
Matthew Wilcox <willy@...radead.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
Jan Kara <jack@...e.com>
Subject: [patch 0/4] fs: Substitute bit-spinlocks for PREEMPT_RT and debugging
Bit spinlocks are problematic if PREEMPT_RT is enabled. They disable
preemption, which is undesired for latency reasons and breaks when regular
spinlocks are taken within the bit_spinlock locked region because regular
spinlocks are converted to 'sleeping spinlocks' on RT.
Bit spinlocks are also not covered by lock debugging, e.g. lockdep. With
the spinlock substitution in place, they can be exposed via a new config
switch: CONFIG_DEBUG_BIT_SPINLOCKS.
This series handles only buffer head and jbd2, but does not touch the
hlist_bl bit-spinlock usage.
For most usage sites of hlist_bl the protected sections are either really
small and do not contain any RT incompatible code or can be trivially fixed
up. In those cases converting the list_bl locking to spinlocks looks like
overkill, but it still might make sense to provide it for debugging.
The only exception for this is the code in drivers/md/dm-snap.c which has
interesting nested locking in place (via kmemcache, cgroups, block ...)
which completely escapes lockdep.
I pondered making the hlist_bl locking conditional on a per source
file define, but that does not work due to include hell.
Thoughts?
Thanks,
tglx
Powered by blists - more mailing lists