Re: new cmp -i 99999999999999999999 failure

[Jim Meyering]

On Sun, Jun 25, 2023 at 3:33 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 2023-06-25 12:26, Jim Meyering wrote:
> > I was surprised to see your just-added "cmp" test failing, but only on 
> > Fedora 38.
> > This would report a difference:
> >
> >    echo a>a;echo b>b; src/cmp -i 99999999999999999999 a b
>
> Hmm, it doesn't fail for me on Fedora 38 x86-64. uname -a reports:
>
> Linux penguin.cs.ucla.edu 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC
> Thu Jun 15 02:15:40 UTC 2023 x86_64 GNU/Linux
>
> and 'dnf list glibc' says it's 2.37-4.fc38.

  $ rpm -q glibc
  glibc-2.37-4.fc38.x86_64

uname -a shows this: 6.2.15-300.fc38.x86_64

> What file system are you using? I ran my tests on ext4, and on tmpfs,
> and they all worked without your patch installed.

ext4 for me, too.

> What does strace say?
>
> Is there some ulimit thing that prevents large lseeks?
>
> A downside of the patch is that it breaks cmp on growing files due to a
> TOCTOU race. Is there some better way to work around the problem,
> whatever it is?
>
> In trying out the patch I discovered that it sometimes called read with
> very large sizes, and fixed that with the attached. I think this bug
> happened even without the patch.

A similar command (differing only in file names) shows failing lseeks like this:

openat(AT_FDCWD, "j1", O_RDONLY)        = 3
openat(AT_FDCWD, "j2", O_RDONLY)        = 4
lseek(3, 9223372036854775807, SEEK_CUR) = -1 EINVAL (Invalid argument)
read(3, 0x1a2ae50, 18446744073709551615) = -1 EFAULT (Bad address)
lseek(4, 9223372036854775807, SEEK_CUR) = -1 EINVAL (Invalid argument)
read(4, 0x1a2ae50, 18446744073709551615) = -1 EFAULT (Bad address)
read(3, "a\n", 4096)                    = 2
read(3, "", 4094)                       = 0
read(4, "b\n", 4096)                    = 2
read(4, "", 4094)                       = 0
j1 j2 differ: byte 1, line 1