Subject: Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

From: Arnaud Panaïotis <[email-masked]>
Date: Tue, 26 Apr 2022 14:44:37 +0200

On 21/04/2022 22:59, Pádraig Brady wrote:
> On 21/04/2022 18:41, Adhemerval Zanella wrote:
>>
>>
>> On 21/04/2022 12:25, Pádraig Brady wrote:
>>> On 21/04/2022 15:53, Arnaud Panaïotis wrote:
>>>>
>>>> On 21/04/2022 14:36, Pádraig Brady wrote:
>>>>> On 19/04/2022 16:01, Arnaud Panaïotis wrote:
>>>>>> On 19/04/2022 16:00, Pádraig Brady wrote:
>>>>>>> On 19/04/2022 08:47, Arnaud Panaïotis wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I did not received any feedback from this request right now.
>>>>>>>> Have you
>>>>>>>> made any progress on this subject ?
>>>>>>>>
>>>>>>>> Please let me know the progress for this, or contact me for
>>>>>>>> additional
>>>>>>>> information if needed.
>>>>>>>>
>>>>>>>> I'd like to have a ticket link to follow the advancement of
>>>>>>>> this issue
>>>>>>>> (if possible). I'm available to test a patch if you are able to
>>>>>>>> provide
>>>>>>>> me one.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> On 01/04/2022 15:55, Arnaud Panaïotis wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'm working for a client to generate embedded 32-bits Linux
>>>>>>>>> Kernel
>>>>>>>>> working after y2038 issue.
>>>>>>>>>
>>>>>>>>> I generated a 5.15 Kernel thought Buildroot with Coreutils
>>>>>>>>> 9.0, GCC
>>>>>>>>> 11.2.0, Binutils 2.37 and CFLAGS -D_LARGEFILE_SOURCE
>>>>>>>>> -D_FILE_OFFSET_BITS=64  -D_TIME_BITS=64
>>>>>>>>>
>>>>>>>>> The Kernel pass y2038 but I found an issue with cp:
>>>>>>>>> After analysis, the error occurs when trying to move an empty
>>>>>>>>> folder
>>>>>>>>> without all user mode rights.
>>>>>>>>>
>>>>>>>>> Here how to reproduce:
>>>>>>>>>
>>>>>>>>> # mkdir -p test/test1 folder
>>>>>>>>> # chmod u-w test/test1
>>>>>>>>> # date -s "2040-04-02"
>>>>>>>>> # cp -a test/* folder/
>>>>>>>>> cp: setting permissions for 'folder/test1' : Value too large
>>>>>>>>> for defined data type
>>>>>>>>>
>>>>>>>>> Note: The folder is copied before the error occurs. The copy
>>>>>>>>> works
>>>>>>>>> fine before y2038.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The issue comes from coreutils-9.0/src/cp.c
>>>>>>>>>
>>>>>>>>> Line 512 : if (lchmod (dir, stats.st_mode | S_IRWXU) != 0)
>>>>>>>>>
>>>>>>>>> FYI I had a previous issue while calling lstat function from
>>>>>>>>> <sys/stat.h> which is included in lib/lchmod.c. I used
>>>>>>>>> /usr/bin/stat
>>>>>>>>> as a workaround.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Keep me in touch if you need more information.
>>>>>>>
>>>>>>> The original mail seems to not have hit the lists, sorry.
>>>>>>>
>>>>>>> The error suggests that the fstatat() done within lchmod()
>>>>>>> is using a 32 bit time_t component of the stat structure.
>>>>>>> Your kernel is new enough to support the 64 bit equivalent,
>>>>>>> but you don't mention glibc. Can you ensure you're using
>>>>>>> at least glibc 2.34, which added support for the 64 bit variants.
>>>>>>>
>>>>>>> coreutils is configured by default to enable use
>>>>>>> of the 64 bit variants where available, and you've confirmed
>>>>>>> this as you say both -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64
>>>>>>> are defined.
>>>>>>>
>>>>>>> An strace of the cp command would be useful to confirm the
>>>>>>> problematic syscall.
>>>>>
>>>>> That suggests the kernel (statx) returns fine,
>>>>> but glibc is returning the EOVERFLOW.
>>>>> That suggests fstatat() rather than fstatat64() is being used
>>>>> (inferring that by comparing
>>>>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat.c
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/fstatat64.c)
>>>>>
>>>>>
>>>>> So why is fstatat() being used if compiling with
>>>>> -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64
>>>>>
>>>>> You might confirm what statat is being called with:
>>>>> nm cp | grep U.*statat
>>>>>
>>>>> The redirect from fstatat() in code to the appropriate 64 bit
>>>>> interface
>>>>> should be done with asm redirects and so immune to any undef etc.
>>>>> that gnulib may be doing.
>>>>>
>>>>> So in summary please look at how fstatat() is being referenced
>>>>> on your system (by gnulib).
>>>>>
>>>>> thanks,
>>>>> Pádraig
>>>>
>>>> Hi,
>>>>
>>>> I had to add -D option to nm to avoid "no symbols" error.
>>>>
>>>>           U [email-masked]
>>>>
>>>> All fstat, fstatat, lstat and stat are 64_time64 with the same GLIBC.
>>>
>>> That looks correct.
>>>
>>> So perhaps the EOVERFLOW is within your glibc's fstatat64
>>> implementation?
>>> You might get to the issue more quickly by installing debug symbols for
>>> your coreutils and/or glibc and using: gdb -tui -args cp rest of cp
>>> args
>>>
>>
>> Assuming a default config option (without --enable-kernel) the
>> _fstatat64_time64 should first try statx and then the old fstatat64
>> if statx fails with ENOSYS (on kernel older than 4.11).  The EOVERFLOW
>> only happens for later, assuming kernel does not returns anything
>> bogus.
>>
>> What strace shows in this scenario?
>
> strace shows statx() returning non error on this 5.15 kernel
Hi,

Sorry for the delay, had trouble to generate all requirements within
Buildroot (now with gdb+coreutils debugs). I can add glibc debug if needed.

quotearg_buffer_restyled (buffer=buffer@entry=0x41b5a0 <slot0> "",
  buffersize=<optimized out>, buffersize@entry=256,
arg=arg@entry=0x41c5f0 "folder/test1", argsize=4294967295,

     quoting_style=<optimized out>, flags=<optimized out>,
quote_these_too=<optimized out>, left_quote=0x0, right_quote=0x0)
at lib/quotearg.c:262

(gdb)
quotearg_n_options (n=n@entry=0, arg=arg@entry=0x41c5f0 "folder/test1",
argsize=argsize@entry=4294967295, options=0xbffff630) at
lib/quotearg.c:905

0x00406b46 in copy_reg (src_sb=<optimized out>,
new_dst=<optimized out>, omitted_permissions=<optimized
out>, dst_mode=<optimized out>, x=<optimized out>,
dst_name=<optimized out>,

     src_name=<optimized out>) at src/copy.c:1146

/bin/cp: setting permissions for 'folder/test1': Value too large for defined data type

I don't have layout src working but layout asm works.

(breakpoint at fstatat, then step by step).

Let me know if you need more details, I'm available for a shared screen
visio if needed (I'm in UTC+2).

Best regards,

--

*Arnaud PANAÏOTIS* | Lead Developer Freelance
+33 6 34 82 12 62 | [email-masked] <mailto:Arnaud Panaïotis
<[email-masked]>>

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr <https://www.panaiotis.fr>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus