Messages in this thread | | | Date | Wed, 27 Oct 1999 16:29:02 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: lock/unlock_super and inode bitmaps. |
| |
Hello Stephen,
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/
| |