Re: Race with inodes in I_FREEING state

On Jun 13, 2003  15:02 +1000, Neil Brown wrote:
> >   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