<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/xfs, branch v6.18.36</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:44:06+00:00</updated>
<entry>
<title>xfs: fix rtgroup cleanup in CoW fork repair</title>
<updated>2026-06-19T11:44:06+00:00</updated>
<author>
<name>Yingjie Gao</name>
<email>gaoyingjie@uniontech.com</email>
</author>
<published>2026-05-27T04:31:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fcfdff42e841d246397c3756d4218c66c2b3b263'/>
<id>urn:sha1:fcfdff42e841d246397c3756d4218c66c2b3b263</id>
<content type='text'>
commit c3e073894379532c00cca7ba5762e18fafe29da8 upstream.

xrep_cow_find_bad_rt() initializes scrub rtgroup state before the
force-rebuild path calls xrep_cow_mark_file_range(). If that call
fails, the code jumps directly to out_rtg, which skips the scrub
rtgroup cleanup and only drops the local rtgroup reference.

Remove the unnecessary jump so the function falls through to out_sr,
ensuring the realtime cursors, lock state, and sr-&gt;rtg reference are
released before returning.

Fixes: fd97fe111208 ("xfs: fix CoW forks for realtime files")
Cc: &lt;stable@vger.kernel.org&gt; # v6.14
Signed-off-by: Yingjie Gao &lt;gaoyingjie@uniontech.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix error returns in CoW fork repair</title>
<updated>2026-06-19T11:44:06+00:00</updated>
<author>
<name>Yingjie Gao</name>
<email>gaoyingjie@uniontech.com</email>
</author>
<published>2026-05-27T04:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d84ed2f9718efcfe7afae4821cefa1bcdccea970'/>
<id>urn:sha1:d84ed2f9718efcfe7afae4821cefa1bcdccea970</id>
<content type='text'>
commit fcf4faba9f986b3bb528da11913c9ec5d6e8f689 upstream.

xrep_cow_find_bad() returns success after the cleanup labels even if
AG setup, btree queries, or bitmap updates failed. This can make
repair continue with an incomplete bad-file-offset bitmap instead of
stopping at the original error.

The force-rebuild path has a related cleanup problem. If
xrep_cow_mark_file_range() fails, the function returns directly and
skips the scrub AG context and perag cleanup.

Let the force-rebuild path fall through to the existing cleanup code
and return the saved error after cleanup.

Fixes: dbbdbd008632 ("xfs: repair problems in CoW forks")
Cc: &lt;stable@vger.kernel.org&gt; # v6.8
Signed-off-by: Yingjie Gao &lt;gaoyingjie@uniontech.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix memory leak on error in xfs_alloc_zone_info()</title>
<updated>2026-05-23T11:07:18+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=690b7ca1f9b343b505ff6d02226d40d1911a9d16'/>
<id>urn:sha1:690b7ca1f9b343b505ff6d02226d40d1911a9d16</id>
<content type='text'>
commit 592975da8c3ca87b043077e6eafa37665eae7936 upstream.

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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix a resource leak in xfs_alloc_buftarg()</title>
<updated>2026-05-07T04:11:48+00:00</updated>
<author>
<name>Haoxiang Li</name>
<email>lihaoxiang@isrc.iscas.ac.cn</email>
</author>
<published>2026-04-01T04:02:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c293a1e1ef0f838772d20ae8afae4cbd87cd3f9'/>
<id>urn:sha1:5c293a1e1ef0f838772d20ae8afae4cbd87cd3f9</id>
<content type='text'>
commit 29a7b2614357393b176ef06ba5bc3ff5afc8df69 upstream.

In the error path, call fs_put_dax() to drop the DAX
device reference.

