<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/xfs, branch v7.1-rc5</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.1-rc5</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.1-rc5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-21T11:43:58+00:00</updated>
<entry>
<title>xfs: fix a buffer lookup against removal race</title>
<updated>2026-05-21T11:43:58+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2026-05-18T06:02:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c69439a891ccb37ede5d68539636337c6bd92fab'/>
<id>urn:sha1:c69439a891ccb37ede5d68539636337c6bd92fab</id>
<content type='text'>
When a buffer is freed either by LRU eviction or because it is unset,
the lockref is marked as dead instantly, which prevents the buffer from
being used after finding it in the buffer hash in xfs_buf_lookup and
xfs_buf_find_insert.  But the latter will then not add the new buffer to
the hash because it already found an existing buffer.

Fix this using in two places:  Remove the buffer from the hash before
marking the lockref dead so that that no buffer with a dead lockref can
be found in the hash, but if we find one in xfs_buf_find_insert due to
store reordering, handle this case correctly instead of returning an
unhashed buffer.

Fixes: 67fe4303972e ("xfs: don't keep a reference for buffers on the LRU")
Reported-by: Andrey Albershteyn &lt;aalbersh@redhat.com&gt;
Reported-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Andrey Albershteyn &lt;aalbersh@kernel.org&gt;
Reviewed-by: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: Fix typo in comment</title>
<updated>2026-05-11T10:58:38+00:00</updated>
<author>
<name>Md Shofiqul Islam</name>
<email>shofiqtest@gmail.com</email>
</author>
<published>2026-05-06T16:36:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=509fdeb3326be0db055e88d0f689a3888f147f90'/>
<id>urn:sha1:509fdeb3326be0db055e88d0f689a3888f147f90</id>
<content type='text'>
Fix spelling mistake in comment:
 - occured -&gt; occurred

Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Md Shofiqul Islam &lt;shofiqtest@gmail.com&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix the "limiting open zones" message</title>
<updated>2026-05-11T10:51:57+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2026-05-07T05:24:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5082d8835070fe63f3c61fe574cbb5319bd94575'/>
<id>urn:sha1:5082d8835070fe63f3c61fe574cbb5319bd94575</id>
<content type='text'>
The xfs logging macros include a newline, remove the \n, which adds an
extra one.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Reviewed-by: Andrey Albershteyn &lt;aalbersh@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: flush delalloc blocks on ENOSPC in xfs_trans_alloc_icreate</title>
<updated>2026-04-27T09:31:15+00:00</updated>
<author>
<name>Ravi Singh</name>
<email>ravising@redhat.com</email>
</author>
<published>2026-04-22T07:39:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=87e63466c9fc30c3d95b8741c3df1f1ff01d7f23'/>
<id>urn:sha1:87e63466c9fc30c3d95b8741c3df1f1ff01d7f23</id>
<content type='text'>
xfs_trans_alloc_icreate() can fail with ENOSPC when delalloc
reservations have consumed most of the available block count
(fdblocks).  xfs_trans_alloc() already retries internally with
xfs_blockgc_flush_all(), but that only trims post-EOF speculative
preallocation and may not free enough space for the transaction
reservation.

Add a retry with xfs_flush_inodes() when xfs_trans_alloc() returns
ENOSPC.  This forces writeback of all dirty inodes via
sync_inodes_sb(), converting delalloc reservations to real
allocations and freeing the over-reserved portion back to fdblocks.

This fixes all callers of xfs_trans_alloc_icreate() and removes
the existing caller-level retry from xfs_create(), which is now
handled centrally.

Signed-off-by: Ravi Singh &lt;ravising@redhat.com&gt;
Reviewed-by: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: check da node block pad field during scrub</title>
<updated>2026-04-27T08:36:36+00:00</updated>
<author>
<name>Yuto Ohnuki</name>
<email>ytohnuki@amazon.com</email>
</author>
<published>2026-04-10T17:06:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fca20fcb76a20655daf18738f4a88c638a6bb64c'/>
<id>urn:sha1:fca20fcb76a20655daf18738f4a88c638a6bb64c</id>
<content type='text'>
The da node block header (xfs_da3_node_hdr) contains a __pad32 field
that should always be zero. Add a check for this during directory and
attribute btree scrubbing.

