[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.108 / U:5.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site