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 6BC703858422 for ; Thu, 22 Sep 2022 12:18:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6BC703858422 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663849118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7dLjpBPEW5s5Tpv5IXj547NBA7abzGEVIHWCR7cxTt8=; b=GzJyKhPAvfWPMFQg8DhvTV7OEGHSrbqUiKYxaOv0qiFwF0ZHAmzY48KJMQo1ZlnAPH60FF Xe/6S+n/isPqyQYrnap1DVlAYqnEVU7uoiX1SYO5XieqWjW7cy52h25lucEal0O9xRSvKG lAkmfFL2gINinolYtDLtw3OYgY9rmI0= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-471-P3Ps4AsnMkyKCxRpUptZbg-1; Thu, 22 Sep 2022 08:18:37 -0400 X-MC-Unique: P3Ps4AsnMkyKCxRpUptZbg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 41DB23817A66; Thu, 22 Sep 2022 12:18:37 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.103]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 73C77492B05; Thu, 22 Sep 2022 12:18:36 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Netto Cc: Adhemerval Zanella Netto via Libc-help , Rain Subject: Re: posix_spawn: parent can get stuck in uninterruptible sleep if child receives SIGTSTP early enough 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> Date: Thu, 22 Sep 2022 14:18:34 +0200 In-Reply-To: <5bcba9d3-7bdd-1855-afb7-1f9d63014842@linaro.org> (Adhemerval Zanella Netto's message of "Wed, 21 Sep 2022 12:24:49 -0300") Message-ID: <87leqbmwkl.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Adhemerval Zanella Netto: > On 13/09/22 07:04, Florian Weimer wrote: >> * Adhemerval Zanella Netto: >> >>> On 22/08/22 15:21, Florian Weimer wrote: >>>> * Adhemerval Zanella Netto via Libc-help: >>>> >>>>> Right, my mistake. I understood the issue better now, although I am >>>>> still puzzled why SIGTSTP is only being triggered on sigprocmask (sing >>>>> default action is still to stop PROCESS). >>>> >>>> I think it's a maskable stop, not an unmaskable one, like SIGSTOP. >>> >>> Yeah, we do block the signal on parent (internal_signal_block_all). >>> >>>> >>>> This looks a vfork-specific bug that can't happen with fork. I don't >>>> see how to fix it in a generic fashion because we can't unblock SIGTSTP >>>> and launch the new process in an atomic fashion. >>> >>> We might ask for a new clone3 field to define the default signal mask on >>> process start (and thus omit the final sigprocmask before execve). >> >> It might already possible to fix this using io_uring. Unfortunately, I >> didn't attend the LPC presentation. > > 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. Thanks, Florian