Race in iput()?

Race in iput()?

[Paul Menage]

Hi,

Is the following sequence of events possible? If so, that would seem
to be a bug.

- inode on non-MS_ACTIVE superblock is on unused list (fs being unmounted?)
- prune_icache() starts processing inode, so sets I_LOCK
- in another thread, someone calls iget() then iput() on inode 
- inode is dirty, so iput() calls write_inode_now() 
- write_inode_now() calls sync_one()
- sync_one() calls __iget() and bumps inode ref count back up to 1
- sync_one() calls __wait_on_inode() and sleeps
- in original thread, prune_icache() finishes with inode and clears I_LOCK
- sync_one() wakes up and calls iput()
- iput() decrements ref count to 0 again and frees inode (no wait this time)
- sync_one() and callers now hold a pointer to a freed inode

Alternatively, try_to_sync_unused_inodes() could be racing rather than
prune_icache().

We've seen a crash that could be explained by this race being hit, if
it is possible.

Paul

Re: Race in iput()?

[viro]

On Mon, Jun 28, 2004 at 09:40:10PM -0700, Paul Menage wrote:
> Hi,
> 
> Is the following sequence of events possible? If so, that would seem
> to be a bug.
> 
> - inode on non-MS_ACTIVE superblock is on unused list (fs being unmounted?)
> - prune_icache() starts processing inode, so sets I_LOCK
> - in another thread, someone calls iget() then iput() on inode 

Umm...  What would that other thread be?  MS_ACTIVE is removed upon the final
umount, all right, but that's done only when nobody except the filesystem
itself should be able to even see it...