Messages in this thread |  | | Date | Sun, 24 Sep 2000 20:49:12 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [patch] vmfixes-2.4.0-test9-B2 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |