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 32ABA3858D35 for ; Mon, 22 May 2023 10:41:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 32ABA3858D35 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=1684752075; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O+piCV3OWV2JM/AtdZgqTkbvnyrBWCFhltIeg4HSbpk=; b=JQNP7N1wEgUEg0wapg1sCfprkkqB/MQTRt9LzK3wBc6LnSVpPr/zWUdMU+eiS1NvSR95mT 4k7ds8MN84sZbNyxwcuNOb6z14dQ62dgC5uU5kFWOqIKzD5LxdUhckTKkZJhJGko4+bjyZ +QDhByPaRwK+IUWUo6YBkH+BIyRdgvo= 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-13-IzPAQ5_YNeGxvi4TMLoo4A-1; Mon, 22 May 2023 06:41:12 -0400 X-MC-Unique: IzPAQ5_YNeGxvi4TMLoo4A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 416781C01512; Mon, 22 May 2023 10:41:12 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.195.128]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 30CC8407DEC0; Mon, 22 May 2023 10:41:10 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org, Luca Boccassi , Philip Withnall Subject: Re: [PATCH v4 1/3] posix: Add pidfd_spawn and pidfd_spawnp (BZ# 30349) References: <20230517173516.1988283-1-adhemerval.zanella@linaro.org> <20230517173516.1988283-2-adhemerval.zanella@linaro.org> Date: Mon, 22 May 2023 12:41:09 +0200 In-Reply-To: <20230517173516.1988283-2-adhemerval.zanella@linaro.org> (Adhemerval Zanella's message of "Wed, 17 May 2023 14:35:14 -0300") Message-ID: <87zg5w4piy.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: > Returning a pidfd allows a process to keep a race-free handle to a child > process, otherwise the caller will need to either use pidfd_open (which > still might be subject to TOCTOU) or keep using the old racy interface. > > The implementation makes sure that kernel must support the complete > pidfd interface, meaning that waitid (P_PIDFD) should be supported > (added on Linux 5.4). It ensure that non racy workaround is required > (such as reading procfs fdinfo pid to use along with old wait interfaces)= . > If kernel does not have the required support the interface returns ENOSY= S. =E2=80=9CIt avoids workarounds with race conditions=E2=80=9D? > These interfaces are similar to the posix_spawn and posix_spawnp, with > the only different diferent being it returns a process file descriptor > (int) instead of process ID (pid_t). Their prototypes are: > > int pidfd_spawn (int *restrict pidfd, > =09=09 const char *restrict file, > =09=09 const posix_spawn_file_actions_t *restrict facts, > =09=09 const posix_spawnattr_t *restrict attrp, > =09=09 char *const argv[restrict], > =09=09 char *const envp[restrict]) > > int pidfd_spawnp (int *restrict pidfd, > =09=09 const char *restrict path, > =09=09 const posix_spawn_file_actions_t *restrict facts, > =09=09 const posix_spawnattr_t *restrict attrp, > =09=09 char *const argv[restrict_arr], > =09=09 char *const envp[restrict_arr]); Should we return the pid_t value as we.. > A new symbol is used instead of a posix_spawn extension to avoid possible > issue with language bindings that might track the return argument > lifetime. Although, on Linux pid_t and int are interchangeable, POSIX > only state that pid_t should be a signed interger. > > Both symbols reuse the posix_spawn posix_spawn_file_actions_t and > posix_spawnattr_t, to void rehash posix_spawn API or add a new one. > It also mean that both interfaces support the same attribute and > file actions, and a new flag or file actions on posix_spawn is also > added automatically for pidfd_spawn. Same question as with pidfd_fork: how does this interact with SIGCHLD, and can the PID be used with waitpid? > diff --git a/posix/spawn.h b/posix/spawn.h > index 0a6a070523..2e20991627 100644 > --- a/posix/spawn.h > +++ b/posix/spawn.h > @@ -229,6 +229,8 @@ posix_spawn_file_actions_addtcsetpgrp_np (posix_spawn= _file_actions_t *, > =20 > #endif /* __USE_MISC */ > =20 > +#include > + > __END_DECLS Nested __BEGIN_DECLS. You should probably move the #include after __END_DECLS. > diff --git a/sysdeps/unix/sysv/linux/clone-pidfd-support.c b/sysdeps/unix= /sysv/linux/clone-pidfd-support.c > new file mode 100644 > index 0000000000..4bf2317c17 > --- /dev/null > +++ b/sysdeps/unix/sysv/linux/clone-pidfd-support.c > + Also tThe waitid is a cancellation entrypoint, so issue the sys= call > +=09 directly. */ Typo: =E2=80=9CtThe=E2=80=9D Thanks, Florian