diff mbox series

[7/8] xfs_io: fix pwrite/pread length truncation on 32-bit systems

Message ID 157982503725.2765410.9945705757777826157.stgit@magnolia (mailing list archive)
State Accepted, archived
Headers show
Series xfsprogs: random fixes | expand

Commit Message

Darrick J. Wong Jan. 24, 2020, 12:17 a.m. UTC 
From: Darrick J. Wong <darrick.wong@oracle.com>

The pwrite and pread commands in xfs_io accept an operation length that
can be any quantity that fits in a long long int; and loops to handle
the cases where the operation length is larger than the IO buffer.

Weirdly, the do_ functions contain code to shorten the operation to the
IO buffer size but the @count parameter is size_t, which means that for
a large argument on a 32-bit system, we rip off the upper bits of the
length, turning your 8GB write into a 0 byte write, which does nothing.

This was found by running generic/175 and observing that the 8G test
file it creates has zero length after the operation:

wrote 0/8589934592 bytes at offset 0
0.000000 bytes, 0 ops; 0.0001 sec (0.000000 bytes/sec and 0.0000 ops/sec)

Fix this by pushing long long count all the way through the call stack.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 io/pread.c  |    4 ++--
 io/pwrite.c |    6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

Comments

Christoph Hellwig Jan. 25, 2020, 11:18 p.m. UTC | #1 
On Thu, Jan 23, 2020 at 04:17:17PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> The pwrite and pread commands in xfs_io accept an operation length that
> can be any quantity that fits in a long long int; and loops to handle
> the cases where the operation length is larger than the IO buffer.
> 
> Weirdly, the do_ functions contain code to shorten the operation to the
> IO buffer size but the @count parameter is size_t, which means that for
> a large argument on a 32-bit system, we rip off the upper bits of the
> length, turning your 8GB write into a 0 byte write, which does nothing.
> 
> This was found by running generic/175 and observing that the 8G test
> file it creates has zero length after the operation:
> 
> wrote 0/8589934592 bytes at offset 0
> 0.000000 bytes, 0 ops; 0.0001 sec (0.000000 bytes/sec and 0.0000 ops/sec)
> 
> Fix this by pushing long long count all the way through the call stack.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>
diff mbox series

Patch

diff --git a/io/pread.c b/io/pread.c
index 1b4352be..d52e21d9 100644
--- a/io/pread.c
+++ b/io/pread.c
@@ -164,7 +164,7 @@  static ssize_t
 do_preadv(
 	int		fd,
 	off64_t		offset,
-	size_t		count)
+	long long	count)
 {
 	int		vecs = 0;
 	ssize_t		oldlen = 0;
@@ -199,7 +199,7 @@  static ssize_t
 do_pread(
 	int		fd,
 	off64_t		offset,
-	size_t		count,
+	long long	count,
 	size_t		buffer_size)
 {
 	if (!vectors)
diff --git a/io/pwrite.c b/io/pwrite.c
index ccf14be9..1c28612f 100644
--- a/io/pwrite.c
+++ b/io/pwrite.c
@@ -54,8 +54,8 @@  static ssize_t
 do_pwritev(
 	int		fd,
 	off64_t		offset,
-	size_t		count,
-	int 		pwritev2_flags)
+	long long	count,
+	int		pwritev2_flags)
 {
 	int vecs = 0;
 	ssize_t oldlen = 0;
@@ -97,7 +97,7 @@  static ssize_t
 do_pwrite(
 	int		fd,
 	off64_t		offset,
-	size_t		count,
+	long long	count,
 	size_t		buffer_size,
 	int		pwritev2_flags)
 {