Messages in this thread | | | Date | Fri, 11 Jul 1997 13:15:55 -0400 | From | Bill Hawes <> | Subject | Ext2 Questions/Problems |
| |
While checking out some issues with the new inode code I've run across some problems in Ext2. I was hoping one of our resident Ext2 experts (Ted? Stephen?) could shed some light on the matter ...
The first question concerns the call to get_empty_inode() in ext2_new_inode. It's a potential problem with the new code, as inodes obtained from this call are not hashed (at least not immediately). In addition, this seems to introduce a race condition (under all kernel versions, not just 2.1.45). Since get_empty_inode will often block, two callers could end up getting inodes for the same object, which can't be a good thing. Shouldn't this call go through iget() to guarantee a unique inode?
Next problem is that there unprotected race conditions in the ext2_put_inode and its continuation ext2_free_inode. ext2_put_inode is called via the s_op interface from iput() when the inode count is at 1 and about to go to 0. There are many potential blocking calls between the entry of ext2_put_inode and the eventual call to clear_inode, so it's possible for another process to put the inode back in use as it's being taken out of use. This could lead to many problems ...
In addition, at several points the inode is marked dirty, even though all execution paths lead to clear_inode(). Since clear_inode() takes no action for dirty inodes, I don't understand the semantics of marking an inode dirty just before it's cleared.
I have some ideas on how the race conditions can be fixed, but would like to get some other opinions first.
Regards, Bill
| |