[lkml]   [1999]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: lock/unlock_super and inode bitmaps.

    On Wed, 27 Oct 1999 08:03:52 +0100 (BST), Tigran Aivazian
    <tigran@sco.COM> said:

    > 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.

    > 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).

    In ext2, we do take the superblock lock during allocations, but that
    is only to protect the "bitmap caches", and we have already tested
    patches to avoid the superblock lock in such cases.

    > 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.020 / U:0.936 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site