Message-ID: <6599ad830406282140a6310fe@mail.google.com>
Date: Mon, 28 Jun 2004 21:40:10 -0700
From: Paul Menage <menage@google.com>
To: viro@parcelfarce.linux.theplanet.co.uk
Subject: Race in iput()?
Cc: linux-kernel@vger.kernel.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1167
Lines: 29

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/