From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EED163858C2C for ; Mon, 25 Apr 2022 09:05:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EED163858C2C Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-303-t9l-OwKKOVuNfpoY0_VoNA-1; Mon, 25 Apr 2022 05:05:51 -0400 X-MC-Unique: t9l-OwKKOVuNfpoY0_VoNA-1 Received: by mail-ed1-f72.google.com with SMTP id cn27-20020a0564020cbb00b0041b5b91adb5so8015151edb.15 for ; Mon, 25 Apr 2022 02:05:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gNyX5Ic52+/ZiyoAA+sT1TD7bYoLM+k8rRYNZ6KmWl8=; b=JS692I67rtWRXI37PMyFuLTUVEqV+yG31AWuRZBxAiEJu1Dtdan8euxky4NBu9FQFT WsuKFCndV2PF6hvtadMCzEiNum7PDK4tUGKPG17nfhcOQO9uxf28DWgIR84Tt1esc59L 8/hJM7/AECJTYBV+vgLyluI3BGZvcNXBdoBWYB1oU1ZPSW/ZkjSpa963gfBCoi0I5gie yni0C9o4dxT16RlKGzu+Bw7A6fxezPzTtD6LLjre3AZkmCchxd1cA+4AHVURE6j9tvQg W3TiveLGbJxTAg0N7rQVbak45SO4UMQmqefLhqqY5UsDA9KutuOKghcAK0tRvkarU5ve B8VQ== X-Gm-Message-State: AOAM533COoOT6Oiq59XmsMcFXnjJ9o6BX6dZHjCF9oqisfl6cuLiI7oi 9I+VnlQt535GyCDhhp+3eQQUXdPOLxF/YtMKUvv1BSl20cklwt+kmnuu6GeU0Bx9wnIKzzcT3cG CLvw64OyGFW/fvVfFWup16PvHFBj0yXY4uL+A X-Received: by 2002:a05:6402:4008:b0:425:e769:c001 with SMTP id d8-20020a056402400800b00425e769c001mr4061171eda.34.1650877549989; Mon, 25 Apr 2022 02:05:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6fdi0fBIOyqUjzw3NELKnJNwZUsPtBGCPiaIbbnivu4G5Wz2VjKwWKJeZ9URESypE16zQpvFiV4I+QP/kcKU= X-Received: by 2002:a05:6402:4008:b0:425:e769:c001 with SMTP id d8-20020a056402400800b00425e769c001mr4061155eda.34.1650877549750; Mon, 25 Apr 2022 02:05:49 -0700 (PDT) MIME-Version: 1.0 References: <20220421123144.3796982-1-arjun@redhat.com> <1bdc5a3c-4257-a69d-174d-c457f362ff03@linaro.org> In-Reply-To: <1bdc5a3c-4257-a69d-174d-c457f362ff03@linaro.org> From: Arjun Shankar Date: Mon, 25 Apr 2022 11:05:38 +0200 Message-ID: Subject: Re: [PATCH] Fix deadlock when pthread_atfork handler calls pthread_atfork or dlclose To: Adhemerval Zanella Cc: libc-alpha@sourceware.org, Florian Weimer X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 25 Apr 2022 09:05:58 -0000 Hi Adhemerval, > I sent a proposed fix sometime ago [1] which similar strategy, the > difference it uses a linked list (there is no need to booking the last > index used since newer elements are added on the start of the list). > Not sure which would be best strategy. > > [1] https://sourceware.org/pipermail/libc-alpha/2019-August/105590.html Thanks. I wasn't aware of this patch until you pointed it out. I was able to (with some changes) apply it to master. I then did two things: 1. I added your test on top of my own patch and tested it. It caught a programming error in my run_postfork_handlers where dlclose'ing after the fork led to a crash. I fixed that and could post the result as a v2. 2. Separately, I added my test on top of your patch in master and tested that combination as well. The test failed and the reason in this case seems like it's simply to do with the lack of a clear specification of what should happen to atfork handlers registered by atfork handlers. When I wrote my patch and corresponding test, I figured that since running a prepare handler registered by another prepare handler would go against the specification of reverse order execution of prepare handlers, the parent/child handlers that pair with the skipped prepare handler should *also* be skipped. Thus, all handlers registered by other handlers *during* a fork are skipped from execution during *that* particular fork. I see two separate questions: 1. Do we keep the dynarray or switch to a linked list? 2. What about execution order when it comes to handlers registered by handlers? It seems reasonable to not execute prepare handlers that get registered by handlers during the fork because that violates the specification: execution in reverse order of registration. But the execution of parent/child handlers registered by handlers seems a bit more of an open question. In my case, I went with skipping them simply because any corresponding prepare would also get skipped by default. Cheers, Arjun