summaryrefslogtreecommitdiff
path: root/fs/qnx4/truncate.c
diff options
context:
space:
mode:
authorArjan van de Ven <arjan@linux.intel.com>2006-07-03 07:25:20 (GMT)
committerLinus Torvalds <torvalds@g5.osdl.org>2006-07-03 22:27:08 (GMT)
commit5c81a4197de38411fe3e27f8593fff73a5d6b868 (patch)
tree0a7867025e08353bf9946759864beeaf0ff01ad2 /fs/qnx4/truncate.c
parent59345374742ee6673c2d04b0fa8c888e881b7209 (diff)
downloadlinux-5c81a4197de38411fe3e27f8593fff73a5d6b868.tar.xz
[PATCH] lockdep: annotate the quota code
The quota code plays interesting games with the lock ordering; to quote Jan: | i_mutex of inode containing quota file is acquired after all other | quota locks. i_mutex of all other inodes is acquired before quota | locks. Quota code makes sure (by resetting inode operations and | setting special flag on inode) that noone tries to enter quota code | while holding i_mutex on a quota file... The good news is that all of this special case i_mutex grabbing happens in the (per filesystem) low level quota write function. For this special case we need a new I_MUTEX_* nesting level, since this just entirely outside any of the regular VFS locking rules for i_mutex. I trust Jan on his blue eyes that this is not ever going to deadlock; and based on that the patch below is what it takes to inform lockdep of these very interesting new locking rules. The new locking rule for the I_MUTEX_QUOTA nesting level is that this is the deepest possible level of nesting for i_mutex, and that this only should be used in quota write (and possibly read) function of filesystems. This makes the lock ordering of the I_MUTEX_* levels: I_MUTEX_PARENT -> I_MUTEX_CHILD -> I_MUTEX_NORMAL -> I_MUTEX_QUOTA Has no effect on non-lockdep kernels. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Jan Kara <jack@ucw.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/qnx4/truncate.c')
0 files changed, 0 insertions, 0 deletions