public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/247: filter out expected XFS warnings for mixed mmap/direct I/O
Date: Thu, 29 Jun 2017 14:19:09 +0800	[thread overview]
Message-ID: <20170629061909.GL23360@eguan.usersys.redhat.com> (raw)
In-Reply-To: <20170628141442.10950-1-bfoster@redhat.com>

On Wed, Jun 28, 2017 at 10:14:42AM -0400, Brian Foster wrote:
> generic/247 reproduces some of the same, expected warnings from XFS
> as generic/095. These warnings occur due to mixed buffered/mapped
> I/O racing with direct I/O to the same file.
> 
> generic/095 contains a custom dmesg filter to prevent test failure
> in the event of such warnings. Lift the helper from generic/095 to
> common/xfs and reuse it in generic/247 to implement the same
> behavior.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>

Thanks a lot for doing this! It was in my todo list but I never got to
it..

Some minor issues below, that I can fix them all at commit time.

> ---
>  common/xfs        | 18 ++++++++++++++++++
>  tests/generic/095 | 20 +++-----------------
>  tests/generic/247 | 11 +++++++++--
>  3 files changed, 30 insertions(+), 19 deletions(-)
> 
> diff --git a/common/xfs b/common/xfs
> index 0f0825b..0266f50 100644
> --- a/common/xfs
> +++ b/common/xfs
> @@ -584,3 +584,21 @@ _require_xfs_mkfs_ciname()
>  	_scratch_mkfs_xfs_supported -n version=ci >/dev/null 2>&1 \
>  		|| _notrun "need case-insensitive naming support in mkfs.xfs"
>  }
> +
> +# xfs generates WARNINGs on purpose when applications mix buffered/mmap IO with
> +# direct IO on the same file. This is a helper for _check_dmesg() to filter out
> +# such warnings.
> +filter_xfs_dmesg()

I've renamed it, added a leading underscore _filter_xfs_dmesg, it's
common helper now.

> +{
> +	local warn1="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_dio_aio_write.*"
> +	local warn2="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_dio_aio_read.*"
> +	local warn3="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_read_iter.*"
> +	local warn4="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_aio_read.*"
> +	local warn5="WARNING:.*fs/iomap\.c:.*iomap_dio_rw.*"
> +	sed -e "s#$warn1#Intentional warnings in xfs_file_dio_aio_write#" \
> +	    -e "s#$warn2#Intentional warnings in xfs_file_dio_aio_read#" \
> +	    -e "s#$warn3#Intentional warnings in xfs_file_read_iter#" \
> +	    -e "s#$warn4#Intentional warnings in xfs_file_aio_read#" \
> +	    -e "s#$warn5#Intentional warnings in iomap_dio_rw#"
> +}
> +
> diff --git a/tests/generic/095 b/tests/generic/095
> index d837564..9580aaf 100755
> --- a/tests/generic/095
> +++ b/tests/generic/095
> @@ -117,28 +117,14 @@ _scratch_mount
>  echo "Silence is golden"
>  $FIO_PROG $fio_config >>$seqres.full 2>&1
>  
> +# umount before checking dmesg in case umount triggers any WARNING or Oops
> +_scratch_unmount
> +
>  # xfs generates WARNINGs on purpose when applications mix buffered/mmap IO with
>  # direct IO on the same file. On the other hand, this fio job has been proven
>  # to be potent, we don't want to simply _disable_dmesg_check which could miss
>  # other potential bugs. So filter out the intentional WARNINGs, make sure test
>  # doesn't fail because of this warning and fails on other WARNINGs.
> -filter_xfs_dmesg()
> -{
> -	local warn1="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_dio_aio_write.*"
> -	local warn2="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_dio_aio_read.*"
> -	local warn3="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_read_iter.*"
> -	local warn4="WARNING:.*fs/xfs/xfs_file\.c:.*xfs_file_aio_read.*"
> -	local warn5="WARNING:.*fs/iomap\.c:.*iomap_dio_rw.*"
> -	sed -e "s#$warn1#Intentional warnings in xfs_file_dio_aio_write#" \
> -	    -e "s#$warn2#Intentional warnings in xfs_file_dio_aio_read#" \
> -	    -e "s#$warn3#Intentional warnings in xfs_file_read_iter#" \
> -	    -e "s#$warn4#Intentional warnings in xfs_file_aio_read#" \
> -	    -e "s#$warn5#Intentional warnings in iomap_dio_rw#"
> -}
> -
> -# umount before checking dmesg in case umount triggers any WARNING or Oops
> -_scratch_unmount
> -
>  if [ "$FSTYP" == "xfs" ]; then
>  	_check_dmesg filter_xfs_dmesg
>  else
> diff --git a/tests/generic/247 b/tests/generic/247
> index 832ade1..f46ab30 100755
> --- a/tests/generic/247
> +++ b/tests/generic/247
> @@ -80,6 +80,13 @@ wait
>  
>  echo "Silence is golden."
>  
> -# success, all done
> -status=0
> +# unmount and check dmesg, filtering out expected XFS warnings about mixed
> +# mmap/dio
> +_scratch_unmount

generic/247 doesn't take use of SCRATCH_DEV, _scratch_unmount and the
associated comment can be removed.

Thanks,
Eryu

> +if [ "$FSTYP" == "xfs" ]; then
> +	_check_dmesg filter_xfs_dmesg
> +else
> +	_check_dmesg
> +fi
> +status=$?
>  exit
> -- 
> 2.9.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-06-29  6:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 14:14 [PATCH] generic/247: filter out expected XFS warnings for mixed mmap/direct I/O Brian Foster
2017-06-29  6:19 ` Eryu Guan [this message]
2017-06-29 11:54   ` Brian Foster

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=20170629061909.GL23360@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=bfoster@redhat.com \
    --cc=fstests@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox