bug-coreutils
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Arnaud Panaïotis
Subject: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel
Date: Tue, 26 Apr 2022 14:44:37 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 

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 __fstatat64_time64@GLIBC_2.34

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 | arnaud.panaiotis@gmx.fr <mailto:Arnaud Panaïotis
<arnaud.panaiotis@gmx.fr>>

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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]