On Wed, Sep 25, 2013 at 04:10:20PM +0800, Jeff Liu wrote: > From: Jie Liu <jeff.liu@xxxxxxxxxx> > > Write a file with an offset greater than 16TB on 32-bit system and > then trigger page write-back via sync(1) as below will cause the > task hang in a little while: [snip] > This patch just fixed both issues. > > Reported-by: Michael L. Semon <mlsemon35@xxxxxxxxx> > Signed-off-by: Jie Liu <jeff.liu@xxxxxxxxxx> > --- > v2: don't reset the s_max_bytes to MAX_LFS_FILESIZE, instead, revise the page offset > check up strategy to avoid the potential overflow. > v1: http://oss.sgi.com/archives/xfs/2013-07/msg00154.html > > fs/xfs/xfs_aops.c | 11 ++++++----- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c > index 41a6950..6059d00 100644 > --- a/fs/xfs/xfs_aops.c > +++ b/fs/xfs/xfs_aops.c > @@ -969,7 +969,9 @@ xfs_vm_writepage( > offset = i_size_read(inode); > end_index = offset >> PAGE_CACHE_SHIFT; > last_index = (offset - 1) >> PAGE_CACHE_SHIFT; > - if (page->index >= end_index) { > + if (page->index < end_index) > + end_offset = (xfs_off_t)(page->index + 1) << PAGE_CACHE_SHIFT; > + else { > unsigned offset_into_page = offset & (PAGE_CACHE_SIZE - 1); The logic here is already difficult to understand, and the fact that the code that has 32 bit overflow issues is not obvious . Can you add a comment noting the overflow issue being handled here? > > /* > @@ -978,7 +980,8 @@ xfs_vm_writepage( > * page so that reclaim stops reclaiming it. Otherwise > * xfs_vm_releasepage() is called on it and gets confused. > */ > - if (page->index >= end_index + 1 || offset_into_page == 0) > + if (page->index > end_index || > + (page->index == end_index && offset_into_page == 0)) > goto redirty; And again here? That means in future we will be aware of the problem when reading the code... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
