linux-kernel - Re: lockdep "splat" on v2.6.33.5-rt23

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] [day] [month] [year] [list]

Date:	Thu, 24 Jun 2010 10:03:41 -0700
From:	john stultz <johnstul@...ibm.com>
To:	John Kacur <jkacur@...hat.com>
Cc:	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: lockdep "splat" on v2.6.33.5-rt23

On Thu, 2010-06-24 at 17:40 +0200, John Kacur wrote:
> I believe this is related to the dcache scale discussion thread. I've 
> shown this to Peter privately, but thought it would be useful to share it 
> with everyone so we all have the same info.
> The kernel is from tip/rt/2.6.33 up to commit 
> faf35813f204901f85dd0c6b3c5092e0064c6c2f
> It has a lot of debug options enabled, but is not modified.
> The "splat" is very easy to reproduce, it simply occurs when I 
> boot the kernel on my T500.
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.33.5-rt23-tip-debug #3
> ---------------------------------------------
> init/1 is trying to acquire lock:
>  (&dentry->d_lock/1){+.+...}, at: [<ffffffff811981be>] 
> shrink_dcache_parent+0x10f/0x2eb
> 
> but task is already holding lock:
>  (&dentry->d_lock/1){+.+...}, at: [<ffffffff811981be>] 
> shrink_dcache_parent+0x10f/0x2eb

This looks like the issue Peter brought up earlier this week. I think
you were cc'ed (although it may have been your gmail account).

It seems my fix for the earlier dput/select_parent race is causing this.
Lockdep doesn't allow us to lock sub-chains, so any time select_parent
descends two directories down, this will trigger.

Right off I'm not sure what to do about it. We can't just revert, since
that will open the race up, and trying to serialize dput/select parent
using something other then the parent/child dentry->d_locks will
probably be akin to the dcache_lock, and will hurt scalability.

I need to read through Nick's new patchset and see how its changed and
try to adapt any fixes to the -rt tree, but that's competing with some
other critical issues I'm working at the moment.

thanks
-john

--
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/