From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=rF+O=6J=google.com=vitalybuka@sourceware.org>
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835])
	by sourceware.org (Postfix) with ESMTPS id 131293858D35
	for <libc-alpha@sourceware.org>; Mon, 13 Feb 2023 01:55:07 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 131293858D35
Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com
Received: by mail-qt1-x835.google.com with SMTP id cr22so12372951qtb.10
        for <libc-alpha@sourceware.org>; Sun, 12 Feb 2023 17:55:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=vZvb6ShHPJ+D85GzkbUN1Zbi/JbVKXc1l13LoF6XMEA=;
        b=UGVujHn/y1SNtBbpE3Q7wONq7/GShG32oW16sz7eAed5AVVnhVUuIK1aliySqKatix
         nWms/UHKcfgmDkB4c341s+UFZM3ovVJ4B5oLJ4bPFU4/NwCS9cOhRVkeE5XdHpIaFoG8
         ttYuHS+RomGanmzA98iQLwwenrzqu9OppOBt6jXyOG8hubV7JjQlCkQeWuSImDhr+F5d
         TKx1s4NWiYiqE1ZlWfuxtgxISZ+gOmKTxnxBoGQUv/1d/xv/lu9JZDuSXc/VuviFZLtw
         Ba0e3F6A6qOieJr+wQyvrIjGlbxprYp8sUuj8uyUG2Wm5JWJLJXFd9LeYLSzXev70+Vx
         7tcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=vZvb6ShHPJ+D85GzkbUN1Zbi/JbVKXc1l13LoF6XMEA=;
        b=H+Sww6GAu9PkzRjpXNCdCRtQGwZD189UbRIg0yeD1UnDldT6lmsANu051Jr0Te+y0o
         p2muGNNS9IyJg1ZQEx6MPioDO7nbge28w8q82mVLBr63AjQ9A2HONtlc0TahtfhU1Io0
         XO9ye0RregbkBoqpc7FAA6rWeKux/qSra5rd4wiNO/Rg1pjtQ8OM1aXLHyDmIErSVenl
         TmCoVlBVmdLqU/mYwmtP7EF7vanPdFrfT8Sk2/NMreAoMpvSVtInT4EnTsiyHKiVMHNy
         QnbAu/7yhHhG970OMPCNmsxFD99yXTWzG+LiX8msOjK09isrC/2jc40SpZEJ+zQ6K2AD
         aadQ==
X-Gm-Message-State: AO0yUKXFwRxvfgjjGs1smmSLdQ2e2K2pD+vyVUZYz0gb4S4lW6WaHdh/
	I6XTHYHTFjhslVy5fAJAgJAJd2CHC9s8AXxPjb2kkpfd398gMg7Dwmg=
X-Google-Smtp-Source: AK7set9ZcpPIAik4enYnsWgO7U3vszRCUJqyC467HtNWphKrSKT614+XUY1nTODnBLqUoahQomoPj8+AQVOh1bkKbGY=
X-Received: by 2002:a05:622a:54c:b0:3b9:b9e1:3335 with SMTP id
 m12-20020a05622a054c00b003b9b9e13335mr2927647qtx.314.1676253306232; Sun, 12
 Feb 2023 17:55:06 -0800 (PST)
MIME-Version: 1.0
References: <0a4a8828-ed9a-66d4-f65c-f2f386768bdb@prevas.dk>
In-Reply-To: <0a4a8828-ed9a-66d4-f65c-f2f386768bdb@prevas.dk>
From: Vitaly Buka <vitalybuka@google.com>
Date: Sun, 12 Feb 2023 17:54:29 -0800
Message-ID: <CAPjTjwswS5a3p7z4O4eBT+-ERsvY4LLuMogRL2-6j9L0Z+G=MQ@mail.gmail.com>
Subject: Re: commit 16adc58e73f3 (stdlib: Fix data race in __run_exit_handlers
 [BZ #27749])
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Cc: libc-alpha@sourceware.org, 
	Adhemerval Zanella <adhemerval.zanella@linaro.org>
Content-Type: multipart/alternative; boundary="000000000000df85a105f48b226b"
X-Spam-Status: No, score=-20.4 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

--000000000000df85a105f48b226b
Content-Type: text/plain; charset="UTF-8"

Not sure how this happened, but it was not on my patch
https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html

On Sun, 12 Feb 2023 at 15:44, Rasmus Villemoes <rasmus.villemoes@prevas.dk>
wrote:

> I think the commit in $subject is broken. I was browsing through the
> atexit handling code and stumbled on something which is always a code
> smell, namely the pattern
>
>   if (whatever)
>     continue;
>
> at the end of a loop.
>
> And indeed, since we no longer jump back to the outer loop and refetch
> the list head, one can observe a change in behavior. This program:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> void h(void)
> {
>         printf("third: %s()\n", __func__);
> }
> void j(void)
> {
>         printf("second: %s()\n", __func__);
> }
>
> void g(void)
> {
>         printf("first: %s()\n", __func__);
>         atexit(h);
>         atexit(j);
> }
> void f(void) {
>         static int c;
>         printf("%s: %d\n", __func__, ++c);
> }
>
> int main(int argc, char *argv[])
> {
>         int i;
>
>         /*
>          * Stuff the "struct exit_function_list" with dummy callbacks;
>          * 30 may need to be adjusted depending on how many atexit()
>          * registrations libc itself does.
>          */
>         for (i = 0; i < 30; ++i)
>                 atexit(f);
>
>         /* Register one more, to fill the last slot in struct
> exit_function_list. */
>         atexit(g);
>
>         return 0;
> }
>
> used to print
>
> first: g()
> second: j()
> third: h()
> f: 1
> ...
> f: 30
>
> but now it instead prints
>
> first: g()
> third: h()
> f: 1
> ...
> f: 30
> second: j()
>
>
> Rasmus
>

--000000000000df85a105f48b226b--