| Message ID | 20250109041253.2494374-1-marco.nelissen@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | iomap: avoid avoid truncating 64-bit offset to 32 bits | expand |
On Wed, Jan 08, 2025 at 08:11:50PM -0800, Marco Nelissen wrote: > on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a > 32-bit position due to folio_next_index() returning an unsigned long. > This could lead to an infinite loop when writing to an xfs filesystem. > > Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com> > --- > fs/iomap/buffered-io.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 54dc27d92781..d303e6c8900c 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -1138,7 +1138,7 @@ static void iomap_write_delalloc_scan(struct inode *inode, > start_byte, end_byte, iomap, punch); > > /* move offset to start of next folio in range */ > - start_byte = folio_next_index(folio) << PAGE_SHIFT; > + start_byte = folio_pos(folio) + folio_size(folio); eeek. Yeah, I guess that would happen towards the upper end of the 16T range on 32-bit. I wonder if perhaps pagemap.h should have: static inline loff_t folio_next_pos(struct folio *folio) { return folio_pos(folio) + folio_size(folio); } But I think this is the only place in the kernel that uses this construction? So maybe not worth the fuss. Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> --D > folio_unlock(folio); > folio_put(folio); > } > -- > 2.39.5 >
On Wed, Jan 8, 2025 at 8:38 PM Darrick J. Wong <djwong@kernel.org> wrote: > > On Wed, Jan 08, 2025 at 08:11:50PM -0800, Marco Nelissen wrote: > > on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a > > 32-bit position due to folio_next_index() returning an unsigned long. > > This could lead to an infinite loop when writing to an xfs filesystem. > > > > Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com> > > --- > > fs/iomap/buffered-io.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > > index 54dc27d92781..d303e6c8900c 100644 > > --- a/fs/iomap/buffered-io.c > > +++ b/fs/iomap/buffered-io.c > > @@ -1138,7 +1138,7 @@ static void iomap_write_delalloc_scan(struct inode *inode, > > start_byte, end_byte, iomap, punch); > > > > /* move offset to start of next folio in range */ > > - start_byte = folio_next_index(folio) << PAGE_SHIFT; > > + start_byte = folio_pos(folio) + folio_size(folio); > > eeek. Yeah, I guess that would happen towards the upper end of the 16T > range on 32-bit. By "16T" do you mean 16 TeraByte? I'm able to reproduce the infinite loop with files around 4 GB. > I wonder if perhaps pagemap.h should have: > > static inline loff_t folio_next_pos(struct folio *folio) > { > return folio_pos(folio) + folio_size(folio); > } > > But I think this is the only place in the kernel that uses this > construction? So maybe not worth the fuss. > > Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> > > --D > > > folio_unlock(folio); > > folio_put(folio); > > } > > -- > > 2.39.5 > >
On Wed, Jan 08, 2025 at 08:45:07PM -0800, Marco Nelissen wrote: > On Wed, Jan 8, 2025 at 8:38 PM Darrick J. Wong <djwong@kernel.org> wrote: > > > > On Wed, Jan 08, 2025 at 08:11:50PM -0800, Marco Nelissen wrote: > > > on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a > > > 32-bit position due to folio_next_index() returning an unsigned long. > > > This could lead to an infinite loop when writing to an xfs filesystem. > > > > > > Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com> > > > --- > > > fs/iomap/buffered-io.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > > > index 54dc27d92781..d303e6c8900c 100644 > > > --- a/fs/iomap/buffered-io.c > > > +++ b/fs/iomap/buffered-io.c > > > @@ -1138,7 +1138,7 @@ static void iomap_write_delalloc_scan(struct inode *inode, > > > start_byte, end_byte, iomap, punch); > > > > > > /* move offset to start of next folio in range */ > > > - start_byte = folio_next_index(folio) << PAGE_SHIFT; > > > + start_byte = folio_pos(folio) + folio_size(folio); > > > > eeek. Yeah, I guess that would happen towards the upper end of the 16T > > range on 32-bit. > > By "16T" do you mean 16 TeraByte? I'm able to reproduce the infinite loop > with files around 4 GB. Yes. On 32-bit, everything between 2^32 and 16T is the upper end. :) --D > > I wonder if perhaps pagemap.h should have: > > > > static inline loff_t folio_next_pos(struct folio *folio) > > { > > return folio_pos(folio) + folio_size(folio); > > } > > > > But I think this is the only place in the kernel that uses this > > construction? So maybe not worth the fuss. > > > > Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> > > > > --D > > > > > folio_unlock(folio); > > > folio_put(folio); > > > } > > > -- > > > 2.39.5 > > >
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
On Wed, 08 Jan 2025 20:11:50 -0800, Marco Nelissen wrote: > on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a > 32-bit position due to folio_next_index() returning an unsigned long. > This could lead to an infinite loop when writing to an xfs filesystem. > > Applied to the vfs.fixes branch of the vfs/vfs.git tree. Patches in the vfs.fixes branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.fixes [1/1] iomap: avoid avoid truncating 64-bit offset to 32 bits https://git.kernel.org/vfs/vfs/c/c13094b894de
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 54dc27d92781..d303e6c8900c 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1138,7 +1138,7 @@ static void iomap_write_delalloc_scan(struct inode *inode, start_byte, end_byte, iomap, punch); /* move offset to start of next folio in range */ - start_byte = folio_next_index(folio) << PAGE_SHIFT; + start_byte = folio_pos(folio) + folio_size(folio); folio_unlock(folio); folio_put(folio); }
on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a 32-bit position due to folio_next_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem. Signed-off-by: Marco Nelissen <marco.nelissen@gmail.com> --- fs/iomap/buffered-io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)