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.019 / U:33.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site