Messages in this thread | | | Date | Wed, 27 Oct 1999 05:31:34 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: lock/unlock_super and inode bitmaps. |
| |
On Wed, 27 Oct 1999, Tigran Aivazian wrote:
> On Wed, 27 Oct 1999, Tigran Aivazian wrote: > > 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?) > > Interestingly, ext2_new_inode() does have the explicit lock_super(sb). So, > could this be just a bug in minix_new_inode()?
It is a bug in minix_new_inode(). However, in case of minixfs lock_super() is not needed (it can't block, so locking buys nothing here - we hold the big kernel lock anyway). Looks like unlock_super() is a braino introduced when somebody did quota support for minixfs (in 2.3.13). It should be removed.
If your filesystem needs additionl exclusion here - use lock_super().
- 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/
| |