Fixes: 6f643c57d57c ("xfs: implement -&gt;notify_failure() for XFS")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li &lt;lihaoxiang@isrc.iscas.ac.cn&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: start gc on zonegc_low_space attribute updates</title>
<updated>2026-05-07T04:11:48+00:00</updated>
<author>
<name>Hans Holmberg</name>
<email>hans.holmberg@wdc.com</email>
</author>
<published>2026-03-25T12:43:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fe570daa51930b066a4ecc2086df308e88a95d0e'/>
<id>urn:sha1:fe570daa51930b066a4ecc2086df308e88a95d0e</id>
<content type='text'>
commit 181ea4e2de422aa0a66f355bd59bccccdd169826 upstream.

Start gc if the agressiveness of zone garbage collection is changed
by the user (if the file system is not read only).

Without this change, the new setting will not be taken into account
until the gc thread is woken up by e.g. a write.

Cc: stable@vger.kernel.org # v6.15
Fixes: 845abeb1f06a8a ("xfs: add tunable threshold parameter for triggering zone GC")
Signed-off-by: Hans Holmberg &lt;hans.holmberg@wdc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: remove file_path tracepoint data</title>
<updated>2026-04-02T11:23:26+00:00</updated>
<author>
<name>Darrick J. Wong</name>
<email>djwong@kernel.org</email>
</author>
<published>2026-03-23T21:04:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c2db09b904312b8938aef693e6fea0060e30066'/>
<id>urn:sha1:2c2db09b904312b8938aef693e6fea0060e30066</id>
<content type='text'>
commit e31c53a8060e134111ed095783fee0aa0c43b080 upstream.

