[Toybox] [PATCH] sendfile_len: fix bounds check.

enh enh at google.com
Wed Jul 31 13:13:09 PDT 2024


oh, and the unconcluded thought in the commit message is "...but it
seems unreasonable to add a test that requires > 2GiB of disk space,
so i haven't included a new test in this patch".

On Wed, Jul 31, 2024 at 4:09 PM enh <enh at google.com> wrote:
>
> this is actually a regression in Android V, since the change to enable
> the use of copy_file_range(2) went in too late for U, so i'm sending
> this minimal fix that i can cherrypick to Android V (since regular
> AOSP changes won't make it to V at this point).
>
> that said... there's a separate cosmetic issue i noticed while testing:
> ```
> /tmp/x$ ~/toybox-tar/toybox tar xvf ~/toybox-tar/x/x.tar
> tar: tar: had errors
> two
> two-and-a-half
> /tmp/x$ ls -l
> total 4657156
> -rw-r----- 1 enh primarygroup 2147483648 Jul 31 15:44 two
> -rw-r----- 1 enh primarygroup 2621441024 Jul 31 15:45 two-and-a-half
> ```
> from the
> ```
> error:
>       if (fd!=1) perror_msg(0);
>       skippy(TT.hdr.size-used);
> ```
> code in tar.c's sendfile_sparse() that's probably worth a separate fix.
>
>
> On Wed, Jul 31, 2024 at 4:04 PM enh <enh at google.com> wrote:
> >
> > We want to check whether the next call we make will try to send more
> > than 1<<30 bytes, not whether the total number of bytes to transfer is
> > more than that.
> >
> > Interestingly, the read() fallback implementation already has the right
> > check, presumably because files larger than libbuf are commonplace,
> > whereas files larger than 1<<30 bytes are not.
> >
> > Tested locally using truncate to create a 2GiB file (which works) and a
> > 2.5GiB file (which does not work), tar to create the tarfile, and then
> > tar to extract them.
> > ---
> >  lib/portability.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)


More information about the Toybox mailing list