From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AC54A7F54 for ; Fri, 22 Mar 2013 18:18:57 -0500 (CDT) Date: Fri, 22 Mar 2013 18:18:57 -0500 From: Ben Myers Subject: Re: [PATCH] xfs: Fix WARN_ON(delalloc) in xfs_vm_releasepage() Message-ID: <20130322231857.GR22182@sgi.com> References: <1363267854-25602-1-git-send-email-jack@suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1363267854-25602-1-git-send-email-jack@suse.cz> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Jan Kara Cc: xfs@oss.sgi.com 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. > > Signed-off-by: Jan Kara Applied. Regards, Ben _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs