From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 822121F4B4 for ; Sun, 20 Sep 2020 20:42:30 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 570823851C2C; Sun, 20 Sep 2020 20:42:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 570823851C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1600634549; bh=mLfMVJhi+Fg6s606d/w4UlPHyVw1vBgxQ19s7EvR4PE=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=PjGom9wTcoQAbb94GiUsBYxt2MiWbyvocN4WPqlCsWBpWrfuNWLBucXtDh6Jfltfv 2f8fd/bELV3OoOkpO1TSDuYpTBQtzlcSQfzgNftBf4cn8vjfruPOH6afM9Mizq4Pcd 48ZO5icePhB54o/1lln42bkpbLq9eujvXRspJA0c= Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) by sourceware.org (Postfix) with ESMTPS id 435B4385700C for ; Sun, 20 Sep 2020 20:42:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 435B4385700C Received: by mail-yb1-xb41.google.com with SMTP id k2so8793428ybp.7 for ; Sun, 20 Sep 2020 13:42:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mLfMVJhi+Fg6s606d/w4UlPHyVw1vBgxQ19s7EvR4PE=; b=nXQd1tP9aWrBOqu8qY22nk3H8KsCJVPjqBrJNyrSuzf+t3e2RIHSsmxtpmaylAxl6A 36qHWxG6nor7Bsb4o9kpJJCE2r5PTxoPt3kS2ZNTBoOZ0VOv1oR+HwWcDi5nchwNv+HS vZTxDokWgxpRw8k3xf6P6uibvqXkxZ+PQseRVtztnM/Gnep515GIF9wwf81iOlny2TdX 69DzQWYm5/nsrTycMpqrI1E7X49LcmbaU6CavXsC5T1Y+WPgzWTtQ11eZue65iHo7OhC 9CtC1RiIgPuFrbMWhuQawJffBMXb+OcMmcBAz5BLBgagsefaviUNIyLDnOOeY3DigjnJ HzFA== X-Gm-Message-State: AOAM530jTQdc+0tqjgXxGra3m+xGHB121BFaVP5ZZ/veIpDpuj8rbbTi rQDaRKKi5TYq/gXpJfsT06By/XN5mj9PLgrBu+MU9g== X-Google-Smtp-Source: ABdhPJwDKnjm7CKw9crfVzrYp+J1X9e1lnUfihfOL3MQ/ZW3fLeRPNDkEKwVJQzwVJb1rN5hLhs3+/oSmnGmvXvf5X0= X-Received: by 2002:a25:b8cb:: with SMTP id g11mr27897256ybm.203.1600634546269; Sun, 20 Sep 2020 13:42:26 -0700 (PDT) MIME-Version: 1.0 References: <20200920095750.396908-1-vitalybuka@google.com> <20200920120957.852821-1-vitalybuka@google.com> In-Reply-To: <20200920120957.852821-1-vitalybuka@google.com> Date: Sun, 20 Sep 2020 13:41:58 -0700 Message-ID: Subject: Re: [PATCH] stdlib: Fix data race in __run_exit_handlers To: Vitaly Buka Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul Pluzhnikov via Libc-alpha Reply-To: Paul Pluzhnikov Cc: GLIBC Devel Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Sun, Sep 20, 2020 at 5:10 AM Vitaly Buka via Libc-alpha wrote: > +static void * > +threadfunc (void *unused) > +{ > + for (; done < 1e6;) > + { > + if (added < done + 100) > + { > + __cxa_atexit (&atexitcb, (void *)(++added), __dso_handle); Isn't there a data race on "added" here (in addition to a data race on "done")? What prevents two threads from observing "added == 100" at the same time and adding two calls with value of 101, which would later trigger abort() in exitcb()? > + /* With default 8MiB Linux stack size, creating 1024 threads can cause > + VM exhausiton on 32-bit machines. Reduce stack size of each thread to > + 128KiB for a maximum required VM size of 128MiB. */ This comment is far removed from the computation of kStacksize (and the name violates the naming conventions used here). I suggest: size_t stack_size = 128 << 10; /* 128KiB */ if (stack_size < PTHREAD_STACK_MIN) stack_size = PTHREAD_STACK_MIN; Also, I suspect that 32KiB would be more than enough for stack size here. > + for (i = 0; i < kNumThreads; ++i) Since kNumThreads isn't used anywhere else, I suggest making it a local: const int num_threads = 50; -- Paul Pluzhnikov