Re: [patch] vmfixes-2.4.0-test9-B2

Alexander Viro
2000-09-25T00:49:12Z

On Sun, 24 Sep 2000, Linus Torvalds wrote:

> > ext2_new_block (or whatever that runs getblk with the superlock lock
> > acquired)->getblk->GFP->shrink_dcache_memory->prune_dcache->
> > prune_one_dentry->dput->dentry_iput->iput->inode->i_sb->s_op->
> > put_inode->ext2_discard_prealloc->ext2_free_blocks->lock_super->D
>
> Whee..
[snip]

> On the whole, fixing the cases would probably imply dropping the lock,
> doing the read, re-aquireing the lock, and then going back and seeing if
> maybe somebody else already filled in the bitmap cache or whatever. So not
> one-liners by any means, but we'll probably want to do it at some point
> (the superblock lock is quite contended right now, and the reason for that
> may well be that it's just so badly done for historical reasons).

Nope. Solution is to kill the silly "hold super_block lock during the
allocation" completely. Right now the main problem making us use it at all
is the following: dquot_alloc_block() is a blocking operation. If that
gets fixed - that's it. We simply don't need anything more fancy than
rwlock on access to bitmap + rwlock or plain spinlock on access to group
descriptors cache. End of problem.

Remember that off-list thread in July when you asked what could be done
with lock_super()? I did the analysis, all right - list of ext2 races was
a side effect of that. Now we have that crap fixed, so getting rid of
lock_super() in ext2 (in clear way) is possible. So if you still want it -
tell. ext2 part is very easy, it's quota part that needs serious work.