glibc 2.34 - Hard ABI freeze effective immediately.

[Adhemerval Zanella]

On 26/07/2021 10:00, Carlos O'Donell wrote:
> On 7/23/21 9:13 AM, Adhemerval Zanella wrote:
>>
>>
>> On 23/07/2021 02:13, Carlos O'Donell wrote:
>>> On 7/22/21 9:24 AM, Adhemerval Zanella wrote:
>>>> Do we still have time for the posix_spawnattr_tcsetpgrp_np [1]? I think the
>>>> code should be simple enough.
>>>>
>>>> [1] https://patchwork.sourceware.org/project/glibc/patch/20210617175751.1619846-2-adhemerval.zanella@linaro.org/
>>> No, I do not think we have enough time, or to be more precise I want 
>>> to review the use case, ask Godmar to verify that API does what is
>>> required, and *then* include it in the release.
>>
>> Fair enough.
>>
>>>
>>> I want to use the remaining 6 days to fix bugs without any further
>>> ABI work.
>>>
>>> I would like to see:
>>> - LD_AUDIT bugs fixed.
>>> - pthread condvar bugs fixed.
>>> - C.UTF-8 added as supported (resolved Florian's last comment about U+FFFD usage).
>>>
>>
>> I would like to add some extra time64 tests changes [1].  They do not touch
>> the code, besides libsupport.
>>
>> [1] https://patchwork.sourceware.org/project/glibc/list/?series=2510
> 
> Absolutely, we should review this and merge it.
> 
> I see the 32-bit builder failed this series:
> NONE -> FAIL : socket/tst-socket-timestamp
> NONE -> FAIL : socket/tst-socket-timestamp-time64

Carlos, this again does seems another container runtime filtering issue.
The non 64-bit shows the following log: 

../sysdeps/unix/sysv/linux/tst-socket-timestamp.c:156: numeric comparison failure
   left: 1 (0x1); from: errno
  right: 9 (0x9); from: EBADF
../sysdeps/unix/sysv/linux/tst-socket-timestamp.c:94: numeric comparison failure
   left: -1 (0xffffffff); from: r
  right: 4 (0x4); from: sizeof (int)
../sysdeps/unix/sysv/linux/tst-socket-timestamp.c:95: numeric comparison failure
   left: -84852 (0xfffeb48c); from: msg
  right: 0 (0x0); from: exp_msg
Didn't expect signal from child: got `Segmentation fault'

The first issue on line 156 is:

155   TEST_COMPARE (recvmmsg (-1, NULL, 0, 0, NULL), -1);
156   TEST_COMPARE (errno, EBADF);

It means that a recvmmsg syscall is returning EPERM instead of EBADF
for an *invalid* file descriptor, even with the input size is set to
0 (which should not trigger any EFAULT from the kernel).

The another issue is that the recvmsg/recvmmsg is failing for some
reason:

 85   int r;
 86   if (use_multi_call)
 87     {
 88       r = recvmmsg (s, &mmhdr, 1, 0, NULL);
 89       if (r >= 0)
 90         r = mmhdr.msg_len;
 91     }
 92   else
 93     r = recvmsg (s, &mmhdr.msg_hdr, 0);
 94   TEST_COMPARE (r, sizeof (int));
 95   TEST_COMPARE (msg, exp_msg);

I tested both 32-bit and 64-bit tests on multiple kernel (3.10, 4.4, 4.15,
and 5.11) without any issue, but all without any container runtime.

The tests creates and binds on a random TCP/IP port, so it *might* be the
case. I think I can use a socketpair using AF_UNIX for this tests (I need
to verify if SO_TIMESTAMPNS are set for such case), but I will need some
strace output to understand exactly why it is failing on the buildbot.