Since old kernels may have written non-zero padding without issues, flag
this as an optimization opportunity (preen) rather than corruption.

Signed-off-by: Yuto Ohnuki &lt;ytohnuki@amazon.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix memory leak for data allocated by xfs_zone_gc_data_alloc()</title>
<updated>2026-04-27T08:36:36+00:00</updated>
<author>
<name>Wilfred Mallawa</name>
<email>wilfred.mallawa@wdc.com</email>
</author>
<published>2026-04-17T02:16:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af47a4be6a90c8bfc874f9994ac9c15813b9718b'/>
<id>urn:sha1:af47a4be6a90c8bfc874f9994ac9c15813b9718b</id>
<content type='text'>
In xfs_zone_gc_mount(), on error, a struct xfs_zone_gc_data allocated
with xfs_zone_gc_data_alloc() is freed with kfree(), however, this
doesn't free the underlying folios or the rmap_irecs.

Use xfs_zone_gc_data_free() to correctly free this memory.

Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection")
Cc: stable@vger.kernel.org # v6.15
Signed-off-by: Wilfred Mallawa &lt;wilfred.mallawa@wdc.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix memory leak on error in xfs_alloc_zone_info()</title>
<updated>2026-04-27T08:36:36+00:00</updated>
<author>
<name>Wilfred Mallawa</name>
<email>wilfred.mallawa@wdc.com</email>
</author>
<published>2026-04-14T23:45:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=592975da8c3ca87b043077e6eafa37665eae7936'/>
<id>urn:sha1:592975da8c3ca87b043077e6eafa37665eae7936</id>
<content type='text'>
Currently, the 0th index of the zi_used_bucket_bitmap array is not freed
on error due to the pre-decrement then evaluate semantic of the while
loop used in xfs_alloc_zone_info(). Fix it by allowing for the i == 0
case to be covered.

Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection")
Cc: stable@vger.kernel.org # v6.15
Reviewed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Signed-off-by: Wilfred Mallawa &lt;wilfred.mallawa@wdc.com&gt;
Reviewed-by: Hans Holmberg &lt;hans.holmberg@wdc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: check directory data block header padding in scrub</title>
<updated>2026-04-27T08:36:36+00:00</updated>
<author>
<name>Yuto Ohnuki</name>
<email>ytohnuki@amazon.com</email>
</author>
<published>2026-04-11T14:24:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=939919ccddfcc379bb82b1f90f732d9a5cb32cc8'/>
<id>urn:sha1:939919ccddfcc379bb82b1f90f732d9a5cb32cc8</id>
<content type='text'>
Add the missing scrub check for the pad field in directory data block
headers. Old kernels may have written non-zero padding without issue,
and the write path now self-heals stale padding on modification. Flag
non-zero padding as an optimization opportunity (preen) rather than
corruption.

Add xchk_fblock_set_preen helper for reporting file fork block issues
that could be optimized. The trace event xchk_fblock_preen already
exists.

Signed-off-by: Yuto Ohnuki &lt;ytohnuki@amazon.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: zero directory data block padding on write verification</title>
<updated>2026-04-27T08:36:36+00:00</updated>
<author>
<name>Yuto Ohnuki</name>
<email>ytohnuki@amazon.com</email>
</author>
<published>2026-04-11T14:24:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8fbb1877dfa5e26bda1baf8cc6abd3f805098486'/>
<id>urn:sha1:8fbb1877dfa5e26bda1baf8cc6abd3f805098486</id>
<content type='text'>
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 &lt;dgc@kernel.org&gt;
Signed-off-by: Yuto Ohnuki &lt;ytohnuki@amazon.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: zero entire directory data block header region at init</title>
<updated>2026-04-27T08:36:36+00:00</updated>
<author>
<name>Yuto Ohnuki</name>
<email>ytohnuki@amazon.com</email>
</author>
<published>2026-04-11T14:24:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=00dd8d7ec5253c6273023a0fd6dc08683e0bdfef'/>
<id>urn:sha1:00dd8d7ec5253c6273023a0fd6dc08683e0bdfef</id>
<content type='text'>
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-&gt;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 &lt;dgc@kernel.org&gt;
Signed-off-by: Yuto Ohnuki &lt;ytohnuki@amazon.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
</content>
</entry>
</feed>
