Hi,
On Thu, Sep 07, 2000 at 11:44:23PM -0400, Alexander Viro wrote:
> Umm... OK, look at it that way: what are we protecting with ->s_lock?
> Aside of serializing ->read_super() and friends, that is. Three things:
> 1) cache of cylinder group descriptors
> 2) block bitmaps and counters
> 3) inode bitmaps and counters
> None of them actually needs a blocking lock at all.
Right, and I've already got patches which drop the superblock lock for
nearly all of balloc.c and ialloc.c. It's not hard in principle, and
I'll redo what I had for 2.4-current.
> For bitmaps we will
> need a spinlock per cg for search/modifications/counters updates. Add
> one more for descriptor cache and that's it. I'll try to dig out
> pre-patches along these lines - I should have them somewhere.
Right. My last stuff was, I think, before we dropped the BKL
throughout this code so I'll have to double-check whether any such
races remain.
> The worst problem is with the quota alocation/deallocation. Currently it
> blocks and it actually gives bad races (i_blocks getting out of sync with
> the quota and dquot_transfer() doing the wrong things).
What races? I don't think that quota updates will need to be atomic
as long as they eventuall complete. dquot_transfer() is indeed a
potential problem, but we don't need to serialise normal quota ops to
fix that --- we just need to make dquot_transfer lock out other
operations while it plays its games.
> issues (exploitable quota leaks are _not_ fun). Modulo that problem we can
> actually get rid of ->s_lock inside the fs/ext2/* completely...
Agreed, but it's probably even easier to get rid of it _mostly_ than
to totally remove it. In particular, the s_lock protects the bitmap
cache, and that is easy to replace with a cache function which simply
bumps the refcount on the buffer_head --- there's no need to lock it
there. Bitmap updates _can_ be done with atomic bitops, but we
probably don't want to --- if we have two processes allocating from
the same block group, we'll get better disk layout if they get
serialised at least during the bitmap update. The subsequent quota
update doesn't need serialising, and neither does the group status
information if we use atomic types there.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
