From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91215CF6499 for ; Mon, 30 Sep 2024 12:34:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7D938002A; Mon, 30 Sep 2024 08:34:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2D8E80017; Mon, 30 Sep 2024 08:34:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF56D8002A; Mon, 30 Sep 2024 08:34:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9131580017 for ; Mon, 30 Sep 2024 08:34:41 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 45A771C4D1C for ; Mon, 30 Sep 2024 12:34:41 +0000 (UTC) X-FDA: 82621348362.01.64CAA23 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id 98348C0017 for ; Mon, 30 Sep 2024 12:34:39 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XX55u6TP; spf=pass (imf22.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727699616; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CEcwHpmnOP975TGSxGapESzapy2XLebu/MdC4+mg5IE=; b=n7kbUHUp8CNVhOSiAVzN33yl+CQ/whJJ58LOu6SQiCaKf1x+tHvPBpgrVmJXDu9q9Pu43w jG4fpcjuGxk3ii81cBtKartCD2OQTLkhdmV3l508l93nMaTb10F3vTB2XqS9+mMFZFS3NJ DnLLsDPkTemgmnOAhNeTl0P51SHZLJs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XX55u6TP; spf=pass (imf22.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727699616; a=rsa-sha256; cv=none; b=0Hg70F5WFpDHyjHtV7u/rJMQ7xnsJD6YcQx9E3N4q4CgPjafy0pH1f9eD0JcwWtJuFqk4r czapQAYoMQmmBIVeEvFBYKjIvGtJu9Wj/W9ZVodxB2qSw3mHWLvY3PZZvj61NMqDEdE1Fp C8JOTzAcIH40AQRiLH6QVSwQ5s3iZzo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 893DD5C4671; Mon, 30 Sep 2024 12:34:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 580A2C4CEC7; Mon, 30 Sep 2024 12:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727699678; bh=QIG50gsAuDNEdAD4sYdmyP9U9mIQ+FPqmqNXI/RmpE4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XX55u6TPb7v1ucI75GB0Fgvo0jazhfo5ge0LACwOmkf8sLGc2lCqH/17jcSJMT1Yg /vqJ2u1yN8ATiSCDVLNWzAl+2ydsx2NA96Qx0ujDXI+D4OZ7xAuAkguamoiN1CmyOL x1FJ6m1igOWyLxm8kcss9g2XRsBAwKO26K3znpgxiHbO+lel1ADtgU4jvg7JWkUA9h 1cH/WDYN6fP6cfCj4bCtVBgGugFFXwpZDCE53i0qkc8dz9xV72mPzpRJ3QOH/A4Wwm xd/tnsbhTs/kzncbTOSqqGq/+gL4H0vrcbakHA4Hv+HqNYu67QPKXmAvl4pAF8wyk1 qrvNtXUe8m99w== Date: Mon, 30 Sep 2024 14:34:33 +0200 From: Christian Brauner To: Lorenzo Stoakes Cc: Florian Weimer , Christian Brauner , Shuah Khan , "Liam R . Howlett" , Suren Baghdasaryan , Vlastimil Babka , pedro.falcato@gmail.com, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/3] introduce PIDFD_SELF Message-ID: <20240930-verbiegen-zinspolitik-cafb730c3c84@brauner> References: <87ttdxl9ch.fsf@oldenburg.str.redhat.com> <42df57ac-d89c-4111-a04d-290dd2197573@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42df57ac-d89c-4111-a04d-290dd2197573@lucifer.local> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 98348C0017 X-Stat-Signature: cq3xrf9anbg8gmxf1b4i9kkgt6pdf4d7 X-HE-Tag: 1727699679-114241 X-HE-Meta: U2FsdGVkX19GTl/gnYzpW0iHptjQlTBV2WopyEgB6hP6tK9/OHgkSRPIRE6KtyFRi/eYzDiFKQAzfznZGtWS37eoyoxDxIMxx5vd2/WtRO+eS8CbFMezZ70B6zn730Egwl/oKynVnhNLbxGEjLUGArzswdqO36K9Kzfvm0gZd4XdRy7WOjGqqOKYLDnN6w4yKyScgawmmP9YUrdDv9CTykUA3mPlL4mqrhegEyMpxVkvqbPXyiP85ntupSn4O93f5oIUUeb4f2Kr+gssv+NupSbof7gy0tnJHNI5aYCflOn/I/vIF7F5yFSk6xo/AMUMLO2oVy4mL23NNHlnzK1s2JALUk2+ERfcnBvQbMR1jSsZxcwusICCQ8JPtAPsYpynXSlqlXi701ScUT2KudNdV5lxhW4UJBFFZ1DeDtw7+uOL9NGYw2ieXmd0ijy8ta9MfuCm83MrfaoI6XLj64/zCOhzF4C7Un4e1n1bzTO+b7ZSUMprQCvprHKDnyikwcL+ECR71EgbgHxU4bEREFxUsmlTGNT3ml/AK1kGTgRUUsFlvuyCAA8g/yv3TPiY9DzlVetJCWb/88d7vPleRfKNHsf7b3WB9pkjsWD/2ksQsSVHzBesNw9XwbhcZaF8BxDYWHwnqNjpaDAl6uw2s4BrpL/jrS3MVicWalp2nwo/9SErHr/FSBPEwqWAu+U5Mhf83ieHthiBSVYL/xugEkcdoW4kQMp8RCgP725lH6rG9xjAbiWc0eipVo48sWD9NgBHa4Gzql/B9+PcT8u3iVk1kKOl3wVOWbkutaKHauZ15om2U49MT+undrqF1ldMUvAer3Qsf9iXpQurrkF6Oz9agS0kFOtEY3AK4STZIo3lw+8DpiUaBdXQppzfqztMI64/URs/5h4qSJXPnZSiuOFoRt3+m9/+0bD6zBX5sRh1eF/St3xJNyM7o6PB9A/tpJSTIVyHZGi1eZHpwi/g8T2 X2jr2io0 ceFXfoDigCH4da38onZTv/8XEgAQFDbujgxVOsTed4vaNffs0C7pgnkYzOK5lhPSrBv1KyLuAL37CNbLUU4U+GXJdrXAEWkgGS05ck+h4iENAKJtwWX2u0ommLN/GzbP9tNhfxkqplcEtRPEYT8zceo4ShIkFMJ+DgH+0XypwqZ+YyLk19WdkRhlL+wbyWOkYb9A0QDBFKGj5GpuZpuWsqH3WHKPvB3vHKmgGETmnLMhH4GiuOkV2GEsKtFgUbWvDGF/BA8CgtAmx1RnqFwxeaCeBA/lM5nTMi4MBFpVIEzu9LkyzG81PS7vXXtfqDkS3LM+ryibKKtV4bwsPMtvw5unu8K7WE0K/QUonwGTNOtnuZzVqK14a8d8Ry++Fy32lkdaiOlT/WOXOevPrXV6w2ncB4cpTTf0P39mehkPfSdFwau4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Sep 30, 2024 at 11:39:49AM GMT, Lorenzo Stoakes wrote: > On Mon, Sep 30, 2024 at 12:33:18PM GMT, Florian Weimer wrote: > > * Lorenzo Stoakes: > > > > > If you wish to utilise a pidfd interface to refer to the current process > > > (from the point of view of userland - from the kernel point of view - the > > > thread group leader), it is rather cumbersome, requiring something like: > > > > > > int pidfd = pidfd_open(getpid(), 0); > > > > > > ... > > > > > > close(pidfd); > > > > > > Or the equivalent call opening /proc/self. It is more convenient to use a > > > sentinel value to indicate to an interface that accepts a pidfd that we > > > simply wish to refer to the current process. > > > > The descriptor will refer to the current thread, not process, right? > > No it refers to the current process (i.e. thread group leader from kernel > perspective). Unless you specify PIDFD_THREAD, this is the same if you did the above. > > > > > The distinction matters for pidfd_getfd if a process contains multiple > > threads with different file descriptor tables, and probably for > > pidfd_send_signal as well. > > You mean if you did a strange set of flags to clone()? Otherwise these are > shared right? > > Again, we are explicitly looking at process not thread from userland > perspective. A PIDFD_SELF_THREAD might be possible, but this series doesn't try > to implement that. Florian raises a good point. Currently we have: (1) int pidfd_tgid = pidfd_open(getpid(), 0); (2) int pidfd_thread = pidfd_open(getpid(), PIDFD_THREAD); and this instructs: pidfd_send_signal() pidfd_getfd() to do different things. For pidfd_send_signal() it's whether the operation has thread-group scope or thread-scope for pidfd_send_signal() and for pidfd_getfd() it determines the fdtable to use. The thing is that if you pass: pidfd_getfd(PDIFD_SELF) and you have: TGID T1 { clone(CLONE_THREAD) unshare(CLONE_FILES) } T2 { clone(CLONE_THREAD) unshare(CLONE_FILES) } You have 3 threads in the same thread-group that all have distinct file descriptor tables from each other. So if T1 did: pidfd_getfd(PIDFD_SELF, ...) and we mirror the PIDTYPE_TGID behavior then T1 will very likely expect to get the fd from its file descriptor table. IOW, its reasonable to expect that T1 is interested in their very own resource, not someone else's even if it is the thread-group leader. But what T1 will get in reality is an fd from TGID's file descriptor table (and similar for T2). Iirc, yes that confusion exists already with /proc/self. But the question is whether we should add the same confusion to the pidfd api or whether we make PIDFD_SELF actually mean PIDTYPE_PID aka the actual calling thread. My thinking is that if you have the reasonable suspicion that you're multi-threaded and that you're interested in the thread-group resource then you should be using: int pidfd = pidfd_open(getpid(), 0) and hand that thread-group leader pidfd around since you're interested in another thread. But if you're really just interested in your own resource then pidfd_open(getpid(), 0) makes no sense and you would want PIDFD_SELF. Thoughts?