Re: XFS hang during xfs_fsr run

[Christoph Hellwig <hch@xxxxxxxxxxxxx>]

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.