Messages in this thread | | | Date | Wed, 27 Oct 1999 08:03:52 +0100 (BST) | From | Tigran Aivazian <> | Subject | lock/unlock_super and inode bitmaps. |
| |
Hi,
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.
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).
The only lock taken at the VFS level is lock_parent() so two things with different parents can still corrupt super_block info.
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?)
Thank you, ------ Tigran A. Aivazian | http://www.sco.com Escalations Research Group | tel: +44-(0)1923-813796 Santa Cruz Operation Ltd | http://www.ocston.org/~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/
| |