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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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