XFS hang during xfs_fsr run
Christoph Hellwig
hch at infradead.org
Fri Mar 12 08:27:37 CST 2010
On Fri, Mar 12, 2010 at 10:56:45PM +1100, Dave Chinner wrote:
> ->page_mkwrite executes without the inode iolock held, so we can't
> lock it out from creating new delalloc pages by holding the iolock
> like the bmap code does.
>
> I don't think we're allowed to take the iolock in ->page_mkwrite, so
> effectively that leaves us with the situation where we can't do an
> atomic flush and map in the bmap code.
>
> Christoph, I guess that means we need to make the bmap code
> handle/ignore delalloc extents rather than assume they never occur
> after the flush. What do you think?
The current swapext code is supposed to skip any file that is mapped
into userspace via mmap. So if you get a file that is actually mmaped
something is wrong with that check. From a quick look the only problem
I see is that we don't take the iolock in ->mmap so we could add a new
mapping after the check, but I'd be surprise if that is what Michael
is seeing.
More information about the xfs
mailing list