linux-kernel - Re: [PATCH] Increase lockdep MAX_LOCK

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: <1188542389.6112.44.camel@twins>
Date:	Fri, 31 Aug 2007 08:39:49 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Eric Sandeen <sandeen@...deen.net>
Cc:	linux-kernel Mailing List <linux-kernel@...r.kernel.org>,
	xfs-oss <xfs@....sgi.com>, Dave Chinner <dgc@....com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] Increase lockdep MAX_LOCK_DEPTH

On Thu, 2007-08-30 at 23:43 -0500, Eric Sandeen wrote:
> The xfs filesystem can exceed the current lockdep 
> MAX_LOCK_DEPTH, because when deleting an entire cluster of inodes,
> they all get locked in xfs_ifree_cluster().  The normal cluster
> size is 8192 bytes, and with the default (and minimum) inode size 
> of 256 bytes, that's up to 32 inodes that get locked.  Throw in a 
> few other locks along the way, and 40 seems enough to get me through
> all the tests in the xfsqa suite on 4k blocks.  (block sizes
> above 8K will still exceed this though, I think)

As 40 will still not be enough for people with larger block sizes, this
does not seems like a solid solution. Could XFS possibly batch in
smaller (fixed sized) chunks, or does that have significant down sides?

> Signed-off-by: Eric Sandeen <sandeen@...deen.net>
> 
> Index: linux-2.6.23-rc3/include/linux/sched.h
> ===================================================================
> --- linux-2.6.23-rc3.orig/include/linux/sched.h
> +++ linux-2.6.23-rc3/include/linux/sched.h
> @@ -1125,7 +1125,7 @@ struct task_struct {
>  	int softirq_context;
>  #endif
>  #ifdef CONFIG_LOCKDEP
> -# define MAX_LOCK_DEPTH 30UL
> +# define MAX_LOCK_DEPTH 40UL
>  	u64 curr_chain_key;
>  	int lockdep_depth;
>  	struct held_lock held_locks[MAX_LOCK_DEPTH];
> 
> -
> 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/

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