<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/fs/xfs/xfs_rtalloc.c, branch jd/bump-compilers</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/fs/xfs/xfs_rtalloc.c?h=jd%2Fbump-compilers</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/fs/xfs/xfs_rtalloc.c?h=jd%2Fbump-compilers'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2024-08-27T13:02:14Z</updated>
<entry>
<title>xfs: reset rootdir extent size hint after growfsrt</title>
<updated>2024-08-27T13:02:14Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>djwong@kernel.org</email>
</author>
<published>2024-08-23T00:01:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=a24cae8fc1f13f6f6929351309f248fd2e9351ce'/>
<id>urn:sha1:a24cae8fc1f13f6f6929351309f248fd2e9351ce</id>
<content type='text'>
If growfsrt is run on a filesystem that doesn't have a rt volume, it's
possible to change the rt extent size.  If the root directory was
previously set up with an inherited extent size hint and rtinherit, it's
possible that the hint is no longer a multiple of the rt extent size.
Although the verifiers don't complain about this, xfs_repair will, so if
we detect this situation, log the root directory to clean it up.  This
is still racy, but it's better than nothing.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: take m_growlock when running growfsrt</title>
<updated>2024-08-27T13:02:14Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>djwong@kernel.org</email>
</author>
<published>2024-08-23T00:00:51Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=16e1fbdce9c8d084863fd63cdaff8fb2a54e2f88'/>
<id>urn:sha1:16e1fbdce9c8d084863fd63cdaff8fb2a54e2f88</id>
<content type='text'>
Take the grow lock when we're expanding the realtime volume, like we do
for the other growfs calls.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix rtalloc rotoring when delalloc is in use</title>
<updated>2024-07-09T03:38:28Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-07-08T12:02:57Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=2bf6e353542d233486195953dc9c346331f82dcb'/>
<id>urn:sha1:2bf6e353542d233486195953dc9c346331f82dcb</id>
<content type='text'>
If we're trying to allocate real space for a delalloc reservation at
offset 0, we should use the rotor to spread files across the rt volume.

Switch the rtalloc to use the XFS_ALLOC_INITIAL_USER_DATA flag that
is set for any write at startoff to make it match the behavior for
the main data device.

Based on a patch from Darrick J. Wong.

Fixes: 6a94b1acda7e ("xfs: reinstate delalloc for RT inodes (if sb_rextsize == 1)")
Reported-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: simplify iext overflow checking and upgrade</title>
<updated>2024-05-03T05:50:06Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-05-02T07:33:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=25576c5420e61dea4c2b52942460f2221b8e46e8'/>
<id>urn:sha1:25576c5420e61dea4c2b52942460f2221b8e46e8</id>
<content type='text'>
Currently the calls to xfs_iext_count_may_overflow and
xfs_iext_count_upgrade are always paired.  Merge them into a single
function to simplify the callers and the actual check and upgrade
logic itself.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Reviewed-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix error returns from xfs_bmapi_write</title>
<updated>2024-04-30T04:15:18Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-04-29T06:15:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=6773da870ab89123d1b513da63ed59e32a29cb77'/>
<id>urn:sha1:6773da870ab89123d1b513da63ed59e32a29cb77</id>
<content type='text'>
xfs_bmapi_write can return 0 without actually returning a mapping in
mval in two different cases:

 1) when there is absolutely no space available to do an allocation
 2) when converting delalloc space, and the allocation is so small
    that it only covers parts of the delalloc extent before the
    range requested by the caller

Callers at best can handle one of these cases, but in many cases can't
cope with either one.  Switch xfs_bmapi_write to always return a
mapping or return an error code instead.  For case 1) above ENOSPC is
the obvious choice which is very much what the callers expect anyway.
For case 2) there is no really good error code, so pick a funky one
from the SysV streams portfolio.

This fixes the reproducer here:

    https://lore.kernel.org/linux-xfs/CAEJPjCvT3Uag-pMTYuigEjWZHn1sGMZ0GCjVVCv29tNHK76Cgg@mail.gmail.com0/

which uses reserved blocks to create file systems that are gravely
out of space and thus cause at least xfs_file_alloc_space to hang
and trigger the lack of ENOSPC handling in xfs_dquot_disk_alloc.

