aboutsummaryrefslogtreecommitdiffstats
path: root/fs/ext3/inode.c
diff options
context:
space:
mode:
authorGlauber de Oliveira Costa <glommer@br.ibm.com>2005-10-30 18:02:48 -0500
committerLinus Torvalds <torvalds@g5.osdl.org>2005-10-30 20:37:23 -0500
commit5b11687924e40790deb0d5f959247ade82196665 (patch)
tree29aa104cc40bd2c85e7bba0f4b404b04cd6f207a /fs/ext3/inode.c
parent2384f55f8aa520172c995965bd2f8a9740d53095 (diff)
[PATCH] Locking problems while EXT3FS_DEBUG on
I noticed some problems while running ext3 with the debug flag set on. More precisely, I was unable to umount the filesystem. Some investigation took me to the patch that follows. At a first glance , the lock/unlock I've taken out seems really not necessary, as the main code (outside debug) does not lock the super. The only additional danger operations that debug code introduces seems to be related to bitmap, but bitmap operations tends to be all atomic anyway. I also took the opportunity to fix 2 spelling errors. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/ext3/inode.c')
-rw-r--r--fs/ext3/inode.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c
index 8b38f2232796..b5da5244e144 100644
--- a/fs/ext3/inode.c
+++ b/fs/ext3/inode.c
@@ -491,7 +491,7 @@ static unsigned long ext3_find_goal(struct inode *inode, long block,
491 * the same format as ext3_get_branch() would do. We are calling it after 491 * the same format as ext3_get_branch() would do. We are calling it after
492 * we had read the existing part of chain and partial points to the last 492 * we had read the existing part of chain and partial points to the last
493 * triple of that (one with zero ->key). Upon the exit we have the same 493 * triple of that (one with zero ->key). Upon the exit we have the same
494 * picture as after the successful ext3_get_block(), excpet that in one 494 * picture as after the successful ext3_get_block(), except that in one
495 * place chain is disconnected - *branch->p is still zero (we did not 495 * place chain is disconnected - *branch->p is still zero (we did not
496 * set the last link), but branch->key contains the number that should 496 * set the last link), but branch->key contains the number that should
497 * be placed into *branch->p to fill that gap. 497 * be placed into *branch->p to fill that gap.