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: Fri, 28 Jun 2013 13:54:37 +1000 From: Dave Chinner <david@...morbit.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Dave Jones <davej@...hat.com>, Oleg Nesterov <oleg@...hat.com>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Linux Kernel <linux-kernel@...r.kernel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Andrey Vagin <avagin@...nvz.org>, Steven Rostedt <rostedt@...dmis.org> Subject: Re: frequent softlockups with 3.10rc6. On Thu, Jun 27, 2013 at 04:54:53PM -1000, Linus Torvalds wrote: > On Thu, Jun 27, 2013 at 3:18 PM, Dave Chinner <david@...morbit.com> wrote: > > > > Right, that will be what is happening - the entire system will go > > unresponsive when a sync call happens, so it's entirely possible > > to see the soft lockups on inode_sb_list_add()/inode_sb_list_del() > > trying to get the lock because of the way ticket spinlocks work... > > So what made it all start happening now? I don't recall us having had > these kinds of issues before.. Not sure - it's a sudden surprise for me, too. Then again, I haven't been looking at sync from a performance or lock contention point of view any time recently. The algorithm that wait_sb_inodes() is effectively unchanged since at least 2009, so it's probably a case of it having been protected from contention by some external factor we've fixed/removed recently. Perhaps the bdi-flusher thread replacement in -rc1 has changed the timing sufficiently that it no longer serialises concurrent sync calls as much.... However, the inode_sb_list_lock is known to be a badly contended lock from a create/unlink fastpath for XFS, so it's not like this sort of thing is completely unexpected. It sits behind only the dentry cache LRU lock on my most contended VFS lock list, so it's been on my radar for a while. With the work to remove the global dentry LRU lock currently in -mm, this was always going to be the next lock I looked at.... Cheers, Dave. -- Dave Chinner david@...morbit.com -- 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