linux-ext4 - Re: [URGENT PATCH] ext4: fix potential deadlock in ext4_evict

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Aug 2011 05:17:18 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Tao Ma <tm@....ma>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Chinner <david@...morbit.com>,
	Theodore Ts'o <tytso@....edu>,
	Jiaying Zhang <jiayingz@...gle.com>, linux-ext4@...r.kernel.org
Subject: Re: [URGENT PATCH] ext4: fix potential deadlock in ext4_evict_inode()

On Fri, Aug 26, 2011 at 05:10:35PM +0800, Tao Ma wrote:
> yeah, the DIO read on a buffer write file issue is also another side
> effect of it.[1]
> So could you please talk a little more about how xfs handle it now?

The thing I have queued up for 3.2 makes it very simple:  we do not
track I/O ends any more at all, outside of the workqueue.

For buffered I/O we only mark the page uptodate when all unwritten
extent conversion and size updates have finished.  All data integrity
callers and inode eviction wait for the pages to be update so we are
covered.

For direct I/O we only call inode_dio_done and aio_complete once all
unwritten extent size updates are done.  Inodes can't be evicted until
we drop a reference to the inode, which can't happen until the
sync or async dio is done and we drop the inode reference the VFS
holds for it.  Sync and fsync are only guaranteed to pick up I/O
that has returned to userspace, so we are covered for that as well.

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