[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: read_super()
From:       Andrew Morton <andrewm () uow ! edu ! au>
Date:       2001-05-11 17:49:18
[Download RAW message or body]

Bryan Henderson wrote:
> 
> >all ->read_super() should do is read the superblock!
> 
> You're taking it kind of literally, aren't you?  These days, superblock is
> a metaphor.  Lots of filesystems don't have real superblocks.  I think if
> we were naming ->read_super() today, we'd name it ->mount().

Well, today I'd call it lock_up_machine(), but that's another story :)

> ...
> 
> >This deadlocks ext3, which wants to call ext3_truncate()
> >inside ext3_read_super().
> 
> This is the part I don't get.  Does ext3_truncate() acquire the superblock
> lock?  If so, that would seem to be the problem -- it's a layering
> violation.

Yes.  ext2 (and hence ext3) use lock_super() to provide locking
around their manipulation of the fs-private allocation bitmaps.
As far as I can tell there's no need to do this and an fs-private
semaphore would do the job just as well, and would avoid these
deadlocks.

Andreas? Al? Stephen? Can anyone see a reason for overloading
lock_super() in this manner?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

[prev in list] [next in list] [prev in thread] [next in thread]