All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] fstests: fix bug with _check_dmesg "some pattern"
Date: Fri, 21 Nov 2025 11:21:25 -0800	[thread overview]
Message-ID: <20251121192125.GP196366@frogsfrogsfrogs> (raw)
In-Reply-To: <16110e3dac5c7476dd5c74bfb50efb4dc1aac5f0.1763747729.git.josef@toxicpanda.com>

On Fri, Nov 21, 2025 at 12:55:34PM -0500, Josef Bacik wrote:
> I've been rigging up Claude to run fstests via an MCP, and part of this
> means it mounts a 9p file system to save the fstests results. This was
> giving me occasional ENODATA errors, which I dug into. Turns out it's a
> race between truncate and read on 9p which is completely normal for 9p,
> but it's uncovering an actual bug in _check_dmesg. The way bash works is
> when you do
> 
> cat foo | whatever > foo
> 
> bash will setup the various communication channels first, which is the |
> and >, and then it will execute the commands. This means that it
> truncates foo FIRST, and then it launches cat. Which means we'd race
> with truncate and sometimes get data, sometimes get nothing. And even
> worse on 9p we'd get ENODATA because we get a 0 read back when we
> thought the isize was reasonable.
> 
> Fix this by changing this case in _check_dmesg to redirect to another
> file, and move that file over $seqres.dmesg to be checked later.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
>  common/rc | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/common/rc b/common/rc
> index a10ac177..947685df 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -4844,7 +4844,14 @@ _check_dmesg()
>  	# test failures. Custom filters are then applied afterwards.
>  	_dmesg_since_test_start | _check_dmesg_filter > $seqres.dmesg
>  	if [ -n "$1" ]; then
> -		cat $seqres.dmesg | $1 > $seqres.dmesg
> +		# We use $seqres.dmesg.tmp because shell will setup the
> +		# redirections first, which means we would truncate
> +		# $seqres.dmesg before cat'ing it. This is racy so sometimes it
> +		# would work, but othertimes it would silently fail, or in the
> +		# case of 9p you'd get ENODATA. We must redirect into a
> +		# temporary file and then move it.
> +		cat $seqres.dmesg | $1 > $seqres.dmesg.tmp && \
> +			mv $seqres.dmesg.tmp $seqres.dmesg

I wonder if this would be simpler put:

	if [ -n "$1" ]; then
		_dmesg_since_test_start | _check_dmesg_filter | $1 > $seqres.dme
	else
		_dmesg_since_test_start | _check_dmesg_filter > $seqres.dmesg
	fi

Fewer tempfiles, etc.

--D

>  	fi
>  
>  	grep -E -q -e "kernel BUG at" \
> -- 
> 2.51.1
> 
> 

      reply	other threads:[~2025-11-21 19:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 17:55 [PATCH] fstests: fix bug with _check_dmesg "some pattern" Josef Bacik
2025-11-21 19:21 ` Darrick J. Wong [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=20251121192125.GP196366@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=josef@toxicpanda.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.