On Wed, 27 Oct 1999 08:03:52 +0100 (BST), Tigran Aivazian
<tigran@sco.COM> said:
> I keep the number of free inodes and a pointer to inode bitmap in
> the private (fs-specific) superblock info inside super_block. Now,
> if one engine creates a new inode and another frees some other inode
> then we have a race.
Where? Most of that code runs with the big kernel lock currently, and
in many cases that is good enough.
> Do I therefore need to lock/unlock_super(sb) manually in those
> methods? I see unlock_super(sb) at the end of minix_new_inode() but
> I don't find the corresponding lock_super(sb).
In ext2, we do take the superblock lock during allocations, but that
is only to protect the "bitmap caches", and we have already tested
patches to avoid the superblock lock in such cases.
> So, the question is - is it right to lock/unlock_super(sb) in
> XXX_new_inode()/XXX_free_inode() or do I need to invent my own lock for
> this purpose (or do I need no locks at all for some magical reason that
> currently escapes me)? (and where is lock_super for the unlock_super in
> minix_new_inode?)
The superblock lock is there for you to take if you want it --- you
don't have to use it, but it's as good a lock as any if you want a
blocking operation to be atomic.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/