Re: [PATCH 09/12] xfs: break out of zoned reservation loop if signals are pending

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Sep 25, 2026 at 12:18:30PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 24, 2026 at 10:41:54PM -0700, Christoph Hellwig wrote:
> > On Thu, Sep 24, 2026 at 09:12:51PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > I noticed that if you run generic/476 for long enough on a zoned
> > > filesystem that it runs out of space in the zoned section, fsstress gets
> > > stuck in this loop trying to reserve space, failing, and kicking off the
> > > gc.
> > 
> > I guess this is not directly fixed here, right?
> 
> Correct.  There's enough space freeing activity going on (truncate,
> punch, unlink, etc) so that the gc actually does clear out zones; but
> there are also enough writers consuming more space that they all end up
> in this loop at some point, and some of the threads never manage to get
> what they want from rtavailable.
> 
> > > The garbage collector in turn is continuously running (so we don't
> > > break out of the loop) but the process is no longer responsive to
> > > signals and can't be killed.
> > > 
> > > Fix this by backing out to userspace for any pending signal.  This
> > > should be safe because space reservation is usually the first step in
> > > any modification to a zoned file.
> > > 
> > > Cc: <hch@lst.de>
> > > Cc: <stable@vger.kernel.org> # v6.15
> > > Fixes: 0bb2193056b596 ("xfs: add support for zoned space reservations")
> > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > ---
> > >  fs/xfs/xfs_zone_space_resv.c |    5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > 
> > > diff --git a/fs/xfs/xfs_zone_space_resv.c b/fs/xfs/xfs_zone_space_resv.c
> > > index 7aa3c74fb2e01a..8edc82025abbd5 100644
> > > --- a/fs/xfs/xfs_zone_space_resv.c
> > > +++ b/fs/xfs/xfs_zone_space_resv.c
> > > @@ -157,6 +157,11 @@ xfs_zoned_reserve_available(
> > >  		if (error != -ENOSPC)
> > >  			break;
> > >  
> > > +		if (signal_pending(current)) {
> > > +			error = -ERESTARTSYS;
> > > +			break;
> > > +		}
> > 
> > I don't think normal fs read/write semantics allow for -ERESTARTSYS
> > on arbitrary signals.  So this should probably be limited to
> > fatal_signal_pending().
> 
> Ok.  That at least means I can ^C the g/476 test processes. :)

Heh.  Rereading my notes it was always possible to kill -9 the process,
but the difficulty with fsstress is that it uses SIGTERM sets a global
flag to tell its threads to exit their file IO loops.  Since that's not
a fatal action, fatal_signal_pending() returns false and so the thread
remains stuck looping in the kernel.

--D