glibc 2.39 test failure on ppc64el: elf/tst-decorate-maps

[Simon Chopin]

This test fails on Noble/ppc64el

3775s FAIL: elf/tst-decorate-maps
3775s original exit status 1
3775s error: tst-decorate-maps.c:152: not true: r.n_loader_malloc_mmap >= 1
3775s error: tst-decorate-maps.c:167: not true: r.n_loader_malloc_mmap >= 1
3775s error: tst-decorate-maps.c:152: not true: r.n_loader_malloc_mmap >= 1
3775s error: tst-decorate-maps.c:167: not true: r.n_loader_malloc_mmap >= 1
3775s error: 4 test failures

[Paolo Pisati (p-pisati)]

What's the kernel version? Do you have a log?

[Simon Chopin (schopin)]

Using the Ubuntu kernels (e.g. 6.5.0-26-generic from Mantic, but also the ones in the upcoming Noble), the glibc test suite fails on

FAIL: elf/tst-decorate-maps
original exit status 1
error: tst-decorate-maps.c:152: not true: r.n_loader_malloc_mmap >= 1
error: tst-decorate-maps.c:167: not true: r.n_loader_malloc_mmap >= 1
error: tst-decorate-maps.c:152: not true: r.n_loader_malloc_mmap >= 1
error: tst-decorate-maps.c:167: not true: r.n_loader_malloc_mmap >= 1
error: 4 test failures

Tested on upstream master branch (as of dc1a77269c "htl: Implement some support for TLS_DTV_AT_TP"), release/2.39/master, as well as the Ubuntu package.

I couldn't see anything particularly relevant in the system logs.

(assigning to malloc component since this seems to be primarily about allocations)

[Andreas Schwab (schwab-linux-m68k)]

Does the kernel use 64k pages?

[Simon Chopin (schopin)]

(In reply to Andreas Schwab from comment #1)
> Does the kernel use 64k pages?

$ getconf PAGESIZE
65536

I guess it does.

[Simon Chopin (schopin)]

@Paolo thanks for probing this. I finally managed to get my hands on a suitable power system with recent enough kernel to reproduce this and file an upstream bug report, and the conversation there led me to conclude that it's just a faulty assumption in the test (namely that the initial allocation code would need to allocate a new page, which isn't the case when the page size is 64k).

I'll just XFAIL this on power for now, and mark this a low priority on the upstream bug tracker (as I'd like the test to be fixed)

[Simon Chopin (schopin)]

Thanks Andreas for pointing me to the page size.

There's an assumption made in the test that the early allocation code will need to grow beyond the initial data page, as those extra pages would be the ones marked "[anon: glibc: loader malloc]". However, if the page size is large enough, I guess that assumption isn't valid anymore.

I'll write a patch skipping this particular assertion if the page size is 64k or above.

[Adhemerval Zanella (adhemerval-zanella)]

(In reply to Simon Chopin from comment #3)
> Thanks Andreas for pointing me to the page size.
>
> There's an assumption made in the test that the early allocation code will
> need to grow beyond the initial data page, as those extra pages would be the
> ones marked "[anon: glibc: loader malloc]". However, if the page size is
> large enough, I guess that assumption isn't valid anymore.
>
> I'll write a patch skipping this particular assertion if the page size is
> 64k or above.

I could reproduce it on a ppc64le VM, and it seems to what you described: the __minimal_malloc never issues the mmap because the initial data segment can supply the loader memory requirement. I think without a way to trigger the load mmap allocation, it would be better to just remove the 'loader malloc' check (it might be that we will need to adjust for possible different page sizes).

[Launchpad Janitor (janitor)]

This bug was fixed in the package glibc - 2.39-0ubuntu8

---------------
glibc (2.39-0ubuntu8) noble; urgency=medium

  * No-change rebuild for CVE-2024-3094

 -- Steve Langasek <email address hidden> Sat, 30 Mar 2024 07:42:05 +0000

[Adhemerval Zanella (adhemerval-zanella)]

Fixed on 2.40.