| Message ID | 20201004180428.14494-2-willy@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix a pile of 4GB file problems on 32-bit | expand |
On Sun, Oct 04, 2020 at 07:04:22PM +0100, Matthew Wilcox (Oracle) wrote: > On 32-bit systems, this multiplication will overflow for files larger > than 4GB. > > Cc: stable@vger.kernel.org > Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.") > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > --- > fs/9p/vfs_file.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c > index 3576123d8299..6d97b6b4d34b 100644 > --- a/fs/9p/vfs_file.c > +++ b/fs/9p/vfs_file.c > @@ -612,9 +612,9 @@ static void v9fs_mmap_vm_close(struct vm_area_struct *vma) > struct writeback_control wbc = { > .nr_to_write = LONG_MAX, > .sync_mode = WB_SYNC_ALL, > - .range_start = vma->vm_pgoff * PAGE_SIZE, > + .range_start = (loff_t)vma->vm_pgoff * PAGE_SIZE, Given the may places where this issue shows up I think we really need a vma_offset or similar helper for it. Much better than chasing missing casts everywhere.
On Wed, Oct 07, 2020 at 06:48:49AM +0100, Christoph Hellwig wrote: > > - .range_start = vma->vm_pgoff * PAGE_SIZE, > > + .range_start = (loff_t)vma->vm_pgoff * PAGE_SIZE, > > Given the may places where this issue shows up I think we really need > a vma_offset or similar helper for it. Much better than chasing missing > casts everywhere. Good point. I think these patches need to go in to fix the bugs in the various stable releases, but we should definitely have a helper for the future. Also, several of these patches are for non-VMA pgoff_t. vma_offset() is a bit weird for me -- vmas have all kinds of offsets. vma_file_offset() would work or vma_fpos(). I tend to prefer the shorter function name ;-) A quick grep shows we probably want a vmf_fpos() too: arch/powerpc/platforms/cell/spufs/file.c: unsigned long area, offset = vmf->pgoff << PAGE_SHIFT; arch/x86/entry/vdso/vma.c: sym_offset = (long)(vmf->pgoff << PAGE_SHIFT) + drivers/gpu/drm/gma500/framebuffer.c: address = vmf->address - (vmf->pgoff << PAGE_SHIFT); drivers/scsi/cxlflash/ocxl_hw.c: offset = vmf->pgoff << PAGE_SHIFT; I'm sure a lot of this will never run on a 32-bit kernel or with a 4GB file, but it's not good to have bad code around for people to copy from.
Matthew Wilcox (Oracle) wrote on Sun, Oct 04, 2020: > On 32-bit systems, this multiplication will overflow for files larger > than 4GB. > > Cc: stable@vger.kernel.org > Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.") > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> I realize I hadn't sent a mail -- FWIW this 9p patch has been merged, thanks!
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c index 3576123d8299..6d97b6b4d34b 100644 --- a/fs/9p/vfs_file.c +++ b/fs/9p/vfs_file.c @@ -612,9 +612,9 @@ static void v9fs_mmap_vm_close(struct vm_area_struct *vma) struct writeback_control wbc = { .nr_to_write = LONG_MAX, .sync_mode = WB_SYNC_ALL, - .range_start = vma->vm_pgoff * PAGE_SIZE, + .range_start = (loff_t)vma->vm_pgoff * PAGE_SIZE, /* absolute end, byte at end included */ - .range_end = vma->vm_pgoff * PAGE_SIZE + + .range_end = (loff_t)vma->vm_pgoff * PAGE_SIZE + (vma->vm_end - vma->vm_start - 1), };
On 32-bit systems, this multiplication will overflow for files larger than 4GB. Cc: stable@vger.kernel.org Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.") Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> --- fs/9p/vfs_file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)