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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/