| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 21 May 2008 21:58:58 +0400 From: Evgeniy Polyakov <johnpol@....mipt.ru> To: Hugh Dickins <hugh@...itas.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: iput() in reclaim context Hi Hugh. On Wed, May 21, 2008 at 06:52:27PM +0100, Hugh Dickins (hugh@...itas.com) 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists