[PATCH xfs: tone down writepage/releasepage WARN_ONs

[PATCH xfs: tone down writepage/releasepage WARN_ONs

[Christoph Hellwig]

I recently ran into the issue fixed by

  "xfs: kill buffers over failed write ranges properly"

which spams the log with lots of backtraces.  Make debugging any issues
like that easier by using WARN_ON_ONCE in the writeback code.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_aops.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index d1b99b6..e32640e 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -975,7 +975,7 @@ xfs_vm_writepage(
 	 * Given that we do not allow direct reclaim to call us, we should
 	 * never be called while in a filesystem transaction.
 	 */
-	if (WARN_ON(current->flags & PF_FSTRANS))
+	if (WARN_ON_ONCE(current->flags & PF_FSTRANS))
 		goto redirty;
 
 	/* Is this page beyond the end of the file? */
@@ -1225,9 +1225,9 @@ xfs_vm_releasepage(
 
 	xfs_count_page_state(page, &delalloc, &unwritten);
 
-	if (WARN_ON(delalloc))
+	if (WARN_ON_ONCE(delalloc))
 		return 0;
-	if (WARN_ON(unwritten))
+	if (WARN_ON_ONCE(unwritten))
 		return 0;
 
 	return try_to_free_buffers(page);
-- 
1.7.10.4

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

Re: [PATCH xfs: tone down writepage/releasepage WARN_ONs

[Brian Foster]

On Tue, May 27, 2014 at 03:31:19AM -0700, Christoph Hellwig wrote:
> I recently ran into the issue fixed by
> 
>   "xfs: kill buffers over failed write ranges properly"
> 
> which spams the log with lots of backtraces.  Make debugging any issues
> like that easier by using WARN_ON_ONCE in the writeback code.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---

The change generally seems fine to me. IIRC, we had a point in time
where these issues were prevalent and noisy. We also had a few lingering
ones that were hard to reproduce. I do wonder whether this would make
that situation difficult to reproduce. For example, running through an
xfstests run where one test might reproduce randomly and suppress output
from a subsequent, perhaps more frequent reproducer. Am I correct to
assume that once fired, the warning wouldn't fire again before a reboot
or module reload?

Hmm, did we have asserts that covered these scenarios as well?

Brian

>  fs/xfs/xfs_aops.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index d1b99b6..e32640e 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -975,7 +975,7 @@ xfs_vm_writepage(
>  	 * Given that we do not allow direct reclaim to call us, we should
>  	 * never be called while in a filesystem transaction.
>  	 */
> -	if (WARN_ON(current->flags & PF_FSTRANS))
> +	if (WARN_ON_ONCE(current->flags & PF_FSTRANS))
>  		goto redirty;
>  
>  	/* Is this page beyond the end of the file? */
> @@ -1225,9 +1225,9 @@ xfs_vm_releasepage(
>  
>  	xfs_count_page_state(page, &delalloc, &unwritten);
>  
> -	if (WARN_ON(delalloc))
> +	if (WARN_ON_ONCE(delalloc))
>  		return 0;
> -	if (WARN_ON(unwritten))
> +	if (WARN_ON_ONCE(unwritten))
>  		return 0;
>  
>  	return try_to_free_buffers(page);
> -- 
> 1.7.10.4
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

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