xfs: fix s_maxbytes computation on 32-bit kernels
authorDarrick J. Wong <darrick.wong@oracle.com>
Thu, 2 Jan 2020 21:20:13 +0000 (13:20 -0800)
committerDarrick J. Wong <darrick.wong@oracle.com>
Tue, 14 Jan 2020 16:02:53 +0000 (08:02 -0800)
commit932befe39ddea29cf47f4f1dc080d3dba668f0ca
tree83e75f4841076c28439a1bbc8f9b875b19c285a7
parent4bbb04abb4ee2e1f7d65e52557ba1c4038ea43ed
xfs: fix s_maxbytes computation on 32-bit kernels

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 <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
fs/xfs/xfs_super.c