Race with inodes in I_FREEING state

[Livio Baldini Soares <livio@ime.usp.br>]

  Hello! 

  I'm developing a file system for Linux (I'm currently only using the
2.4 tree), and  have seem to have  hit a small race with  the VFS code
starting to iget()  an inode while it's being  freed, which is causing
my code to panic.

  The race occurs in the following scenario:

1) prune_icache() is called, and inode $x$ (ino = $z$) is removed from
   the inode hash.

2) dispose_list() is called, but is preempted/scheduled.

3) Another task  calls iget() for inode $y$ (ino  also = $z$), doesn't
   find it in the hash, and reads the inode (read_inode()). 

4) dispose_list() wakes up, and finally calls FS-specific clear_inode()
   operation on inode $x$.

  It _is_ true that $x$ on steps 1 and 4 is a different inode than $y$
in step 3. However, my FS  has some hashed/shared data, kept in 'union
u', which is  deleted when clear_inode() is called. So,  in the end of
step 4, inode $y$ has a broken 'u' field, pointing to deleted memory.

  After looking around in the  archive, I believe this race is similar
to the one described here, by Niel Brown:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105235852013658&w=2

  Does this not also happen in  version 2.4.20? Can anybody tell me if
my logic is  wrong, or if I'm just plain doing  something stupid in my
FS?

  Hope I have not troubled anyone, best regards,

--  
  Livio B. Soares