Note that this patch does not actually make any caller but
xfs_alloc_file_space deal intelligently with case 2) above.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reported-by: 刘通 &lt;lyutoon@gmail.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: reinstate delalloc for RT inodes (if sb_rextsize == 1)</title>
<updated>2024-04-22T12:30:50Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-04-22T11:20:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=6a94b1acda7e7262418e23f906c12a2b08b69d12'/>
<id>urn:sha1:6a94b1acda7e7262418e23f906c12a2b08b69d12</id>
<content type='text'>
Commit aff3a9edb708 ("xfs: Use preallocation for inodes with extsz
hints") disabled delayed allocation for all inodes with extent size
hints due a data exposure problem.  It turns out we fixed this data
exposure problem since by always creating unwritten extents for
delalloc conversions due to more data exposure problems, but the
writeback path doesn't actually support extent size hints when
converting delalloc these days, which probably isn't a problem given
that people using the hints know what they get.

However due to the way how xfs_get_extsz_hint is implemented, it
always claims an extent size hint for RT inodes even if the RT
extent size is a single FSB.  Due to that the above commit effectively
disabled delalloc support for RT inodes.

Switch xfs_get_extsz_hint to return 0 for this case and work around
that in a few places to reinstate delalloc support for RT inodes on
file systems with an sb_rextsize of 1.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: refactor realtime inode locking</title>
<updated>2024-04-22T12:30:47Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2024-04-22T11:20:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=b7e23c0e2e3b1c520a3370f058870b914071a470'/>
<id>urn:sha1:b7e23c0e2e3b1c520a3370f058870b914071a470</id>
<content type='text'>
Create helper functions to deal with locking realtime metadata inodes.
This enables us to maintain correct locking order once we start adding
the realtime rmap and refcount btree inodes.

Signed-off-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: report realtime metadata corruption errors to the health system</title>
<updated>2024-02-22T20:32:44Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>djwong@kernel.org</email>
</author>
<published>2024-02-22T20:32:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=8368ad49aaf771a6283840140149440b958b20fb'/>
<id>urn:sha1:8368ad49aaf771a6283840140149440b958b20fb</id>
<content type='text'>
Whenever we encounter corrupt realtime metadat blocks, we should report
that to the health monitoring system for later reporting.

Signed-off-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>xfs: Replace xfs_isilocked with xfs_assert_ilocked</title>
<updated>2024-02-19T15:49:33Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2024-02-19T15:41:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=3fed24fffc76dd1a8105db558e98bc8355d60379'/>
<id>urn:sha1:3fed24fffc76dd1a8105db558e98bc8355d60379</id>
<content type='text'>
To use the new rwsem_assert_held()/rwsem_assert_held_write(), we can't
use the existing ASSERT macro.  Add a new xfs_assert_ilocked() and
convert all the callers.

Fix an apparent bug in xfs_isilocked(): If the caller specifies
XFS_IOLOCK_EXCL | XFS_ILOCK_EXCL, xfs_assert_ilocked() will check both
the IOLOCK and the ILOCK are held for write.  xfs_isilocked() only
checked that the ILOCK was held for write.

xfs_assert_ilocked() is always on, even if DEBUG or XFS_WARN aren't
defined.  It's a cheap check, so I don't think it's worth defining
it away.

Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Reviewed-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Signed-off-by: "Matthew Wilcox (Oracle)" &lt;willy@infradead.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfs: convert remaining kmem_free() to kfree()</title>
<updated>2024-02-13T12:37:34Z</updated>
<author>
<name>Dave Chinner</name>
<email>dchinner@redhat.com</email>
</author>
<published>2024-01-15T22:59:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=d4c75a1b40cd036a84d98e2711db9cf30eaaaf5f'/>
<id>urn:sha1:d4c75a1b40cd036a84d98e2711db9cf30eaaaf5f</id>
<content type='text'>
The remaining callers of kmem_free() are freeing heap memory, so
we can convert them directly to kfree() and get rid of kmem_free()
altogether.

This conversion was done with:

$ for f in `git grep -l kmem_free fs/xfs`; do
&gt; sed -i s/kmem_free/kfree/ $f
&gt; done
$

Signed-off-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Chandan Babu R &lt;chandanbabu@kernel.org&gt;
</content>
</entry>
</feed>
