linux-kernel - Re: [PATCH 0/3] dma-debug: add additional checks

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]

Message-Id: <1237379290.5069.341.camel@laptop>
Date:	Wed, 18 Mar 2009 13:28:10 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Joerg Roedel <joerg.roedel@....com>
Cc:	Ingo Molnar <mingo@...e.hu>, iommu@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] dma-debug: add additional checks

On Wed, 2009-03-18 at 13:19 +0100, Joerg Roedel wrote:
> On Wed, Mar 18, 2009 at 12:38:47PM +0100, Peter Zijlstra wrote:
> > On Wed, 2009-03-18 at 12:23 +0100, Ingo Molnar wrote:
> > > another -tip testbox started triggering:
> > > 
> > >   BUG: MAX_LOCKDEP_ENTRIES too low!
> > > 
> > > it triggers due to CONFIG_DMA_API_DEBUG=y. Config attached.
> > 
> > 
> > I still have this laying about.. could be we're just at the limit due to
> > lock bloat in the kernel, could be dma_api_debug is doing something
> > all-together iffy
> 
> I had a look and the maximum locking depth in dma-debug code was two.
> Attached patch reduces this to one.
> 
> From d28fc4a308bf66ed98c68e1db18e4e1434206541 Mon Sep 17 00:00:00 2001
> From: Joerg Roedel <joerg.roedel@....com>
> Date: Wed, 18 Mar 2009 13:15:20 +0100
> Subject: [PATCH] dma-debug: serialize locking in unmap path
> 
> Impact: reduce maximum lockdepth to one
> 
> This patch reduces the maximum spin lock depth from two to one in the
> dma-debug code.

While appreciated, this failure is not about lock depth, but about lock
entries, that is items in the dependency chains.

Of course, these two are not unrelated, deeper lock hierarchies lead to
longer chains -> more entries.

Assuming dma api debug doesn't do anything spectaculary odd, I'd say
we've just lock bloated the kernel and might need to increase this
static array a bit.

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