Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@kernel.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <wqu@suse.com>,
	fstests@vger.kernel.org,  linux-btrfs@vger.kernel.org,
	Christian Borntraeger <borntraeger@linux.ibm.com>
Subject: Re: [PATCH] fstests: add a dio-read-into-mmap and sync race test case
Date: Wed, 5 Aug 2026 22:55:07 +0800	[thread overview]
Message-ID: <anNFEruUSvQ9Xh5r@zlang-mailbox> (raw)
In-Reply-To: <3d4d0167-8acb-44bd-9224-78561ddae4bb@gmx.com>

On Tue, Aug 04, 2026 at 09:11:24AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2026/8/3 20:05, Zorro Lang 写道:
> > On Sat, Jul 25, 2026 at 08:37:24PM +0930, Qu Wenruo wrote:
> > > There is a report that on btrfs, if the following workload are running,
> > > btrfs can fail:
> > > 
> > > - A dio read into a mmaped range
> > >    Only the mmap range needs to be on btrfs.
> > >    The dio read source makes no difference.
> > > 
> > > - Sync_range on the mapped range
> > > 
> > > The btrfs errors include:
> > > 
> > > - Hang during data writeback
> > > - Filesystem flips RO
> > > 
> > > The mmap range is dirtied but written back by the sync_range process,
> > > then dio read finished and found that the folios are no longer dirty,
> > > so dio endio will mark those folios dirty again so that the fs can write
> > > them back again.
> > > 
> > > However for non-experimental btrfs with 4K block size and 4K page size,
> > > there is a regression in v7.2 that such case is no longer handled
> > > properly, due to the enablement of large folios and removal of cow
> > > fixup.
> > > And btrfs can never handle it for bs < ps from day 1.
> > > 
> > > Add a regression test for it.
> > > 
> > > Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> > > Link: https://lore.kernel.org/linux-btrfs/20260721191152.101118-1-borntraeger@linux.ibm.com/
> > > Signed-off-by: Qu Wenruo <wqu@suse.com>
> > > ---
> > 
> > Hi Wenruo,
> > 
> > Thanks for this new test!
> 
> Thanks for the review. Will update the patch to address all the comments and
> refresh the test number.
> 
> But one comment inlined below.
> 
> > > +
> > > +kill "$read_pid" "$sync_pid" &> /dev/null
> > 
> > How about:
> >    kill -TERM -"$read_pid" -"$sync_pid" &> /dev/null
> > ?
> > 
> > As the (man 1 kill) says:
> > 
> >    pid
> >      Each pid can be expressed in one of the following ways:
> >      ...
> >      -n
> >         where n is larger than 1. All processes in process group n are signaled.
> >         When an argument of the form '-n' is given, and it is meant to denote a
> >         process group, either a signal must be specified first, or the argument
> >         must be preceded by a '--' option, otherwise it will be taken as the
> >         signal to send.
> > 
> > I didn't give it a try, but I think this might help to kill the
> > dio-read-into-mmap and sync_range process too.
> 
> Unfortunately this doesn't seems to work.
> 
> If I removed the redirection, it shows the following error:
> 
> /home/adam/xfstests/tests/generic/801: line 76: kill: (-1271) - No such
> process
> /home/adam/xfstests/tests/generic/801: line 76: kill: (-1272) - No such
> process
> 
> Thus it will not really kill the children processes.
> 
> Despite this change, all other comments will be addressed.

Hi Wenruo,

Sorry for the confusion! I assumed that approach would work, but from the
error message, it seems running "read_workload &" doesn't create a proper
Process Group (PGID).

How about this approach instead?

1) kill -TERM "$read_pid" 2>/dev/null

Based on the trap in read_workload(), it should enter "wait" upon receiving
SIGTERM, preventing any new iterations of the loop. Then we can run:

2) pkill -P "$read_pid" 2>/dev/null

to clean up any remaining child processes, followed by a wait for the main
process to exit.

3) wait "$read_pid"
   unset read_pid

(We can wrap this logic in a function and invoke it inside _cleanup)

I hope this can prevent the script from waiting long time, and no orphaned
processes are left behind. Feel free to tell me if anyone has better idea :)

Thanks,
Zorro

> 
> Thanks,
> Qu
> 
> > 
> > (same in _cleanup)
> > 
> > > +unset "$read_pid" "$sync_pid"
> > 
> > unset read_pid sync_pid
> > 
> > > +wait
> > > +
> > > +echo "Silence is golden"
> > > +_exit 0
> > > diff --git a/tests/generic/799.out b/tests/generic/799.out
> > > new file mode 100644
> > > index 00000000..f3fd9fa2
> > > --- /dev/null
> > > +++ b/tests/generic/799.out
> > > @@ -0,0 +1,2 @@
> > > +QA output created by 799
> > > +Silence is golden
> > > -- 
> > > 2.51.2
> > > 
> > > 
> > 
> 
> 

  reply	other threads:[~2026-08-05 14:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 11:07 [PATCH] fstests: add a dio-read-into-mmap and sync race test case Qu Wenruo
2026-08-03 10:35 ` Zorro Lang
2026-08-03 23:41   ` Qu Wenruo
2026-08-05 14:55     ` Zorro Lang [this message]
2026-08-05 21:19       ` Qu Wenruo

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=anNFEruUSvQ9Xh5r@zlang-mailbox \
    --to=zlang@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox