All of lore.kernel.org
 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: 6+ 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
2026-08-10 20:54         ` Zorro Lang

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 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.