lkml.org 
[lkml]   [1999]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.067 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site