linux-stable.git/fs, branch v5.4.217

xfs: remove unused variable 'done'

2022-10-07T07:16:57+00:00

commit b3531f5fc16d4df2b12567bce48cd9f3ab5f9131 upstream.

fs/xfs/xfs_inode.c: In function 'xfs_itruncate_extents_flags':
fs/xfs/xfs_inode.c:1523:8: warning: unused variable 'done' [-Wunused-variable]

commit 4bbb04abb4ee ("xfs: truncate should remove
all blocks, not just to the end of the page cache")
left behind this, so remove it.

Fixes: 4bbb04abb4ee ("xfs: truncate should remove all blocks, not just to the end of the page cache")
Reported-by: Hulk Robot 
Reported-by: Stephen Rothwell 
Signed-off-by: YueHaibing 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: fix uninitialized variable in xfs_attr3_leaf_inactive

2022-10-07T07:16:57+00:00

commit 54027a49938bbee1af62fad191139b14d4ee5cd2 upstream.

Dan Carpenter pointed out that error is uninitialized.  While there
never should be an attr leaf block with zero entries, let's not leave
that logic bomb there.

Fixes: 0bb9d159bd01 ("xfs: streamline xfs_attr3_leaf_inactive")
Reported-by: Dan Carpenter 
Signed-off-by: Darrick J. Wong 
Reviewed-by: Allison Collins 
Reviewed-by: Eric Sandeen 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: streamline xfs_attr3_leaf_inactive

2022-10-07T07:16:57+00:00

commit 0bb9d159bd018b271e783d3b2d3bc82fa0727321 upstream.

Now that we know we don't have to take a transaction to stale the incore
buffers for a remote value, get rid of the unnecessary memory allocation
in the leaf walker and call the rmt_stale function directly.  Flatten
the loop while we're at it.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: move incore structures out of xfs_da_format.h

2022-10-07T07:16:57+00:00

commit a39f089a25e75c3d17b955d8eb8bc781f23364f3 upstream.

Move the abstract in-memory version of various btree block headers
out of xfs_da_format.h as they aren't on-disk formats.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: fix memory corruption during remote attr value buffer invalidation

2022-10-07T07:16:57+00:00

commit e8db2aafcedb7d88320ab83f1000f1606b26d4d7 upstream.

[Replaced XFS_IS_CORRUPT() calls with ASSERT() for 5.4.y backport]

While running generic/103, I observed what looks like memory corruption
and (with slub debugging turned on) a slub redzone warning on i386 when
inactivating an inode with a 64k remote attr value.

On a v5 filesystem, maximally sized remote attr values require one block
more than 64k worth of space to hold both the remote attribute value
header (64 bytes).  On a 4k block filesystem this results in a 68k
buffer; on a 64k block filesystem, this would be a 128k buffer.  Note
that even though we'll never use more than 65,600 bytes of this buffer,
XFS_MAX_BLOCKSIZE is 64k.

This is a problem because the definition of struct xfs_buf_log_format
allows for XFS_MAX_BLOCKSIZE worth of dirty bitmap (64k).  On i386 when we
invalidate a remote attribute, xfs_trans_binval zeroes all 68k worth of
the dirty map, writing right off the end of the log item and corrupting
memory.  We've gotten away with this on x86_64 for years because the
compiler inserts a u32 padding on the end of struct xfs_buf_log_format.

Fortunately for us, remote attribute values are written to disk with
xfs_bwrite(), which is to say that they are not logged.  Fix the problem
by removing all places where we could end up creating a buffer log item
for a remote attribute value and leave a note explaining why.  Next,
replace the open-coded buffer invalidation with a call to the helper we
created in the previous patch that does better checking for bad metadata
before marking the buffer stale.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: refactor remote attr value buffer invalidation

2022-10-07T07:16:56+00:00

commit 8edbb26b06023de31ad7d4c9b984d99f66577929 upstream.

[Replaced XFS_IS_CORRUPT() calls with ASSERT() for 5.4.y backport]

Hoist the code that invalidates remote extended attribute value buffers
into a separate helper function.  This prepares us for a memory
corruption fix in the next patch.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: fix IOCB_NOWAIT handling in xfs_file_dio_aio_read

2022-10-07T07:16:56+00:00

commit 7b53b868a1812a9a6ab5e69249394bd37f29ce2c upstream.

Direct I/O reads can also be used with RWF_NOWAIT & co.  Fix the inode
locking in xfs_file_dio_aio_read to take IOCB_NOWAIT into account.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Carlos Maiolino 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: fix s_maxbytes computation on 32-bit kernels

2022-10-07T07:16:56+00:00

commit 932befe39ddea29cf47f4f1dc080d3dba668f0ca upstream.

I observed a hang in generic/308 while running fstests on a i686 kernel.
The hang occurred when trying to purge the pagecache on a large sparse
file that had a page created past MAX_LFS_FILESIZE, which caused an
integer overflow in the pagecache xarray and resulted in an infinite
loop.

I then noticed that Linus changed the definition of MAX_LFS_FILESIZE in
commit 0cc3b0ec23ce ("Clarify (and fix) MAX_LFS_FILESIZE macros") so
that it is now one page short of the maximum page index on 32-bit
kernels.  Because the XFS function to compute max offset open-codes the
2005-era MAX_LFS_FILESIZE computation and neither the vfs nor mm perform
any sanity checking of s_maxbytes, the code in generic/308 can create a
page above the pagecache's limit and kaboom.

Fix all this by setting s_maxbytes to MAX_LFS_FILESIZE directly and
aborting the mount with a warning if our assumptions ever break.  I have
no answer for why this seems to have been broken for years and nobody
noticed.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: truncate should remove all blocks, not just to the end of the page cache

2022-10-07T07:16:56+00:00

commit 4bbb04abb4ee2e1f7d65e52557ba1c4038ea43ed upstream.

xfs_itruncate_extents_flags() is supposed to unmap every block in a file
from EOF onwards.  Oddly, it uses s_maxbytes as the upper limit to the
bunmapi range, even though s_maxbytes reflects the highest offset the
pagecache can support, not the highest offset that XFS supports.

The result of this confusion is that if you create a 20T file on a
64-bit machine, mount the filesystem on a 32-bit machine, and remove the
file, we leak everything above 16T.  Fix this by capping the bunmapi
request at the maximum possible block offset, not s_maxbytes.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman

xfs: introduce XFS_MAX_FILEOFF

2022-10-07T07:16:56+00:00

commit a5084865524dee1fe8ea1fee17c60b4369ad4f5e upstream.

Introduce a new #define for the maximum supported file block offset.
We'll use this in the next patch to make it more obvious that we're
doing some operation for all possible inode fork mappings after a given
offset.  We can't use ULLONG_MAX here because bunmapi uses that to
detect when it's done.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Christoph Hellwig 
Acked-by: Darrick J. Wong 
Signed-off-by: Chandan Babu R 
Signed-off-by: Greg Kroah-Hartman