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