Allen Hewes [Tue, 14 Jul 2026 23:21:03 +0000 (23:21 +0000)]
xfsprogs: healer: install targets one at a time
libtool's --mode=install requires the destination to already exist
as a real directory whenever more than one source file is given
(it emulates cp/install semantics, which have the same requirement).
Installing xfs_healer and xfs_healer_start in a single LTINSTALL
call trips this check on any build where HAVE_HEALER_START_DEPS=yes,
since PKG_LIBEXEC_DIR isn't guaranteed to exist under the raw,
un-DESTDIR'd path libtool checks. Install each target separately
to avoid the multi-file directory check entirely.
Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Allen Hewes <rallenh@hotmail.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Darrick J. Wong [Mon, 13 Jul 2026 15:55:10 +0000 (08:55 -0700)]
xfs_scrub: fix spacemap scan for data volume
I don't know why this hunk got copied into scan_ag_rmaps on merge. The
original patch only touched scan_rtg_rmaps. Get rid of this new
inclusion because now it's broken for the data device.
Cc: linux-xfs@vger.kernel.org # v7.1.0 Fixes: 074c18165ea339 ("xfs_scrub: fix spacemap scan for internal rt devices") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
mdrestore: fix extent length overflow in v2 restore path
Aisle Research reported that a crafted metadump v2 extent
length can overflow the signed int used for length,
leading to incorrect size calculations and a
potential heap buffer over-read in restore_meta_extent().
Change the length type to uint64_t and ensure all size
arithmetic in 64-bit before converting to size_t for I/O
calls.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Manognya Singuru <msinguru@redhat.com>
liuh [Wed, 24 Jun 2026 08:11:35 +0000 (16:11 +0800)]
fsr: preserve xfrog_bulkstat error codes
Fix the bulkstat loop condition in fsrfs() to assign the return
value of xfrog_bulkstat() to ret before comparing it against zero.
Without the extra parentheses, operator precedence causes ret
to receive only the result of the comparison (0 or 1), which
discards the actual error code and breaks error reporting.
Signed-off-by: liuh <liuhuan01@kylinos.cn> Cc: <linux-xfs@vger.kernel.org> # v5.3.0 Fixes: e6542132dec3cd ("libfrog: convert bulkstat.c functions to negative error codes") Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Old kernels did not zero the pad field in xfs_dir3_data_hdr when
initializing directory data blocks, so existing filesystems may have
non-zero padding on disk.
Zero the pad field in xfs_dir3_data_write_verify alongside the existing
LSN and checksum updates. The pad field is pure alignment padding with
no runtime meaning, so zeroing it during write verification is safe and
has no additional I/O cost. This lets filesystems gradually self-heal
stale non-zero padding as directories are modified, without requiring an
explicit repair pass.
Suggested-by: Dave Chinner <dgc@kernel.org> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_dir3_data_init currently zeroes only the xfs_dir3_blk_hdr portion of
the directory data block header, then manually initializes the bestfree
entries in a loop. This leaves the pad field in xfs_dir3_data_hdr
uninitialized and requires explicit zeroing of each bestfree slot.
Zero the entire header region (geo->data_entry_offset bytes)
unconditionally before setting individual fields. This covers all
current and future header fields, all padding (implicit and explicit),
and the bestfree array, so the manual zeroing loop for bestfree can be
removed.
Suggested-by: Dave Chinner <dgc@kernel.org> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
In xfs_refcount_finish_one(), there's no need to pass
XFS_ALLOC_FLAG_FREEING to xfs_alloc_read_agf().
So remove it.
Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
The per-AG buffer hashes were added when all buffer lookups took a
per-hash look. Since then we've made lookups entirely lockless and
removed the need for a hash-wide lock for inserts and removals as
well. With this there is no need to sharding the hash, so reduce the
used resources by using a per-buftarg hash for all buftargs.
Long after writing this initially, syzbot found a problem in the buffer
cache teardown order, which this happens to fix as well by doing the
entire buffer cache teardown in one places instead of splitting it
between destroying the buftarg and the perag structures.
Link: https://lore.kernel.org/linux-xfs/aLeUdemAZ5wmtZel@dread.disaster.area/ Reported-by: syzbot+0391d34e801643e2809b@syzkaller.appspotmail.com Reviewed-by: Darrick J. Wong <djwong@kernel.org> Tested-by: syzbot+0391d34e801643e2809b@syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
There is currently no XFS ioctl that allows userspace to retrieve the
write pointer for a specific realtime group block for zoned XFS. On zoned
block devices, userspace can obtain this information via zone reports from
the underlying device. However, for zoned XFS operating on regular block
devices, no equivalent mechanism exists.
Access to the realtime group write pointer is useful to userspace
development and analysis tools such as Zonar [1]. So extend the existing
struct xfs_rtgroup_geometry to add a new rg_writepointer field. This field
is valid if XFS_RTGROUP_GEOM_WRITEPOINTER flag is set. The rg_writepointer
field specifies the location of the current writepointer as a block offset
into the respective rtgroup.
Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
Darrick J. Wong [Tue, 30 Jun 2026 17:12:02 +0000 (10:12 -0700)]
xfs_scrub: fix spacemap scan for internal rt devices
The scrub media scan on a filesystem with an internal rt volume still
fails with:
# xfs_scrub -dTvnx /mnt
Phase 6: Verify data file integrity.
Error: dev 7:0 rtgroup 1 fsmap: Invalid argument. (spacemap.c line 162)
Error: dev 7:0 rtgroup 0 fsmap: Invalid argument. (spacemap.c line 162)
Info: /mnt: Scrub aborted after phase 6. (xfs_scrub.c line 522)
(this was from xfs/586)
When I tried to add support for internal rt devices in commit 37591ef3f4f14c ("xfs_scrub: support internal RT device"), I forgot that
fsmap reports physical offsets into the underlying block device, and
therefore expects the query keys to reflect that. Put another way, to
scan a single rtgroup, one must add @rtstart to the fmr_physical field
of the query keys.
This hasn't been reported until now because we inadvertently also
disabled spacemap scans of internal rt volumes until commit 3e4bb144f657b1 ("xfs_scrub: handle media scans of internal rt devices
correctly").
Cc: <linux-xfs@vger.kernel.org> # v6.15.0 Fixes: 37591ef3f4f14c ("xfs_scrub: support internal RT device") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
[aalbersh: squashed with accidentally split patch]
Darrick J. Wong [Wed, 10 Jun 2026 22:12:01 +0000 (15:12 -0700)]
mkfs: PQUOTA shouldn't conflict with GQNOENFORCE
Codex points out that project quota isn't incompatible with
non-enforcing group quota in the kernel, so those shouldn't be
incompatible in mkfs either.
Furthermore, project and group quotas are never incompatible on QUOTABIT
and V5 filesystems, so this is clearly a fat-finger error.
Cc: <linux-xfs@vger.kernel.org> # v6.13.0 Fixes: 525f826429a868 ("mkfs: add quota flags when setting up filesystem") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 17:17:09 +0000 (10:17 -0700)]
mkfs: fix hardlink detection in directory import code
There's a serious problem in the hardlink detection code in the new mkfs
protofile functionality that copies a directory tree into the new
filesystem. It's been long established that hardlinks can only be
detected by comparing st_ino *and* st_dev, but the new code doesn't do
that. Fix the detector.
Cc: <linux-xfs@vger.kernel.org> # v6.17.0 Fixes: 8a4ea72724930c ("proto: add ability to populate a filesystem from a directory") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 30 Jun 2026 16:35:03 +0000 (09:35 -0700)]
mkfs: pass stat buf pointers around the protofile code
Not sure why the author of the new mkfs copy-in code sometimes passed
struct stat objects around by value, but let's clean up the code to pass
(const struct stat *) pointers around instead. This will make the next
patch (which fixes hardlink detection) more neat.
While we're at it, introduce some helper variables to reduce long lines.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 9 Jun 2026 16:14:46 +0000 (09:14 -0700)]
xfs_protofile: make nondirectory arguments actually work
Codex points out that xfs_protofile fails if you pass it paths to
non-directories. It's supposed to just copy them into the root
directory, but we don't actually do that.
Cc: <linux-xfs@vger.kernel.org> # v6.13.0 Fixes: 6aace700b7b82d ("mkfs: add a utility to generate protofiles") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 17:08:35 +0000 (10:08 -0700)]
mkfs: fix symlink target length check in create_nondir_inode
Codex complains about the way this function tries to detect symlink
targets that are so long that the new filesystem cannot handle them.
Specifically, it complains about the confusion between
XFS_SYMLINK_MAXLEN and PATH_MAX.
To be clear, XFS cannot handle targets longer than XFS_SYMLINK_MAXLEN
bytes. PATH_MAX is irrelevant here. The manpage for readlink(3) says
that it returns the number of bytes copied into the buffer and does not
say that it null-terminates the buffer. Therefore, the only way to
detect the overflow condition is to declare a buffer larger than
XFS_SYMLINK_MAXLEN and see if readink returns a value greater than
XFS_SYMLINK_MAXLEN.
Cc: <linux-xfs@vger.kernel.org> # v6.17.0 Fixes: 8a4ea72724930c ("proto: add ability to populate a filesystem from a directory") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 17:03:09 +0000 (10:03 -0700)]
mkfs: fix PATH_MAX check
Per the snprintf manpage, the correct means to check snprintf for an
insufficiently large buffer is to check if its return value is >= @size,
not > @size. Codex found this.
Cc: <linux-xfs@vger.kernel.org> # v6.17.0 Fixes: 8a4ea72724930c ("proto: add ability to populate a filesystem from a directory") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 16:58:05 +0000 (09:58 -0700)]
mkfs: don't redefine DIRT for protofiles
Codex noticed that the mkfs Makefile redefines DIRT to point only to the
xfs_protofile script. This overrides the more expansive definition in
buildrules; we should use LDIRT instead.
Cc: <linux-xfs@vger.kernel.org> # v6.13.0 Fixes: 6aace700b7b82d ("mkfs: add a utility to generate protofiles") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 30 Jun 2026 01:04:59 +0000 (18:04 -0700)]
xfs_healer: fix getmntent race in weakhandle
Codex points out that getmntent() can't be used in threaded programs
because it might employ hidden global static buffers. GNU and musl libc
provide a getmntent_r variant that requires the caller to establish the
buffers, so let's use that.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 54c0ba68b007b3 ("xfs_healer: use getmntent to find moved filesystems") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
The rtrefcount btree inode is not *so* corrupt that it's full of random
i18n garbage; valgrind confirms that we're walking off the end of
iocur_top->buf. Looking at what set_iocur_type does, I think it should
be (re)reading the existing buffer while preserving the existing
boff/len fields. Instead, it resets the buffer size to 1 fssector, but,
oddly, preserving boff (and not len). This is why we go off the end of
the buffer.
After fixing, I get:
# xfs_db /dev/sdf -c 'path -m /rtgroups/0.refcount' -c 'type text' -c print -c stack
000: 49 4e 80 00 03 05 00 08 00 00 00 00 00 00 00 00 IN..............
010: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
020: 35 ed d7 36 1e e0 aa 20 35 ed d7 36 1e e0 aa 20 5..6....5..6....
030: 35 ed d7 36 1e e0 ae 08 00 00 00 00 00 00 00 00 5..6............
Truncated for brevity; this is much better.
Cc: linux-xfs@vger.kernel.org # v5.18.0 Fixes: 0d376f6cf1799b ("xfs_db: take BB cluster offset into account when using 'type' cmd") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 30 Jun 2026 01:02:39 +0000 (18:02 -0700)]
xfs_scrub: fix estimate of work items for phase 4
Codex complains that the number of work items computed when estimating
the amount of work for phase 4 doesn't include the FSCOUNTERS and
QUOTACHECK items. Add them back in.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 30 Jun 2026 01:02:24 +0000 (18:02 -0700)]
xfs_scrub: fix spacemap external log device scan dev key
Codex bizarrely complains about the rtstart>0 logic in scan_log_rmaps,
because it gets confused about the difference between internal logs
(which are scanned by scan_ag_rmaps) and external logs, which this
function handles. I'm ignoring the report, but we shouldn't open-code
the synthetic device keys so let's fix that by hoisting the fsmap device
helpers from phase6.c to spacemap.h and using them everywhere.
Cc: linux-xfs@vger.kernel.org # v6.15.0 Fixes: 37591ef3f4f14c ("xfs_scrub: support internal RT device") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 10 Jun 2026 21:57:33 +0000 (14:57 -0700)]
xfs_scrub: always finish cleanup, even if reporting healthy state fails
Codex points out here that we should always release resources used by
the program, even if reporting healthy state to the kernel itself fails.
We're exiting soon anyway so this probably doesn't make much of a
difference.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 9 Jun 2026 16:53:36 +0000 (09:53 -0700)]
xfs_scrub: fix phase 8 debug reporting
Codex observes that the debug printf in fstrim_compute_minlen always
prints a threshold of 0 because we never actually set the block
threshold variable. Fix that by using the results of the
multiplication that's passed into minlen_for_threshold.
Cc: <linux-xfs@vger.kernel.org> # v6.10.0 Fixes: 34bed605490f93 ("xfs_scrub: tune fstrim minlen parameter based on free space histograms") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 9 Jun 2026 16:49:22 +0000 (09:49 -0700)]
xfs_scrub: don't leak phase 5 scan items after a failed workqueue_add
Codex points out that queue_metapath_scan and queue_fs_scan fail to free
the allocated items if they are not consumed by workqueue_add().
Cc: <linux-xfs@vger.kernel.org> # v6.9.0 Fixes: 8fb4b471322e65 ("xfs_scrub: use multiple threads to run in-kernel metadata scrubs that scan inodes") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 16:24:48 +0000 (09:24 -0700)]
xfs_scrub: actually handle NEEDSCHECK scrub items in phase 4
While reading the code in repair.c while triaging another Codex
complaint, I remembered that phases 2 and 3 react to an un-scannable
metadata object by dumping them on the repair list for phase 4 with the
"NEEDSCHECK" flag set. However, repair_item() doesn't actually process
those NEEDSCHECK items, which means that we could silently fail to
complete a full scan.
There are two ways that repair_item() gets called -- one is the action
list processing in phase 4; and the other is repair_item_completely,
which is called directly from phases 2, 5, and 7. Action list items
never have NEEDSCHECK set because repair_item_to_action_item promotes
them into "corruptions" to force a check; and the repair_item_completely
callers only ever pass in actual corruptions.
Therefore, we should amend repair_item() to process NEEDSCHECK action
items so as not to leave a logic bomb for future authors. We should
also set sri_inconsistent so that any errors that are found during the
NEEDSCHECK scans result in a revalidation after the repair.
However, there's a real bug in repair_item_to_action_item. If @sri says
there's at least one NEEDSCHECK item but no corruption elsewhere, then
we exit early instead of queuing an action list item. This apparently
doesn't happen much in the online fsck QA suite becuase phases 2 and 3
aggressively try to clear NEEDSCHECK items and only deferring scans to
phase 4 if they cannot make any forward progress.
Cc: <linux-xfs@vger.kernel.org> # v6.10.0 Fixes: 83ffb5b454b172 ("xfs_scrub: start tracking scrub state in scrub_item") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 15:41:52 +0000 (08:41 -0700)]
xfs_scrub: don't flatten error numbers in read_verify_schedule_now
Codex complains about using a bool variable to convey the results of
workqueue_add (which returns int) to rvp->runtime_error (which is
declared int). As originally written in commit 2000470d5376e4, this
type inconsistency was a benign thinko because code branching decisions
were made based on whether or not workqueue_add returned nonzero but the
error itself was not preserved. However, commit 5c657f1e5a9329 started
preserving the errors but didn't change the @ret declaration, so that's
where the bug was introduced.
Cc: <linux-xfs@vger.kernel.org> # v5.3.0 Fixes: 5c657f1e5a9329 ("xfs_scrub: fix handling of read-verify pool runtime errors") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Mon, 8 Jun 2026 15:35:17 +0000 (08:35 -0700)]
xfs_scrub: stop user file scan if caller already aborted
Codex points out that scrub_scan_user_files keeps calling
scan_user_bulkstat in a loop even if something else aborts the scan.
That's rather pointless, so fix that.
Cc: <linux-xfs@vger.kernel.org> # v6.14.0 Fixes: 279b0d0e8d73f1 ("xfs_scrub: call bulkstat directly if we're only scanning user files") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:17:22 +0000 (11:17 -0700)]
xfs_scrub: warn about difficult rtgroup repairs
Codex noticed that rtgroup metadata repairs can be difficult (e.g.
rtrmap) but we don't ever warn the user about that. Scrub does that for
per-AG and fs metadata, so do that here too.
Cc: linux-xfs@vger.kernel.org # v6.13.0 Fixes: 241d915d69d4ae ("xfs_scrub: scrub realtime allocation group metadata") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:17:06 +0000 (11:17 -0700)]
xfs_scrub: don't leak the autofsck fsproperty handle
Codex notices that we leak the fsproperty handle if the filesystem
doesn't actually have the property set. Fix that by moving the free
call; it can handle a totally nulled out structure.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: 9451b5ee0d0d2d ("xfs_scrub: allow sysadmin to control background scrubs") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:16:35 +0000 (11:16 -0700)]
xfs_scrub: account only data extent tail after an overlap
Codex points out that the fsmap overlap handling in phase7 isn't quite
right -- if we already saw part of the current fsmapping, we should
*subtract* the overlap, not set the length to it! Fix that.
Cc: linux-xfs@vger.kernel.org # v4.15.0 Fixes: 698c6c7cb8ba75 ("xfs_scrub: check summary counters") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:16:04 +0000 (11:16 -0700)]
xfs_scrub: warn about incomplete repairs if we never get to them
If the final pass at repairs fails because the kernel says the
filesystem is busy, we should emit this error to the caller instead of
dropping it silently.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:15:48 +0000 (11:15 -0700)]
xfs_scrub: don't skip bulkstat batch when scrub_scan_user_files helper returns ESTALE
Codex complains that the ESTALE in the switch statement results in the
rest of the bulkstat batch being skipped, and that ECANCELED doesn't
actually abort the walk immediately. scrub_scan_user_files is only
called during phases 5 and 6, which is after we've verified all the file
metadata in the filesystem. Therefore, an ESTALE here means that the
file was deleted, so we skip it and move on to the next file. Fix both
issues.
Cc: linux-xfs@vger.kernel.org # v6.14.0 Fixes: 279b0d0e8d73f1 ("xfs_scrub: call bulkstat directly if we're only scanning user files") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:15:17 +0000 (11:15 -0700)]
xfs_scrub: handle media scans of internal rt devices correctly
Codex noticed media scans of internal rt devices don't work at all
correctly. First, we fail to allocate a ctx->verify_disks[XFS_DEV_RT]
for the internal rt section, and even if we did, phase 6 doesn't
allocate media_verify_state.rvp[XFS_DEV_RT] if there's a media error on
an internal rt volume, so we'll crash there too.
Fix both issues to make it work properly.
Cc: linux-xfs@vger.kernel.org # v6.15.0 Fixes: 37591ef3f4f14c ("xfs_scrub: support internal RT device") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:15:02 +0000 (11:15 -0700)]
xfs_scrub: report bad file ranges correctly
Codex complains that the "media error at data offset..." message prints
the wrong information -- err_off is the offset into @map, not the file
offset; and the length should be constrained by the end of @map. Fix
both of these issues.
Cc: linux-xfs@vger.kernel.org # v4.15.0 Fixes: b364a9c008fc04 ("xfs_scrub: scrub file data blocks") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Wed, 24 Jun 2026 18:14:46 +0000 (11:14 -0700)]
xfs_scrub: handle missing media verify ioctl failure return codes
Back when we reworked the read-verify code to use the kernel ioctl to
perform media scans, we forgot to teach read_verify_one callers to
handle the new error codes. Codex noticed this discrepancy, so let's
fix that.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 02760878dd86b9 ("xfs_scrub: use the verify media ioctl during phase 6 if possible") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Thu, 11 Jun 2026 14:06:23 +0000 (07:06 -0700)]
xfs_healer: allow AF_UNIX socket access for xfs_healer instances
When xfs_healer cannot fix a filesystem problem on its own,
run_full_repair function tries to start an xfs_scrub service instance to
scan the entire filesystem. Unfortunately, as Codex points out, the
service definition for xfs_healer instances doesn't allow AF_UNIX
sockets, so that will fail. Relax the security posture so that we can
do that.
Darrick J. Wong [Thu, 11 Jun 2026 14:06:08 +0000 (07:06 -0700)]
xfs_healer_start: increase statmount buffer size
Codex points out that our statmount call asks for the mount point,
filesystem type, and mount root data for each mount. The first and
last items in that sequence are paths, so we need at least PATH_MAX for
each of them to avoid overflowing the buffer. I don't know what is the
maximum filesystem type string length so we'll just hope that NAME_MAX
is enough. Switch the allocation to dynamic because 9k is a lot.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 11 Jun 2026 14:05:37 +0000 (07:05 -0700)]
xfs_healer_start: check listmount when doing a --check
Codex noticed that xfs_healer_start doesn't try out listmount() when
it's doing a --check. Because systemd uses --check for an
ExecCondition, if it's run on a pre-6.9 kernel (very unlikely) then the
service will fail instead of simply not being run. Fix that.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 11 Jun 2026 14:05:21 +0000 (07:05 -0700)]
xfs_healer: don't allow aliasing of mon_fd in setup_monitor
As the comment says, mon_fp consumes ownership of mon_fd. Therefore, we
should set mon_fd to -1 so that we can't use it further on. Codex
complains about this logic bomb.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: b9b03770197d19 ("xfs_healer: create daemon to listen for health events") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 11 Jun 2026 14:05:06 +0000 (07:05 -0700)]
libfrog: fix buffer overflow in getparents path_to_string
Codex points out rather indirectly that snprintf returns the number of
bytes that would be formatted into the buffer excluding the null
terminator. However, it won't format more bytes than the size
parameter, so the proper way to detect overflows is to compare the
return value against the size parameter. Fix that.
Darrick J. Wong [Thu, 4 Jun 2026 06:09:47 +0000 (23:09 -0700)]
xfs_scrub: read verification isn't ok if it hit runtime errors
Codex complains that a read-verify pool couldn't possibly be ok if
someone set the runtime_error field to a nonzero value. That's true, so
fix the predicate.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 58fca77c2d2ae8 ("xfs_scrub: move failmap and other outputs into read_verify_pool") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:09:31 +0000 (23:09 -0700)]
xfs_scrub: bitmap iteration functions must retur
bitmap_iterate doesn't generate its own errors, so don't invert the sign
of the errors returned from retry_deferred_inode_range. This keeps them
all positive, which is something that Codex is good at noticing and I'm
not. :P
Darrick J. Wong [Thu, 4 Jun 2026 06:09:16 +0000 (23:09 -0700)]
xfs_scrub: don't obscure repair failures in repair_list_schedule
Codex points out that if we bail out of the loop in repair_everything
due to an operational error, the workqueue cleanup blows away the error
code and we return as if nothing went wrong. Let's fix that so that
operational errors cause the program to exit with failure.
Darrick J. Wong [Thu, 4 Jun 2026 06:08:45 +0000 (23:08 -0700)]
xfs_scrub: don't crash trying to complain about clean health
Codex points out that the str_info call in report_to_kernel can crash
because of the null argument. This whole callsite is fubar because
the third argument is supposed to be a format string, and it's supposed
to print the mountpoint too. Fix all this.
Darrick J. Wong [Thu, 4 Jun 2026 06:08:29 +0000 (23:08 -0700)]
xfs_scrub: don't continue with phase1 if autofsck=none
If xfs_scrub was started with -o autofsck and the filesystem's autofsck
property says not to run xfs_scrub, we should exit phase 1 early so that
the rest of the validation checks don't need to run. Codex points out
that the current code can fail pointlessly in this manner.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: 9451b5ee0d0d2d ("xfs_scrub: allow sysadmin to control background scrubs") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:08:14 +0000 (23:08 -0700)]
xfs_scrub: don't return garbage value from bulkstat_the_rest
bulkstat_the_rest returns an inode mask, but Codex noticed that we
carelessly return an error number if we can't allocate a bulkstat
request. Fix this by returning 0, which forces the caller to singlestep
the rest of the bulkstat array.
Cc: linux-xfs@vger.kernel.org # v6.14.0 Fixes: 7ae92e1cb0aeeb ("xfs_scrub: try harder to fill the bulkstat array with bulkstat()") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:07:58 +0000 (23:07 -0700)]
xfs_scrub: reset bulkstat pointer on retry
Codex points out that we don't reset the struct bulkstat array pointer
if we decide to re-issue the inumbers and bulkstat calls. Fix that, and
fix the @error variable being returned uninitialized if hdr.ocount is
zero.
Cc: linux-xfs@vger.kernel.org # v5.18.0 Fixes: 9f4d6358e28ba1 ("xfs_scrub: don't revisit scanned inodes when reprocessing a stale inode") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:07:43 +0000 (23:07 -0700)]
xfs_scrub: don't allow NAN as fstrim percentage
Don't let users pass us -o fstrim_pct=NaN, because strtod will happily
return what looks like success but isn't actually a number. Codex found
this fun little nit.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: 34bed605490f93 ("xfs_scrub: tune fstrim minlen parameter based on free space histograms") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:07:27 +0000 (23:07 -0700)]
xfs_scrub: fix nonsense advice after a scrub finds errors
If a user ran xfs_scrub -p (aka optimization-only mode) and it found
errors, we advise the user to run without -n. That's silly, because
they didn't run with -n, they ran with -p. Fix the messaging here.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: 84e248f3e83f36 ("xfs_scrub: add an optimization-only mode") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:06:56 +0000 (23:06 -0700)]
xfs_scrub: don't report media errors in specially-owned areas as file data
If a media error occurs for some disk space that has a "special" owner,
we mustn't try to walk parent pointers because special owners are not
files. If it's an extent map, we shouldn't accidentally fall into
reporting that as file data loss. This was, like the rest, found by
Codex.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:06:40 +0000 (23:06 -0700)]
xfs_scrub: fix work estimation for rtgroups filesystems
Codex noticed that phase2_func queues up scrub work items for every
rtgroup in the system and tracks progress towards that number of work
items, but that it doesn't include the rtgroups in the estimate. This
leads to the user-papercut of the progressbar quickly advancing to 100%
and then wedging there for most of the rt metadata scan. Let's fix this
by amending the group estimator function.
Darrick J. Wong [Thu, 4 Jun 2026 06:06:25 +0000 (23:06 -0700)]
xfs_scrub: widen scrub and repair dependency mask
Codex observes:
"Since `XFS_SCRUB_TYPE_NR` is now 33 (`XFS_SCRUB_TYPE_RTREFCBT` is 32),
any scheduled scrub item drives this loop to `j == 32`, where `1U << j`
shifts a 32-bit unsigned value by its width. That is undefined behavior
(and will trip UBSan or allow miscompilation of dependency scheduling);
the dependency mask and shift need to use a type wide enough for all
scrub types, e.g. `1ULL`/`uint64_t`."
The presence of a shift overflow is correct, since there are now 33
scrub type codes. However, the local loop variable isn't the only
problem here -- scrub_deps and repair_deps are masks, and they aren't
wide enough. As a result, there's a lurking logic bomb because RTREFCBT
will never get selected.
Fortunately this is benign because no scrub/repair type depends on
RTREFCBT, which is why we haven't seen any complaints. But let's
eliminate an avenue for us to forget to fix the problem. Widen the
masks and the local variable to fix the problem.
Darrick J. Wong [Thu, 4 Jun 2026 06:06:09 +0000 (23:06 -0700)]
xfs_scrub: don't count internal log space in the data device used count
Internal logs are not considered free space, so for the data device
they've already been subtracted from xfs_fsop_counts::freedata by
XFS_IOC_FSCOUNTS. This causes overcounting in the phase 7 reporting.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 95a92c5cecb2e1 ("xfs_scrub: perform media scanning of the log region") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:05:54 +0000 (23:05 -0700)]
xfs_scrub: fix integer overflows
agblocks is a 32-bit variable, which means that on a filesystem with a
large AG block count (e.g. 2^31 blocks on a 1k fsblock fs) the
multiplication with 95 could cause an integer overflow. Let's just do
64-bit arithmetic here. Codex found this.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: 34bed605490f93 ("xfs_scrub: tune fstrim minlen parameter based on free space histograms") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:05:23 +0000 (23:05 -0700)]
xfs_scrub_fail: send content headers for xfs_scrub_all failures
Codex noted that fail_mail() doesn't include the same content headers
that fail_mail_mntpoint() does. As a result, utf8 encoded content for
xfs_scrub_all failures might not be interpreted correctly by mailers,
whereas they will for xfs_scrub@ failures. Fix this by emitting C-T-E
and C-T headers so that mailers will see this as 8-bit encoded utf8.
One could argue that the choice of utf8 is actually system-dependent and
ought to added by the MTA, etc. but I suspect that 99.9% of Linux
systems out there are using utf8 and not some other legacy encoding.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: e040916f649f71 ("xfs_scrub_all: failure reporting for the xfs_scrub_all job") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:05:07 +0000 (23:05 -0700)]
xfs_scrub_all_fail: reduce security lockdowns to avoid postfix problems
The same lockdown logic of commit 9042fcc08eed6a ("xfs_scrub_fail:
tighten up the security on the background systemd service") was applied
to the media scan failure reporting service. Therefore, it's also
broken on systems that have setgid mailer programs (e.g. postfix). Fix
this by applying the same change from commit 15fd6fc686d5ce here too.
While we're at it, put this service in the background scrub slice for
resource control.
Cc: linux-xfs@vger.kernel.org # v6.17.0 Fixes: 15fd6fc686d5ce ("xfs_scrub_fail: reduce security lockdowns to avoid postfix problems") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Fixes: e040916f649f ("xfs_scrub_all: failure reporting for the xfs_scrub_all job") Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:04:52 +0000 (23:04 -0700)]
xfs_scrub_all: fix broken command line string array construction
In scrub_subprocess::__init__(), we construct cmd as an array of strings
to be passed (eventually) to exec. Unfortunately, adding a string to an
array of strings doesn't do what you'd think in Python:
>>> x = ['moo', 'cow']
>>> x += '-x'
>>> x
['moo', 'cow', '-', 'x']
Fix this problem, which Codex has sharp enough eyes to catch.
Cc: linux-xfs@vger.kernel.org # v6.10.0 Fixes: a290edcfa0a391 ("xfs_scrub_all: encapsulate all the subprocess code in an object") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Thu, 4 Jun 2026 06:04:36 +0000 (23:04 -0700)]
xfs_scrub_media_fail: reduce security lockdowns to avoid postfix problems
The same lockdown logic of commit 9042fcc08eed6a ("xfs_scrub_fail:
tighten up the security on the background systemd service") was applied
to the media scan failure reporting service. Therefore, it's also
broken on systems that have setgid mailer programs (e.g. postfix).
Fix this by applying the same change from commit 15fd6fc686d5ce here
too.
Cc: linux-xfs@vger.kernel.org # v6.17.0 Fixes: 15fd6fc686d5ce ("xfs_scrub_fail: reduce security lockdowns to avoid postfix problems") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Fixes: 45ec29cfba02 ("xfs_scrub_all: support metadata+media scans of all filesystems") Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Building libfrog
[CC] gen_crc32table
[GENERATE] crc32table.h
gmake[4]: *** No rule to make target '/builds/buildroot.lorg/buildroot/test-output/TestXfs/host/include/urcu.h', needed by 'avl64.lo'. Stop.
Darrick J. Wong [Tue, 2 Jun 2026 04:59:53 +0000 (21:59 -0700)]
xfs_healer: coordinate access to weakhandle::mntpoint correctly
Codex complained about a potential UAF in the weakhandle code if one
thread is walking weakhandle::mntpoint at exactly the same instant that
another thread calls try_update_mntpoint to update the mntpoint pointer
and free the old mntpoint string. This can only happen if the sysadmin
decides to move the mountpoint while the kernel is logging runtime
errors and healer is trying to fix them, but it /is/ a UAF.
Fix this by transforming the existing static lock into a rwlock and
hoisting it to struct weakhandle. Then make sure that we take it for
all accesses to the mntpoint string.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 1a5eeddf738c80 ("xfs_healer: update weakhandle mountpoint when reconnecting") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 2 Jun 2026 04:59:21 +0000 (21:59 -0700)]
xfs_healer: fix Makefile errors
Codex had a couple of complaints about the makefile -- mostly that it
never cleans up after xfs_healer_start; and that it should use LTINSTALL
to install libtool binaries.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 2 Jun 2026 04:59:06 +0000 (21:59 -0700)]
xfs_healer: run a full xfs_scrub repair if we don't know how to do a spot repair
Codex noticed that there are a few sickness event flags that we don't
explicitly handle in fsrepair.c. These three codes
(XFS_FSOP_GEOM_SICK_METADIR, XFS_FSOP_GEOM_SICK_METAPATH, and
XFS_AG_GEOM_SICK_INODES) can't be handled from within xfs_healer, so we
should trigger a full xfs_scrub run to try to fix those problems.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: a162dc462186a6 ("xfs_healer: run full scrub after lost corruption events or targeted repair failure") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 2 Jun 2026 04:58:50 +0000 (21:58 -0700)]
xfs_healer: initialize variable here
Initialize the event prefix to zeroes so that we don't read bogus stack
data if the filesystem doesn't support parent pointers. Found by Codex.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 17d840245c0e20 ("xfs_healer: use getparents to look up file names") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 2 Jun 2026 04:58:35 +0000 (21:58 -0700)]
xfs_healer: recommend offline fsck for XCORRUPT repairs
If the kernel thinks the repair succeeded but the re-scrub cannot
complete the cross-referencing checks, we should recommend an offline
repair instead of reporting the repair as completely successful or
unnecessary. Codex noticed the omitted flag check here.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: 6f0f35a87c8797 ("xfs_healer: enable repairing filesystems") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 2 Jun 2026 04:58:19 +0000 (21:58 -0700)]
xfs_healer: fix error reporting
Codex complains about incorrect error reporting logic here -- in the
first place we totally fail to pick up errno; in the second, we do, but
with inverted sign. Fix both.
Cc: linux-xfs@vger.kernel.org # v7.0.0 Fixes: b9b03770197d19 ("xfs_healer: create daemon to listen for health events") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Tue, 19 May 2026 04:18:05 +0000 (21:18 -0700)]
xfs_healer: fix missing HAVE_LISTMOUNT flag and stubs
xfs/666 regressed with a broken xfs_healer_start that can't actually
walk the mount namespace with listmount and statmount. The new stubs
are wrapped with HAVE_LISTMOUNT, but this cflag is not added in healer/
Makefile even if the build system has HAVE_LISTMOUNT set.
Also fix the stubs to return error correctly -- the wrappers follow C
library behavior.
Fixes: b30356f25335eb ("libfrog: add fallback stubs for libfrog_statmount and fstatmount") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
libfrog: add fallback stubs for libfrog_statmount and fstatmount
Add stubs for libfrog_statmount and fstatmount to enable compilation of
xfs_healer on systems that lack listmount support. Without these stubs,
statmount.c is not compiled, causing compilation errors due to missing
definitions. The stubs allow xfs_healer to fall back to walking the mount
table in userspace.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Add definitions for STATMOUNT_MNT_BASIC and STATMOUNT_MNT_POINT to support
compilation of xfs_healer on systems with older kernel headers that predate
the statmount syscall (introduced in v6.8).
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
configure: always check for statmount supported_mask
On systems with kernel headers older than v6.8 that preceed the addition
of the statmount syscall, have_listmount will be set to false and thus
checking of the statmount supported_mask is being skipped since the
check is currently conditional to listmount support.
This causes compilation failures since need_internal_statmount will not
be set, and thus struct statmount will not be available to xfs_healer.
Fix this by always checking for statmount supported_mask support even
when listmount is not available.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Darrick J. Wong [Thu, 7 May 2026 22:11:27 +0000 (15:11 -0700)]
platform_defs.h: fix __counted_by_ptr annotation
The kernel userspace headers for Linux 7.0 provide the __counted_by_ptr
macro, so we shouldn't define it separately on those platforms:
In file included from radix-tree.c:11:
../include/platform_defs.h:334:9: error: "__counted_by_ptr" redefined [-Werror]
334 | #define __counted_by_ptr(member)
| ^~~~~~~~~~~~~~~~
In file included from /usr/include/linux/posix_types.h:5,
from /usr/include/linux/types.h:9,
from /usr/include/linux/sched/types.h:5,
from /usr/include/x86_64-linux-gnu/bits/sched.h:63,
from /usr/include/sched.h:43,
from /usr/include/pthread.h:22,
from ../include/platform_defs.h:19:
/usr/include/linux/stddef.h:73:9: note: this is the location of the previous definition
73 | #define __counted_by_ptr(m)
| ^~~~~~~~~~~~~~~~
xfsprogs: update release.sh with fixes from xfsdump
While updating release.sh in xfsdump repository (copy-pasting this
release.sh into xfsdump repo), I added a few minor fixes to the
release.sh. These are those fixes (basically diff -u without
s/xfsprogs/xfsdump).
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Mon, 4 May 2026 17:08:52 +0000 (10:08 -0700)]
xfs_scrub: drop the warning about mixed bidirectional codepoints in names
Gedalya complained about receiving warnings about mixed bidirectional
codepoints in a filename:
"First, well-known file name extensions are not internationalized. While
the file name can be in non-latin letters, the extension will be in
latin. Hence you would expect to see file names such as עברית.pdf ."
Gedalya goes on to point out that file names can be created from (say)
the title of an article, which might itself mix RTL and LTR characters.
Both uses are totally fair, but regrettably unfamiliar to 2018-era me.
Unicode TR 36 even weasel-words its own recommendation: "As much as
possible, avoid mixing right-to-left and left-to-right characters in a
single name." Maybe I should have paid more attention to weasel
wording in specifications. :P
Let's fix this by removing the warning altogether.
Darrick J. Wong [Thu, 30 Apr 2026 15:54:06 +0000 (08:54 -0700)]
xfs_scrub_all: fix deadlock if lsblk produces a lot of output
Patrick Fischer reported a deadlock in find_mounts() that is the result
of lsblk producing so much output that it fills the pipe buffer. When
this happens, lsblk blocks on write()ing the pipe, at which point
waiting for lsblk to exit will also block forever.
Now that we can be reasonably assured that everyone has Python 3.5
(because RHEL6 is long dead), we can replace this whole mess with a call
to subprocess.run that captures the output. The json library can
convert a byte array directly to a python dict, which means we don't
need to concatenate iterated lines or any of that stuff anymore.
Reported-by: patrick.fischer@siedl.net Link: https://lore.kernel.org/linux-xfs/323580211.1220195.1777554001363.JavaMail.zimbra@siedl.net/ Cc: <linux-xfs@vger.kernel.org> # v4.15.0 Fixes: f1dca11cad1308 ("xfs_scrub: create a script to scrub all xfs filesystems") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@kernel.org>
Factor out wrapper xfs_attr3_leaf_init function, which exported for
external use.
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Long Li <leo.lilong@huawei.com> Signed-off-by: Carlos Maiolino <cem@kernel.org> Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
Factor out wrapper xfs_attr3_node_entry_remove function, which
exported for external use.
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Long Li <leo.lilong@huawei.com> Signed-off-by: Carlos Maiolino <cem@kernel.org> Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
Add the `__counted_by_ptr` attribute to the `buffer` field of `struct
xfs_attr_list_context`. This field is used to point to a buffer of
size `bufsize`.
The `buffer` field is assigned in:
1. `xfs_ioc_attr_list` in `fs/xfs/xfs_handle.c`
2. `xfs_xattr_list` in `fs/xfs/xfs_xattr.c`
3. `xfs_getparents` in `fs/xfs/xfs_handle.c` (implicitly initialized to NULL)
In `xfs_ioc_attr_list`, `buffer` was assigned before `bufsize`. Reorder
them to ensure `bufsize` is set before `buffer` is assigned, although
no access happens between them.
In `xfs_xattr_list`, `buffer` was assigned before `bufsize`. Reorder
them to ensure `bufsize` is set before `buffer` is assigned.
In `xfs_getparents`, `buffer` is NULL (from zero initialization) and
remains NULL. `bufsize` is set to a non-zero value, but since `buffer`
is NULL, no access occurs.
In all cases, the pointer `buffer` is not accessed before `bufsize` is set.
This patch was generated by CodeMender and reviewed by Bill Wendling.
Tested by running xfstests.
Signed-off-by: Bill Wendling <morbo@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org> Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
Darrick J. Wong [Mon, 13 Apr 2026 14:57:00 +0000 (07:57 -0700)]
xfs_scrub: warn about unicode variation selectors in names
ArsTechnica recently wrote about a GitHub supply chain attack wherein
non-rendering unicode sequences were embedded in javascript files to
hide payloads that could be decrypted trivially later. While these are
unlikely to appear in file and attribute names, we should warn about
this sort of steganography.
Ravi Singh [Tue, 14 Apr 2026 07:19:21 +0000 (15:19 +0800)]
xfs_quota: display default limits for users with zero usage
When the kernel returns default quota limits for IDs without a dquot
on disk, xfs_quota suppresses the output because it only checks
usage counters (d_bcount, d_icount, d_rtbcount). If all counters
are zero the line is skipped even though non-zero limits apply.
Also check the soft/hard limit fields so that quota output is
displayed whenever limits are configured, even if usage is zero.
This is the userspace companion to the kernel commit:
"xfs: return default quota limits for IDs without a dquot"
Signed-off-by: Ravi Singh <ravising@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
projects / xfsprogs-dev.git / log