Re: [PATCH] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage()

[Dave Chinner <david@fromorbit.com>]

On Mon, Mar 18, 2013 at 05:05:52PM +0100, Jan Kara wrote:
> On Fri 15-03-13 15:52:14, Ben Myers wrote:
> > Hi Jan,
> > 
> > On Thu, Mar 14, 2013 at 02:30:54PM +0100, Jan Kara wrote:
> > > When a dirty page is truncated from a file but reclaim gets to it before
> > > truncate_inode_pages(), we hit WARN_ON(delalloc) in
> > > xfs_vm_releasepage(). This is because reclaim tries to write the page,
> > > xfs_vm_writepage() just bails out (leaving page clean) and thus reclaim
> > > thinks it can continue and calls xfs_vm_releasepage() on page with dirty
> > > buffers.
> > > 
> > > Fix the issue by redirtying the page in xfs_vm_writepage(). This makes
> > > reclaim stop reclaiming the page and also logically it keeps page in a
> > > more consistent state where page with dirty buffers has PageDirty set.
> > 
> > Was there an easy way to reproduce this?  I'm testing and reviewing this now
> > and it might help.
>   I used scripts/run-bash-shared-mapping.sh from the attached tarball - it
> fires up several processes beating a file with mmap accesses while
> truncating the file and memory stressing the machine. I presume fsx with
> some memhog could trigger the issue as well.

I have seen fsx trip this occasionally. The problem is that it was
never reliable because of the fact that other memory pressure had to
be generated at the same time....

Is the above script something you could turn into an xfstest (I
haven't looked at the script yet)?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs