Bootstrap packages fail to build due to mes-libc lacking 'stat64' etc. syscalls

  • Open
  • quality assurance status badge
Details
4 participants
  • Andreas Enge
  • Jan Nieuwenhuizen
  • Ludovic Courtès
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Mathieu Othacehe
Severity
important
Merged with
M
M
Mathieu Othacehe wrote on 14 May 2020 17:17
Bootstrap packages fail to build.
(address . bug-guix@gnu.org)(address . janneke@gnu.org)
87h7wik0kk.fsf@gnu.org
Hello,

This command fails on one of my systems:

Toggle snippet (3 lines)
guix build -e "(@@ (gnu packages commencement) glibc-mesboot0)"

with the following error:

Toggle snippet (11 lines)
phase `unpack' succeeded after 11.8 seconds
starting phase `apply-boot-patch'
patch: **** fstatsterror: unknown error:
command "patch" "--force" "-p1" "-i" "/gnu/store/pfz4y5i7krlvam2m8lpddmg9vi44rpqh-glibc-boot-2.2.5.patch" failed with status 2
note: keeping build directory `/tmp/guix-build-glibc-mesboot0-2.2.5.drv-1'
builder for `/gnu/store/jcqggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv' failed with exit code 1
build of /gnu/store/jcqggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv failed
View build log at '/var/log/guix/drvs/jc/qggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv.bz2'.
guix build: error: build of `/gnu/store/jcqggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv' failed

Here's a stracing of the failing "patch" command:

Toggle snippet (5 lines)
open("/gnu/store/pfz4y5i7krlvam2m8lpddmg9vi44rpqh-glibc-boot-2.2.5.patch", O_RDONLY) = 3
brk(0x9377913) = 0x9377913
fstat(3, 0xffb29328) = -1 EOVERFLOW (Value too large for defined data type)

"patch-mesboot" is built for 32 bits. Hence, it can be using
"__ia32_sys_fstat", "__ia32_compat_sys_newfstat" or
"__ia32_compat_sys_x86_fstat64" syscall for "fstat". Here, according to
perf, it's using __ia32_compat_sys_newfstat which is overflowing on my
file system (inode count to high or so).

There's a little demonstration program attached. When built with `gcc
-m32 test.c', I have:

Toggle snippet (5 lines)
fstat(3, 0xffad5874) = -1 EOVERFLOW (Value too large for defined data type)
fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0

So I think somehow, bootstrap packages use the legacy "fstat" syscall,
which may overflow on a 64 bits system.

WDYT,

Thanks,

Mathieu
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/sysmacros.h>

int
main(int argc, char *argv[])
{
struct stat sb;

if (argc != 2) {
fprintf(stderr, "Usage: %s <pathname>\n", argv[0]);
exit(EXIT_FAILURE);
}

int fd = open(argv[1], O_RDONLY);
syscall(__NR_fstat, fd, &sb);
syscall(__NR_fstat64, fd, &sb);
fstat(fd, &sb);


exit(EXIT_SUCCESS);
}
M
M
Mathieu Othacehe wrote on 15 May 2020 14:11
(address . 41264@debbugs.gnu.org)
87v9kxe6tl.fsf@gnu.org
Hello,

Toggle quote (7 lines)
> fstat(3, 0xffad5874) = -1 EOVERFLOW (Value too large for defined data type)
> fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
> fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
>
> So I think somehow, bootstrap packages use the legacy "fstat" syscall,
> which may overflow on a 64 bits system.

More info on that one. Linux syscall "newstat", will call
"cp_compat_stat". This function starts by checking the device id:

Toggle snippet (6 lines)
struct compat_stat tmp;

if (!old_valid_dev(stat->dev) || !old_valid_dev(stat->rdev))
return -EOVERFLOW;

Here, stat->dev is 66308 (major: 259, minor 4).

"old_valid_dev" checks that:

Toggle snippet (17 lines)
static inline bool old_valid_dev(dev_t dev)
{
return MAJOR(dev) < 256 && MINOR(dev) < 256;
}--8<---------------cut here---------------end--------------->8---

Which is false here, because my NVME disk has a BLOCK_EXT_MAJOR (259).

So stat, lstat, and all other related function will return -EOVERFLOW
unless their 64 bits stat64, lstat64 counterpart is used.

So I think this means that one cannot build the Guix bootstrap toolchain on an
NVME disk.

Thanks,

Mathieu
M
M
Mathieu Othacehe wrote on 19 May 2020 10:52
(address . 41264@debbugs.gnu.org)
87ftbwtigj.fsf@gnu.org
Hello,

Toggle quote (6 lines)
> So stat, lstat, and all other related function will return -EOVERFLOW
> unless their 64 bits stat64, lstat64 counterpart is used.
>
> So I think this means that one cannot build the Guix bootstrap toolchain on an
> NVME disk.

After further investigations I think that it is needed to patch GNU Mes
to fix this bug.

We would need to add three new syscalls for x86:

Toggle snippet (5 lines)
#define SYS_stat64 0xc3
#define SYS_lstat64 0xc4
#define SYS_fstat64 0xc5

lib/linux/stat.c should be modified this way:

Toggle snippet (24 lines)
#if __i386__
#define STAT_SYSCALL SYS_stat64
#else
#define STAT_SYSCALL SYS_stat
#endif

int
stat (char const *file_name, struct stat *statbuf)
{
struct stat64 statbuf64;
int ret;

ret = _sys_call2 (STAT_SYSCALL, (long) file_name, (long) &statbuf64);

#if __i386__
stat64_to_32(&statbuf64, statbuf);
#else
*statbuf = statbuf64;
#endif

return ret;
}

Then we would need to create stat64_to_32 which could be inspired from
__xstat64_conv from the glibc. Then, lstat and fstat64 would need to be
patched the same way.

This way, we would replicate the glibc behavior.

Thanks,

Mathieu
J
J
Jan Nieuwenhuizen wrote on 19 May 2020 18:52
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 41264@debbugs.gnu.org)
87sgfvq32v.fsf@gnu.org
Mathieu Othacehe writes:

Hello Mathieu,

Toggle quote (9 lines)
>> So stat, lstat, and all other related function will return -EOVERFLOW
>> unless their 64 bits stat64, lstat64 counterpart is used.
>>
>> So I think this means that one cannot build the Guix bootstrap toolchain on an
>> NVME disk.
>
> After further investigations I think that it is needed to patch GNU Mes
> to fix this bug.

Hmm, we need to patch Mes after all. That's unfortunate.

Toggle quote (15 lines)
> We would need to add three new syscalls for x86:
>
> #define SYS_stat64 0xc3
> #define SYS_lstat64 0xc4
> #define SYS_fstat64 0xc5
>
>
> lib/linux/stat.c should be modified this way:
>
> #if __i386__
> #define STAT_SYSCALL SYS_stat64
> #else
> #define STAT_SYSCALL SYS_stat
> #endif

Ah...the stat64 syscall is meant for i386; now it at starts making at
least some sense to me.

Toggle quote (17 lines)
> int
> stat (char const *file_name, struct stat *statbuf)
> {
> struct stat64 statbuf64;
> int ret;
>
> ret = _sys_call2 (STAT_SYSCALL, (long) file_name, (long) &statbuf64);
>
> #if __i386__
> stat64_to_32(&statbuf64, statbuf);
> #else
> *statbuf = statbuf64;
> #endif
>
> return ret;
> }

That looks OK...

Toggle quote (6 lines)
> Then we would need to create stat64_to_32 which could be inspired from
> __xstat64_conv from the glibc. Then, lstat and fstat64 would need to be
> patched the same way.
>
> This way, we would replicate the glibc behavior.

Beautiful, thanks for getting to the bottom of this. Now that you
already have gone this far, would you like to whip-up a full patch for
GNU Mes?

