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 <[EMAIL PROTECTED]>
>
> 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 [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
