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
| ||
|
Date: Sun, 02 Nov 2014 08:31:18 +0100 From: Mike Galbraith <umgwanakikbuti@...il.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: LKML <linux-kernel@...r.kernel.org>, linux-rt-users <linux-rt-users@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, Carsten Emde <C.Emde@...dl.org>, John Kacur <jkacur@...hat.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Clark Williams <williams@...hat.com> Subject: 3.14.23-rt20 - fs,btrfs: fix rt deadlock on extent_buffer->lock Subject: fs,btrfs: fix rt deadlock on extent_buffer->lock From: Mike Galbraith <mgalbraith@...e.de> Sat Jul 14 12:30:41 CEST 2012 Trivially repeatable deadlock is cured by enabling lockdep code in btrfs_clear_path_blocking() as suggested by Chris Mason. He also suggested restricting blocking reader count to one, and not allowing a spinning reader while blocking reader exists. This has proven to be unnecessary, the strict lock order enforcement is enough.. or rather that's my box's opinion after long hours of hard pounding. Note: extent-tree.c bit is additional recommendation from Chris Mason, split into a separate patch after discussion. Signed-off-by: Mike Galbraith <efault@....de> Cc: Chris Mason <chris.mason@...ionio.com> --- fs/btrfs/ctree.c | 4 ++-- fs/btrfs/extent-tree.c | 8 -------- 2 files changed, 2 insertions(+), 10 deletions(-) --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -80,7 +80,7 @@ noinline void btrfs_clear_path_blocking( { int i; -#ifdef CONFIG_DEBUG_LOCK_ALLOC +#if (defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_PREEMPT_RT_BASE)) /* lockdep really cares that we take all of these spinlocks * in the right order. If any of the locks in the path are not * currently blocking, it is going to complain. So, make really @@ -107,7 +107,7 @@ noinline void btrfs_clear_path_blocking( } } -#ifdef CONFIG_DEBUG_LOCK_ALLOC +#if (defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_PREEMPT_RT_BASE)) if (held) btrfs_clear_lock_blocking_rw(held, held_rw); #endif --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -6938,14 +6938,6 @@ use_block_rsv(struct btrfs_trans_handle goto again; } - if (btrfs_test_opt(root, ENOSPC_DEBUG)) { - static DEFINE_RATELIMIT_STATE(_rs, - DEFAULT_RATELIMIT_INTERVAL * 10, - /*DEFAULT_RATELIMIT_BURST*/ 1); - if (__ratelimit(&_rs)) - WARN(1, KERN_DEBUG - "BTRFS: block rsv returned %d\n", ret); - } try_reserve: ret = reserve_metadata_bytes(root, block_rsv, blocksize, BTRFS_RESERVE_NO_FLUSH); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists