On 32-bit systems, this multiplication will overflow for files larger
than 4GB.
Cc: [email protected]
Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
---
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,
/* 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),
};
--
2.28.0
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: [email protected]
> Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
> Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
> ---
> 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: [email protected]
> Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
> Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
I realize I hadn't sent a mail -- FWIW this 9p patch has been merged,
thanks!
--
Dominique