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

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

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

--D