* [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits
@ 2025-01-09 4:11 Marco Nelissen
2025-01-09 4:38 ` Darrick J. Wong
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Marco Nelissen @ 2025-01-09 4:11 UTC (permalink / raw)
To: brauner, djwong, linux-xfs, linux-fsdevel, linux-kernel; +Cc: Marco Nelissen
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);
folio_unlock(folio);
folio_put(folio);
}
--
2.39.5
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits
2025-01-09 4:11 [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits Marco Nelissen
@ 2025-01-09 4:38 ` Darrick J. Wong
2025-01-09 4:45 ` Marco Nelissen
2025-01-09 6:10 ` Christoph Hellwig
2025-01-09 15:09 ` Christian Brauner
2 siblings, 1 reply; 6+ messages in thread
From: Darrick J. Wong @ 2025-01-09 4:38 UTC (permalink / raw)
To: Marco Nelissen; +Cc: brauner, linux-xfs, linux-fsdevel, linux-kernel
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits
2025-01-09 4:38 ` Darrick J. Wong
@ 2025-01-09 4:45 ` Marco Nelissen
2025-01-09 4:47 ` Darrick J. Wong
0 siblings, 1 reply; 6+ messages in thread
From: Marco Nelissen @ 2025-01-09 4:45 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: brauner, linux-xfs, linux-fsdevel, linux-kernel
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
> >
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits
2025-01-09 4:45 ` Marco Nelissen
@ 2025-01-09 4:47 ` Darrick J. Wong
0 siblings, 0 replies; 6+ messages in thread
From: Darrick J. Wong @ 2025-01-09 4:47 UTC (permalink / raw)
To: Marco Nelissen; +Cc: brauner, linux-xfs, linux-fsdevel, linux-kernel
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
> > >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits
2025-01-09 4:11 [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits Marco Nelissen
2025-01-09 4:38 ` Darrick J. Wong
@ 2025-01-09 6:10 ` Christoph Hellwig
2025-01-09 15:09 ` Christian Brauner
2 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2025-01-09 6:10 UTC (permalink / raw)
To: Marco Nelissen; +Cc: brauner, djwong, linux-xfs, linux-fsdevel, linux-kernel
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits
2025-01-09 4:11 [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits Marco Nelissen
2025-01-09 4:38 ` Darrick J. Wong
2025-01-09 6:10 ` Christoph Hellwig
@ 2025-01-09 15:09 ` Christian Brauner
2 siblings, 0 replies; 6+ messages in thread
From: Christian Brauner @ 2025-01-09 15:09 UTC (permalink / raw)
To: Marco Nelissen
Cc: Christian Brauner, djwong, linux-xfs, linux-fsdevel, linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-01-09 15:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-09 4:11 [PATCH] iomap: avoid avoid truncating 64-bit offset to 32 bits Marco Nelissen
2025-01-09 4:38 ` Darrick J. Wong
2025-01-09 4:45 ` Marco Nelissen
2025-01-09 4:47 ` Darrick J. Wong
2025-01-09 6:10 ` Christoph Hellwig
2025-01-09 15:09 ` Christian Brauner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox