Re: iput() in reclaim context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hugh.

On Wed, May 21, 2008 at 06:52:27PM +0100, Hugh Dickins (hugh@xxxxxxxxxxx) wrote:
> I happened to notice your remark in the buffer heads defrag thread.
> Do you remember what that limitation was about?
> 
> Because just a few months ago I discovered a shmem race which I fixed
> by doing igrab+iput in shmem_writepage, in the reclaim context.  Feeling
> guilty now: I'd better investigate, but would welcome a starting pointer.
> 
> (If I'm lucky, it'll be that the generic code in vmscan.c cannot
> use iput, but particular filesystems might themselves be safe to.)

If we are talking about the same things, its waiting for pages to be
synced (wither written back or truncated) when inode is about to be
destroyed. Thus reclaim can sleep wating for pages to be synced, which
it is about to move somewhere itself. Deadlock. The same for writepage -
if we drop inode there it can wait for pages to be synced, which inturn
requires writeback, where we are sleeping already...

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux