summaryrefslogtreecommitdiffstats
path: root/fs/iomap
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2020-01-02 13:20:13 -0800
committerDarrick J. Wong <darrick.wong@oracle.com>2020-01-14 08:02:53 -0800
commit932befe39ddea29cf47f4f1dc080d3dba668f0ca (patch)
tree83e75f4841076c28439a1bbc8f9b875b19c285a7 /fs/iomap
parent4bbb04abb4ee2e1f7d65e52557ba1c4038ea43ed (diff)
downloadlinux-932befe39ddea29cf47f4f1dc080d3dba668f0ca.tar.bz2
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>
Diffstat (limited to 'fs/iomap')
0 files changed, 0 insertions, 0 deletions