On Mon, Jul 26, 2021 at 11:20:41PM -0700, Allison Henderson wrote: > During an attr rename operation, blocks are saved for later removal > as rmtblkno2. The rmtblkno is used in the case of needing to alloc > more blocks if not enough were available. However, in the case > that neither rmtblkno or rmtblkno2 are set, we can return as soon > as xfs_attr_node_addname completes, rather than rolling the transaction > with an -EAGAIN return. This extra loop does not hurt anything right > now, but it will be a problem later when we get into log items because > we end up with an empty log transaction. So, add a simple check to > cut out the unneeded iteration. > > Signed-off-by: Allison Henderson <allison.henderson@xxxxxxxxxx> > --- > fs/xfs/libxfs/xfs_attr.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c > index d9d7d51..5040fc1 100644 > --- a/fs/xfs/libxfs/xfs_attr.c > +++ b/fs/xfs/libxfs/xfs_attr.c > @@ -409,6 +409,13 @@ xfs_attr_set_iter( > if (error) > return error; > > + /* > + * If addname was successful, and we dont need to alloc > + * or remove anymore blks, we're done. > + */ > + if (!args->rmtblkno && !args->rmtblkno2) > + return 0; Hmm. I applied this patch and saw a regression in xfs/125: --- /tmp/fstests/tests/xfs/125.out 2021-05-13 11:47:55.824859905 -0700 +++ /var/tmp/fstests/xfs/125.out.bad 2021-08-09 09:50:23.839261469 -0700 @@ -11,3 +11,5 @@ + chattr -R -i + modify xattr (2) + check fs (2) +xfs_repair should not fail +(see /var/tmp/fstests/xfs/125.full for details) Which turned out to be repair tripping over an INCOMPLETE xattr key after the fs unmounts cleanly in "+ modify xattr (2)". --D > + > dac->dela_state = XFS_DAS_FOUND_NBLK; > } > return -EAGAIN; > -- > 2.7.4 >