The xfile/xmbuf shmem file descriptions are no longer as detailed as
they were when online fsck was first merged, because moving to static
strings in commit 60382993a2e180 ("xfs: get rid of the
xchk_xfile_*_descr calls") removed a memory allocation and hence a
source of failure.

However this makes encoding the description in the tracepoints sort of a
waste of memory.  David Laight also points out that file_path doesn't
zero the whole buffer which causes exposure of stale trace bytes, and
Steven Rostedt wonders why we're not using a dynamic array for the file
path.

I don't think this is worth fixing, so let's just rip it out.

Cc: rostedt@goodmis.org
Cc: david.laight.linux@gmail.com
Link: https://lore.kernel.org/linux-xfs/20260323172204.work.979-kees@kernel.org/
Cc: stable@vger.kernel.org # v6.11
Fixes: 19ebc8f84ea12e ("xfs: fix file_path handling in tracepoints")
Signed-off-by: Darrick J. Wong &lt;djwong@kernel.org&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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: don't irele after failing to iget in xfs_attri_recover_work</title>
<updated>2026-04-02T11:23:26+00:00</updated>
<author>
<name>Darrick J. Wong</name>
<email>djwong@kernel.org</email>
</author>
<published>2026-03-23T21:01:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1a5df1038f0b3c560d204270373621a4e622808'/>
<id>urn:sha1:a1a5df1038f0b3c560d204270373621a4e622808</id>
<content type='text'>
commit 70685c291ef82269180758130394ecdc4496b52c upstream.

xlog_recovery_iget* never set @ip to a valid pointer if they return
an error, so this irele will walk off a dangling pointer.  Fix that.

Cc: stable@vger.kernel.org # v6.10
Fixes: ae673f534a3097 ("xfs: record inode generation in xattr update log intent items")
Signed-off-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Reviewed-by: Long Li &lt;leo.lilong@huawei.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Carlos Maiolino &lt;cmaiolino@redhat.com&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix ri_total validation in xlog_recover_attri_commit_pass2</title>
<updated>2026-04-02T11:23:25+00:00</updated>
<author>
<name>Long Li</name>
<email>leo.lilong@huawei.com</email>
</author>
<published>2026-03-20T02:11:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=68d80f35ea62379deb419d0f8881aa0ae919be1c'/>
<id>urn:sha1:68d80f35ea62379deb419d0f8881aa0ae919be1c</id>
<content type='text'>
commit d72f2084e30966097c8eae762e31986a33c3c0ae upstream.

The ri_total checks for SET/REPLACE operations are hardcoded to 3,
but xfs_attri_item_size() only emits a value iovec when value_len &gt; 0,
so ri_total is 2 when value_len == 0.

For PPTR_SET/PPTR_REMOVE/PPTR_REPLACE, value_len is validated by
xfs_attri_validate() to be exactly sizeof(struct xfs_parent_rec) and
is never zero, so their hardcoded checks remain correct.

This problem may cause log recovery failures. The following script can be
used to reproduce the problem:

 #!/bin/bash
 mkfs.xfs -f /dev/sda
 mount /dev/sda /mnt/test/
 touch /mnt/test/file
 for i in {1..200}; do
         attr -s "user.attr_$i" -V "value_$i" /mnt/test/file &gt; /dev/null
 done
 echo 1 &gt; /sys/fs/xfs/debug/larp
 echo 1 &gt; /sys/fs/xfs/sda/errortag/larp
 attr -s "user.zero" -V "" /mnt/test/file
 echo 0 &gt; /sys/fs/xfs/sda/errortag/larp
 umount /mnt/test
 mount /dev/sda /mnt/test/  # mount failed

Fix this by deriving the expected count dynamically as "2 + !!value_len"
for SET/REPLACE operations.

Cc: stable@vger.kernel.org # v6.9
Fixes: ad206ae50eca ("xfs: check opcode and iovec count match in xlog_recover_attri_commit_pass2")
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Long Li &lt;leo.lilong@huawei.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: scrub: unlock dquot before early return in quota scrub</title>
<updated>2026-04-02T11:23:25+00:00</updated>
<author>
<name>hongao</name>
<email>hongao@uniontech.com</email>
</author>
<published>2026-03-12T12:10:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b0c3414b308e6822cda90bf99f7eac94d4cca2b'/>
<id>urn:sha1:3b0c3414b308e6822cda90bf99f7eac94d4cca2b</id>
<content type='text'>
commit 268378b6ad20569af0d1957992de1c8b16c6e900 upstream.

xchk_quota_item can return early after calling xchk_fblock_process_error.
When that helper returns false, the function returned immediately without
dropping dq-&gt;q_qlock, which can leave the dquot lock held and risk lock
leaks or deadlocks in later quota operations.

Fix this by unlocking dq-&gt;q_qlock before the early return.

Signed-off-by: hongao &lt;hongao@uniontech.com&gt;
Fixes: 7d1f0e167a067e ("xfs: check the ondisk space mapping behind a dquot")
Cc: &lt;stable@vger.kernel.org&gt; # v6.8
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: avoid dereferencing log items after push callbacks</title>
<updated>2026-04-02T11:23:25+00:00</updated>
<author>
<name>Yuto Ohnuki</name>
<email>ytohnuki@amazon.com</email>
</author>
<published>2026-03-10T18:38:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95fb5d643cc70959baa54cd17f52f80ffc3295e7'/>
<id>urn:sha1:95fb5d643cc70959baa54cd17f52f80ffc3295e7</id>
<content type='text'>
commit 79ef34ec0554ec04bdbafafbc9836423734e1bd6 upstream.

After xfsaild_push_item() calls iop_push(), the log item may have been
freed if the AIL lock was dropped during the push. Background inode
reclaim or the dquot shrinker can free the log item while the AIL lock
is not held, and the tracepoints in the switch statement dereference
the log item after iop_push() returns.

Fix this by capturing the log item type, flags, and LSN before calling
xfsaild_push_item(), and introducing a new xfs_ail_push_class trace
event class that takes these pre-captured values and the ailp pointer
instead of the log item pointer.

Reported-by: syzbot+652af2b3c5569c4ab63c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=652af2b3c5569c4ab63c
Fixes: 90c60e164012 ("xfs: xfs_iflush() is no longer necessary")
Cc: stable@vger.kernel.org # v5.9
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;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
