Re: [PATCH] generic/286: fix integer underflow on block sizes != 4096

[Eryu Guan <guan@eryu.me>]

On Sat, May 22, 2021 at 08:48:14PM +0200, Jakob Unterwurzacher wrote:
> The read loop always requested 4096 bytes, which only works
> when the total read length is a multiple of 4096 bytes.

The total read length should be

"The length of this extent is (hole_off - data_off)"

according to the comments above do_extent_copy(). Total read length
being not a multiple of 4k means 'data_off' or 'hole_off' is not 4k
aligned.

> 
> This is not neccessarily true, and when it's not, len wraps

But generic/286 creates source files with lenght of all data extents and
hole extents being multiple of 4k. So I still don't understand why this
is valid for gocryptfs. Shouldn't that be a bug in seek_data/seek_hole
in gocryptfs? Could you please elaborate?

Thanks,
Eryu

> around to UINT64_MAX and you get a lot of these:
> 
> 	ERROR: [error:38] reached EOF:Success
> 
> This was caught when running xfstests against gocryptfs,
> an encrypted overlay file system.
> 
> On ext4, the test still passes after this change.
> 
> Signed-off-by: Jakob Unterwurzacher <jakobunt@gmail.com>
> ---
>  src/seek_copy_test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/seek_copy_test.c b/src/seek_copy_test.c
> index 0c2c6a3d..28c021e2 100644
> --- a/src/seek_copy_test.c
> +++ b/src/seek_copy_test.c
> @@ -98,7 +98,7 @@ do_extent_copy(int src_fd, int dest_fd, off_t data_off, off_t hole_off)
>  	}
>  
>  	while (len > 0) {
> -		ssize_t nr_read = read(src_fd, buf, BUF_SIZE);
> +		ssize_t nr_read = read(src_fd, buf, MIN(len, BUF_SIZE));
>  		if (nr_read < 0) {
>  			if (errno == EINTR)
>  				continue;
> -- 
> 2.31.1