lkml.org 
[lkml]   [1999]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectlock/unlock_super and inode bitmaps.
Hi,

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.

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

The only lock taken at the VFS level is lock_parent() so two things with
different parents can still corrupt super_block info.

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

Thank you,
------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran


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