To test it we may have to provide a tarball as we don't want to use XZ
and we don't have patch yet. Or possibly we can download some
individual files ande overwrite them.

Greetings,
Janneke

--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 1 Sep 2021 15:56
control message for bug #41264
(address . control@debbugs.gnu.org)
87wno0761w.fsf@gnu.org
merge 41264 49985
quit
L
L
Ludovic Courtès wrote on 1 Sep 2021 15:59
(address . control@debbugs.gnu.org)
87v93k75xu.fsf@gnu.org
retitle 41264 Bootstrap packages fail to build due to mes-libc lacking 'stat64' etc. syscalls
quit
L
L
Ludovic Courtès wrote on 1 Sep 2021 15:59
(address . control@debbugs.gnu.org)
87tuj475xp.fsf@gnu.org
severity 41264 important
quit
J
J
Jan Nieuwenhuizen wrote on 13 Feb 2023 12:28
Re: bug#49985: Bootstrap packages fail to build due to mes-libc lacking 'stat64' etc. syscalls
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87bklxztvt.fsf_-_@gnu.org
Jan Nieuwenhuizen writes:

Hello!

Toggle quote (1 lines)
> Mathieu Othacehe writes:
[..]
Toggle quote (10 lines)
>> lib/linux/stat.c should be modified this way:
>>
>> #if __i386__
>> #define STAT_SYSCALL SYS_stat64
>> #else
>> #define STAT_SYSCALL SYS_stat
>> #endif
>
> Ah...the stat64 syscall is meant for i386; now it at starts making at
> least some sense to me.
[..]
Toggle quote (5 lines)
>> This way, we would replicate the glibc behavior.
>
> Beautiful, thanks for getting to the bottom of this. Now that you
> already have gone this far, would you like to whip-up a full patch for
> GNU Mes?
[..]

To use stat64 and friends on 32bit, I created the attached patch for GNU
Mes and hope to create a 0.24.2 release from


Also, I have update my core-updates branch with preliminary 0.24.2 mes
and mes-boot packages here


Greetings,
Janneke
J
J
Janneke Nieuwenhuizen wrote on 15 Feb 2023 09:45
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87a61fgvuu.fsf@gnu.org
Jan Nieuwenhuizen writes:

Hello,

Toggle quote (10 lines)
> To use stat64 and friends on 32bit, I created the attached patch for GNU
> Mes and hope to create a 0.24.2 release from
>
> https://gitlab.com/janneke/mes/-/tree/wip-stat64
>
> Also, I have update my core-updates branch with preliminary 0.24.2 mes
> and mes-boot packages here
>
> https://gitlab.com/janneke/guix/-/tree/core-updates

I've got a confirmation this works*, have released 0.24.2 and updated
mes-boot on core-updates as
b928e38bd333e6186727fe5c5e94b85d157b79d6

Hoping to finally close these bugs!

Greetings,
Janneke


--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
J
J
Janneke Nieuwenhuizen wrote on 16 Feb 2023 16:03
Re: Merging core-updates?
(name . Andreas Enge)(address . andreas@enge.fr)
87h6vlfya4.fsf@gnu.org
Andreas Enge writes:

Toggle quote (7 lines)
> Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen:
>> I have released 0.24.2 and updated mes-boot on core-updates as
>> Let's hope this fixes these bugs.
>
> With your latest patch, I have successfully bootstrapped core-updates
> on x86_64 up to hello and mpc. Thanks a lot!

Great, thanks so much for checking! Are you using any of tmpfs or btrfs
on /tmp?

Greetings,
janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
A
A
Andreas Enge wrote on 16 Feb 2023 16:24
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Y+5KklptkTuzW+dd@jurong
Am Thu, Feb 16, 2023 at 04:03:15PM +0100 schrieb Janneke Nieuwenhuizen:
Toggle quote (3 lines)
> Great, thanks so much for checking! Are you using any of tmpfs or btrfs
> on /tmp?

No, it is all on SSD, so we probably cannot conclude for the bugs,
unfortunately.

Andreas
?