unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
To: Carlos O'Donell <carlos@redhat.com>,
	libc-alpha <libc-alpha@sourceware.org>,
	Siddhesh Poyarekar <siddhesh@redhat.com>,
	DJ Delorie <dj@redhat.com>
Subject: Re: glibc 2.34 - Hard ABI freeze effective immediately.
Date: Mon, 26 Jul 2021 15:31:25 -0300	[thread overview]
Message-ID: <2ae406ed-515f-0257-476c-335d65071afa@linaro.org> (raw)
In-Reply-To: <8786a45d-c80d-0a28-1885-c2c7c28efa4a@redhat.com>



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.


  parent reply	other threads:[~2021-07-26 18:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05  2:43 glibc 2.34 - Slushy freeze effective immediately Carlos O'Donell via Libc-alpha
2021-07-19  2:15 ` glibc 2.34 - Hard ABI " Carlos O'Donell via Libc-alpha
2021-07-19 13:51   ` Florian Weimer via Libc-alpha
2021-07-19 14:13     ` Adhemerval Zanella via Libc-alpha
2021-07-19 14:30       ` Florian Weimer via Libc-alpha
2021-07-22 12:28         ` Carlos O'Donell via Libc-alpha
2021-07-22 13:02           ` Carlos O'Donell via Libc-alpha
2021-07-22 17:56             ` Florian Weimer via Libc-alpha
2021-07-22 12:31   ` Carlos O'Donell via Libc-alpha
2021-07-22 13:24     ` Adhemerval Zanella via Libc-alpha
2021-07-23  5:13       ` Carlos O'Donell via Libc-alpha
2021-07-23  5:53         ` Siddhesh Poyarekar via Libc-alpha
2021-07-26 14:22           ` Carlos O'Donell via Libc-alpha
2021-07-26 14:28             ` Samuel Thibault
2021-07-26 14:37               ` Siddhesh Poyarekar
2021-07-26 14:45                 ` Samuel Thibault
2021-07-23 13:13         ` Adhemerval Zanella via Libc-alpha
2021-07-26 13:00           ` Carlos O'Donell via Libc-alpha
2021-07-26 13:13             ` Adhemerval Zanella via Libc-alpha
2021-07-26 18:31             ` Adhemerval Zanella via Libc-alpha [this message]
2021-07-22 13:51     ` Siddhesh Poyarekar
2021-07-25 19:46   ` H.J. Lu via Libc-alpha
2021-07-25 21:54     ` Florian Weimer via Libc-alpha
2021-07-25 22:07       ` H.J. Lu via Libc-alpha
2021-07-25 22:14         ` Florian Weimer via Libc-alpha
2021-07-26  7:19         ` Andreas Schwab
2021-07-26 14:29     ` Carlos O'Donell via Libc-alpha
2021-07-26 14:32       ` H.J. Lu via Libc-alpha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ae406ed-515f-0257-476c-335d65071afa@linaro.org \
    --to=libc-alpha@sourceware.org \
    --cc=adhemerval.zanella@linaro.org \
    --cc=carlos@redhat.com \
    --cc=dj@redhat.com \
    --cc=siddhesh@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).