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
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...