Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp1949511rdb; Thu, 7 Dec 2023 13:29:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IGzb246SrCGU3ty5FF9fR26AG/ehkpWqh/nfbntH9xMa6frQOAcclxQ/l9reTSis6Z61GVr X-Received: by 2002:a17:903:1d2:b0:1d0:6ffd:adff with SMTP id e18-20020a17090301d200b001d06ffdadffmr3511586plh.102.1701984570654; Thu, 07 Dec 2023 13:29:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701984570; cv=none; d=google.com; s=arc-20160816; b=TktgKDlXCnF//SbWWRX2yEDqHVKwwCsqdigVtGL5L+0sv26KqxgWG0+pgSHO+A2IR0 jFlHluIiJDmsbVKOQr13uq5OVP7su0VVVqdKvXXmtToBrGSj8NzvkqwBAc9nj2lHR4mw Dyzv3WmYVU/5U5vBoBtt38XNd4CdcPJytZAgohn6rNSBA+LXnqPVgcfXPK3dJPUYY+2d 4pRa+WYjUEeb4525t1aJtWAh6gT3PuCMqLCM8+Q3F7HKHXTahmuMB/+4Cm/XZD8PzPJF CI3XKd8oC+ZA2LHBWVbptk8eWF1fwMY0C0IWyocbg3+Hhf3W30pKIGpFIcZocP9wox6o kUNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=G5lXlL2DsVSY8SjWlaqAusQX5/OBgbhuTsvtPXETVI4=; fh=LhvObmnrxjRmjQWhIXY2wpwX8dtHWidFP9kHDR6q7HQ=; b=p09F5AIkdEHbId8RPKXXgUH6lguTz/FfL6pqbBJdCwTDR764wqJTtH0u/yImOmAtZN btmeWbN5vSWOMdrNPXbZBkQJq/W6ckbBJ1jIf1kbJyXWFy746VyVdjQFqOJJ9k5KJ9v0 ZtYJkAy2kt8WG70eRyk7wXOwrCM3NFYNnOG5uf08l94CD350T7YsjKTu3v30xKxalRvU F+WFHGi3ttXyp48BGV/EMqBrz/Hq6e+dwNgXq3744EqnayTzPrANTktVh4EIMvUKctUa 8DscA8oLd0VT/Sg6csOM/AmOuv0zgcOKfpYuaNdj38W5Siyr3V4mbhSrwjqxVRVY5SWm bqlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YdAxYA+E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id t12-20020a170902bc4c00b001d087c0f814si377726plz.56.2023.12.07.13.29.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 13:29:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YdAxYA+E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 1F8578521340; Thu, 7 Dec 2023 13:29:27 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235832AbjLGV3E (ORCPT + 99 others); Thu, 7 Dec 2023 16:29:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235810AbjLGV2Y (ORCPT ); Thu, 7 Dec 2023 16:28:24 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A82362126 for ; Thu, 7 Dec 2023 13:25:40 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15240C433CC; Thu, 7 Dec 2023 21:25:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701984315; bh=YaZTLucbXUWiTUu4ZO//do5mro1EpRuUKJNhwZYZyPw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YdAxYA+EeNyu7dUv+IRTk8zJHh9KLM672+XJ7jpuEtThS6zfCTI3ANCa3/dWlAyad LUFegPgGXaSaGie9FCRbKhkTRG0O8jkxlJ/INEAwB6RH1wXjf1rYbDbjEvfyI46TvY H2mChOR+2VWzt6u8hVb9eEhU8KM0kVhU0m0iv06jCCul2W5q8IZJi8z4osKMyynxoN G5I02OijBORh6p1rFOjgnaGjyZWdin5pPaH0ehw2ORdAN4bl2pva8cMV0cA7xS1l89 b4HfU3IB3Rvodibolr3RCSjicIDtQi+roEsAcCcoOK2QRO1cKESYSK+/pj0nkM6KlB +wrdrhd5q1UbQ== Date: Thu, 7 Dec 2023 22:25:09 +0100 From: Christian Brauner To: Tycho Andersen , Oleg Nesterov Cc: "Eric W . Biederman" , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Tycho Andersen , Jan Kara , linux-fsdevel@vger.kernel.org, Joel Fernandes Subject: Re: [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Message-ID: <20231207-avancieren-unbezahlbar-9258f45ec3ec@brauner> References: <20231130163946.277502-1-tycho@tycho.pizza> <20231130173938.GA21808@redhat.com> <20231207-weither-autopilot-8daee206e6c5@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231207-weither-autopilot-8daee206e6c5@brauner> X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 07 Dec 2023 13:29:27 -0800 (PST) > If these concerns are correct So, ok. I misremebered this. The scenario I had been thinking of is basically the following. We have a thread-group with thread-group leader 1234 and a thread with 4567 in that thread-group. Assume current thread-group leader is tsk1 and the non-thread-group leader is tsk2. tsk1 uses struct pid *tg_pid and tsk2 uses struct pid *t_pid. The struct pids look like this after creation of both thread-group leader tsk1 and thread tsk2: TGID 1234 TID 4567 tg_pid[PIDTYPE_PID] = tsk1 t_pid[PIDTYPE_PID] = tsk2 tg_pid[PIDTYPE_TGID] = tsk1 t_pid[PIDTYPE_TGID] = NULL IOW, tsk2's struct pid has never been used as a thread-group leader and thus PIDTYPE_TGID is NULL. Now assume someone does create pidfds for tsk1 and for tsk2: tg_pidfd = pidfd_open(tsk1) t_pidfd = pidfd_open(tsk2) -> tg_pidfd->private_data = tg_pid -> t_pidfd->private_data = t_pid So we stash away struct pid *tg_pid for a pidfd_open() on tsk1 and we stash away struct pid *t_pid for a pidfd_open() on tsk2. If we wait on that task via P_PIDFD we get: /* waiting through pidfd */ waitid(P_PIDFD, tg_pidfd) waitid(P_PIDFD, t_pidfd) tg_pid[PIDTYPE_TGID] == tsk1 t_pid[PIDTYPE_TGID] == NULL => succeeds => fails Because struct pid *tg_pid is used a thread-group leader struct pid we can wait on that tsk1. But we can't via the non-thread-group leader pidfd because the struct pid *t_pid has never been used as a thread-group leader. Now assume, t_pid exec's and the struct pids are transfered. IIRC, we get: tg_pid[PIDTYPE_PID] = tsk2 t_pid[PIDTYPE_PID] = tsk1 tg_pid[PIDTYPE_TGID] = tsk2 t_pid[PIDTYPE_TGID] = NULL If we wait on that task via P_PIDFD we get: /* waiting through pidfd */ waitid(P_PIDFD, tg_pidfd) waitid(P_PIDFD, t_pid) tg_pid[PIDTYPE_TGID] == tsk2 t_pid[PIDTYPE_TGID] == NULL => succeeds => fails Which is what we want. So effectively this should all work and I misremembered the struct pid linkage. So afaict we don't even have a problem here which is great.