On Wed, 27 Oct 1999, Stephen C. Tweedie wrote:
> > 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.
Yes, but I try not to make use of the big kernel lock assumption as I
would *not* like to hinder the process of getting rid of big kernel lock
and ensuring "fine-grained SMP locking".
Another case, where I really don't like the way Linux relies on big kernel
lock is registering/unregistering filesystems. Currently it is only done
either in initialization context or from module_init/cleanup which means
we either don't need a lock or have a big kernel lock respectively. I
would have preferred to see file_systems protected by a read-write lock
whereby register/unregister take a write and all others take a read. When
I wanted to do it I hit the obstacle - the way mount_root() walks through
it sleeping on the way (in read_super())...
> > 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.
At the end it turns out that in my specific case (BFS) there is no need
for it as there is only one directory in BFS and therefore lock_parent()
is sufficient. As you say, there is also no need for it because of the big
kernel lock but I don't want to make use of this fact.
Thank you,
Tigran.
-
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/