From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id A886238582AD for ; Thu, 22 Sep 2022 19:14:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A886238582AD Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x32e.google.com with SMTP id x23-20020a056830409700b00655c6dace73so6866848ott.11 for ; Thu, 22 Sep 2022 12:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date; bh=NsF4WB3I77xzfbumwTHvVYkhKJGrqUJ9vctAW+1PN6U=; b=g5AS6/qXWZlN7pkvR2DFRfWGAl2uiPp3sTCejOBct+ctu3gpW82aclEqdjrdkL+cXA XNeaq023th3XCvCZByoH+y+cbQeVvOOEUuFzRNNTKzAB6a8YSBIkVhpqoUx0Llh7+tHv ppHMXYWQjBRQ4E6ZFidDQWrg4MR0wgrs7qsFmsAQ9jl5ng5kDIQJ/BGY3Nb1sE+DOZEV nhNA+rO2bpBh5dpnZfU/EWeW9MgfKgvFR1HihNgYt8avuv38vYi8D/FU4eYb9QZloerE nBOCrgHhWD6Fk/doPJcnJrbtp5i56s8lw0AqpjYP6G83c4mOYhvskHvGcFywUiSlhNJX qsrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=NsF4WB3I77xzfbumwTHvVYkhKJGrqUJ9vctAW+1PN6U=; b=lXPqHD4lMTHOEIdJRbZx1eNNIsNnHjY5IEZLUuGyHBhhPD0P9uodO4raDv7kH0eIlu PhMylLEK6zXQg4Y+/ETEkrnzXGD4syTqtZnVlWz9ZappvvuyuOOd/XCoRK76iBsuQ2c0 s2k4vA762HEqmw8cIqBB+a6xIf1aq+KI3eqYNvvQNh1tojuZxZRVXwhBesUlwqyuDMaT hbIP1hPl5X5JyM0rqSLTEOsFo566f/RkAfrhEQHTsWjzhKdMBTC+wNO3Y4Z5gQOVPCuK k3DQVSlxnewheQyOWMrdCtj5G7wwqI5eSnWl8thBJeUwUC77P/Hq0kAHnr9IIzB9hJwH fxgw== X-Gm-Message-State: ACrzQf3k86iGKh9weHnSioL7YBi4MOvbq3XTeoxo9wuAmLFLX+qkE3jH cBJUF9TWmLTh2+DKOLwupCMgAA== X-Google-Smtp-Source: AMsMyM6eNP1Y40rvVAVQK4RxbYmT2BYC7LYwSYyI5DOtkjPgoWu2kxoOlaTZo0XvRN+RdWuT0U/t0A== X-Received: by 2002:a9d:4905:0:b0:655:fb61:72ab with SMTP id e5-20020a9d4905000000b00655fb6172abmr2383480otf.192.1663874061972; Thu, 22 Sep 2022 12:14:21 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:c266:202e:f71c:c0e7:6b4e? ([2804:1b3:a7c1:c266:202e:f71c:c0e7:6b4e]) by smtp.gmail.com with ESMTPSA id q43-20020a056830442b00b006561d30cdc2sm3193052otv.23.2022.09.22.12.14.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Sep 2022 12:14:21 -0700 (PDT) Message-ID: <88e5f61f-253d-5e2a-a0bd-39beff55c82c@linaro.org> Date: Thu, 22 Sep 2022 16:14:19 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: posix_spawn: parent can get stuck in uninterruptible sleep if child receives SIGTSTP early enough Content-Language: en-US To: Florian Weimer Cc: Adhemerval Zanella Netto via Libc-help , Rain References: <2921668c-773e-465d-9480-0abb6f979bf9@www.fastmail.com> <7727e4de-a8da-1e6b-4d7c-68a132750996@linaro.org> <64917a2f-788b-4695-b799-63bbb8a4873f@www.fastmail.com> <87tu64w33v.fsf@oldenburg.str.redhat.com> <7c356365-34db-cc00-bb92-0e55e7a89118@linaro.org> <877d27vbdx.fsf@oldenburg.str.redhat.com> <5bcba9d3-7bdd-1855-afb7-1f9d63014842@linaro.org> <87leqbmwkl.fsf@oldenburg.str.redhat.com> <87leqb1f9j.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87leqb1f9j.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: On 22/09/22 14:38, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >> On 22/09/22 09:18, Florian Weimer wrote: >>>> Is there anything that prevents to avoid using CLONE_VFORK? The code already >>>> uses a allocated stack and do synchronizes with waitpid. >>> >>> Assuming there is a way to create a thread which gets replaced by execve >>> only (instead the whole process), this won't work because we have to >>> block all signals for the new thread (it must not be visible to >>> application code, and signal handlers must not run on it), and we can't >>> unblock those signals prior to execve. With vfork, we can unblock them >>> after changing the signal handler disposition to SIG_DFL (preventing the >>> handler execution), but per-thread signal handlers have been removed >>> from Linux. So even if we somehow could prevent the termination signal >>> from beign sent to the whole process (and not just the fake thread), we >>> still have a gap. >> >> But we already block all internal signals with internal_signal_block_all >> prior clone call and it does not use CLONE_SIGHAND on the clone call. >> Also, independently of CLONE_SIGHAND, the calling process and child still >> have distinct signal masks. Recall for posix_spawn we do not use >> CLONE_THREAD, so per-thread signal handlers does not apply here. > > This only works because we restore SIG_DFL before unblocking signals in > the new process. And that depends on a separate set of signal handlers. > >> Doing some tests, the main problem is in fact how to synchronize >> the deallocation of the stack, since without CLONE_VFORK there is no way >> to advertise on a success call when execve has been called. >> >> But I agree that even without CLONE_VFORK we still have a small window, >> between the sigprocmask and execve, that the signal might act upon the >> child. > > And that window shouldn't exist in the current implementation. But that's the main issue described in this first message, isn't? The child unblocks signals by calling sigprocmask, SIGTSTP is delivered to the child, but since clone hasn't exited due CLONE_VFORK, it remains stuck in clone until child receives SIGCONT. I think to actually fix it we need a execve/execveat where the signal mask is set atomically, so SIGTSTP is sent to the spawned process instead of the libc helper one.