mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hengyu Liang <hengyul@cs.unc.edu>
To: Carlos Maiolino <cem@kernel.org>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH] xfs: fix f_bfree underflow in statfs()
Date: Thu, 12 Nov 2026 05:20:18 -0500	[thread overview]
Message-ID: <20261112102018.3922571-1-hengyul@cs.unc.edu> (raw)

Commit dd324cb79e54 ("xfs: refactor xfs_fs_statfs") made
xfs_statfs_data() limit f_bfree with max(0LL, ...) instead of
max_t(int64_t, 0, ...).

However, the value is an unsigned difference, so max() never picks 0.
As of now, when the free block counter is below the count of
unavailable blocks, statfs() reports f_bfree and f_bavail close to 2^64
instead of 0, and df prints negative sizes.

A similar issue happened before and was fixed by commit 237aac4624aa
("xfs: ensure f_bfree returned by statfs() is non-negative"). Perhaps
the refactored code needs that fix as well.

The issue can be reproduced on a new 2 GiB filesystem mounted on /mnt:

    for i in $(seq 3000); do head -c 65536 /dev/zero > /mnt/s$i; done
    dd if=/dev/zero of=/mnt/big bs=1M
    xfs_io -x -c 'resblks 100000000' /mnt
    for i in $(seq 1 2 3000); do rm /mnt/s$i; done
    sync
    df -h /mnt

Before commit dd324cb79e54 ("xfs: refactor xfs_fs_statfs"), the result
is:

    Filesystem      Size  Used Avail Use% Mounted on
    /dev/vda        2.0G  2.0G     0 100% /mnt

After that commit, the result is:

    Filesystem      Size  Used Avail Use% Mounted on
    /dev/vda        2.0G  -64Z  -24K 100% /mnt

This patch will compare the difference as a signed value again.

Fixes: dd324cb79e54 ("xfs: refactor xfs_fs_statfs")
Cc: stable@vger.kernel.org # v6.14
Signed-off-by: Hengyu Liang <hengyul@cs.unc.edu>
---
The resblks ioctl only keeps the reproducer short. The same values show
up after filling a filesystem, writing with O_DIRECT into preallocated
space and deleting files.

Application impact (Ubuntu 26.04 user space, XFS root in that state):
on v6.13, "apt install" stops with "You don't have enough free space in
/var/cache/apt/archives/". On v6.14, it prints "18.4 EB available",
starts the download and fails with ENOSPC. GNOME's "Low Disk Space"
notification is sent on v6.13 and not on v6.14.

Tested on xfs for-next: with this patch, df, apt and the notification
behave as on v6.13.

 fs/xfs/xfs_super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 5a06132aa384..42be6bd34d43 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -916,7 +916,7 @@ xfs_statfs_data(
 		xfs_sum_freecounter(mp, XC_FREE_BLOCKS);
 
 	/* make sure st->f_bfree does not underflow */
-	st->f_bfree = max(0LL,
+	st->f_bfree = max_t(int64_t, 0,
 		fdblocks - xfs_freecounter_unavailable(mp, XC_FREE_BLOCKS));
 
 	/*

base-commit: 48326a2382d80715475d10ce98734ac65d2d2150
-- 
2.53.0


             reply	other threads:[~2026-11-12 10:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 10:20 Hengyu Liang [this message]
2026-11-12 13:44 ` Christoph Hellwig
2026-11-12 15:07   ` Hengyu Liang

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=20261112102018.3922571-1-hengyul@cs.unc.edu \
    --to=hengyul@cs.unc.edu \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®