From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH xfs: tone down writepage/releasepage WARN_ONs
Date: Wed, 28 May 2014 11:49:27 -0400 [thread overview]
Message-ID: <20140528154927.GD5567@bfoster.bfoster> (raw)
In-Reply-To: <20140527103119.GA26420@infradead.org>
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
prev parent reply other threads:[~2014-05-28 15:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 10:31 [PATCH xfs: tone down writepage/releasepage WARN_ONs Christoph Hellwig
2014-05-28 15:49 ` Brian Foster [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140528154927.GD5567@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.