Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp431673imu; Tue, 20 Nov 2018 01:20:14 -0800 (PST) X-Google-Smtp-Source: AFSGD/XjFZv9Dsva+X9iMd+4p8fLhJ9beySa1sPMiY0T33mlIj9R0eOrxNDRby0oVaBBkuFNKKX5 X-Received: by 2002:a63:cf08:: with SMTP id j8mr1218567pgg.113.1542705614705; Tue, 20 Nov 2018 01:20:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542705614; cv=none; d=google.com; s=arc-20160816; b=ON5UG+NvQgXTuUP+u/hnGsWhRwqQpTsHJZ10+wRgJOg7iMy6qLnhJqQ5eVe6/qbYmZ NZE9R5zizuWgW4fFtaiZGyzd5Fr8tV605IsXirj6QPvj3UA5Hgr2o+AlbTDasL6Aprwp cpT/UJmiKfuy5/85rZi7AQaf+3FR1xfiOXrdVePd334x6W/ezMkFISYXU7kDoqV/e2Gw ajejZFQ76wAjlgo6a+xZa5tV4dcLVN8fbZdKEoZxKce3cD0Y4vz5lIeOK22CU+vvBX/6 qlSVGTomr+xnHpowDKMgyYfnGsrgOEf2XmnB3o2XNtl43jHRlESwgdNvFnmyug4QpUhu 4O4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=fZATCDO8SiWJMhD3evCdwTiI6JxJOua721gPHaDBfUU=; b=i6aFhld+P1yx7JemIHPkTYlx9zsq2807BFlD1L8azF8vkJZr54yRTESd/NjRpFZxB8 eyndXh2ZNaaqFPOXwHi5wxyfQ4ZLRmOYfAsXimSKyZOH2RVs5XD7AthJe6Z1zuLr0NzS QJrP4A2+XZMRMk+Pr/4DxgGz5Sof0dvMJVphmNT2u6kG/o5RQMhl/TGOIG5N/Kud2h2p l6ND4jfsMwnTrQhSCVNXW1Iz9lzOHI4fBoIcUVpZhFxvqm277e5IboT+nBmh/6TwETGb t28NL+ErhlCC8REzNVP73m7y8/6HCb5ixIZ95YoPw5IokZU2vVH9rxUENta8izSqkHDc jgZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9si20381106pfd.86.2018.11.20.01.20.00; Tue, 20 Nov 2018 01:20:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727404AbeKTTqi (ORCPT + 99 others); Tue, 20 Nov 2018 14:46:38 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:48821 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726479AbeKTTqh (ORCPT ); Tue, 20 Nov 2018 14:46:37 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 3735D8094E; Tue, 20 Nov 2018 10:18:27 +0100 (CET) Date: Tue, 20 Nov 2018 10:18:29 +0100 From: Pavel Machek To: Vlastimil Babka Cc: Daniel Colascione , linux-kernel@vger.kernel.org, rppt@linux.ibm.com, timmurray@google.com, joelaf@google.com, surenb@google.com, Jonathan Corbet , Andrew Morton , Roman Gushchin , Mike Rapoport , "Kirill A. Shutemov" , "Dennis Zhou (Facebook)" , Prashant Dhamdhere , "open list:DOCUMENTATION" Subject: Re: [PATCH v2] Document /proc/pid PID reuse behavior Message-ID: <20181120091829.GD16916@amd> References: <20181031150625.147369-1-dancol@google.com> <20181105132205.138695-1-dancol@google.com> <20181119105426.GD28607@amd> <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EY/WZ/HvNxOox07X" Content-Disposition: inline In-Reply-To: <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue 2018-11-20 10:05:21, Vlastimil Babka wrote: > On 11/19/18 11:54 AM, Pavel Machek wrote: > > On Mon 2018-11-05 13:22:05, Daniel Colascione wrote: > >> State explicitly that holding a /proc/pid file descriptor open does > >> not reserve the PID. Also note that in the event of PID reuse, these > >> open file descriptors refer to the old, now-dead process, and not the > >> new one that happens to be named the same numeric PID. > >> > >> Signed-off-by: Daniel Colascione > >> --- > >> Documentation/filesystems/proc.txt | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> Moved paragraphed to start of /proc/pid section; added signed-off-by. > >> > >> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesy= stems/proc.txt > >> index 12a5e6e693b6..0b14460f721d 100644 > >> --- a/Documentation/filesystems/proc.txt > >> +++ b/Documentation/filesystems/proc.txt > >> @@ -125,6 +125,13 @@ process running on the system, which is named aft= er the process ID (PID). > >> The link self points to the process reading the file system. Eac= h process > >> subdirectory has the entries listed in Table 1-1. > >> =20 > >> +Note that an open a file descriptor to /proc/ or to any of its > >> +contained files or subdirectories does not prevent being reused > >> +for some other process in the event that exits. Operations on > >=20 > > "does not" -> "may not"? > >=20 > > We want to leave this unspecified, so that we can change it in future. >=20 > Why can't the documentation describe the current implementation, and > change in the future if the implementation changes? I doubt somebody Documentation should describe "contract" between kernel and userspace. > would ever rely on the pid being reused while having the descriptor > open. How would that make sense? I agree this is corner space, but users might be surprised that keeping FDs of /proc/pid/X would lead to PID space exhaustion, for example. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --EY/WZ/HvNxOox07X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlvz0WUACgkQMOfwapXb+vJ1PACgmy/iCA1dXVCGclBaPHG6U4Kw 1zMAnjmMZqfNMLsTsMqdWy4mmy/bpC5r =fvhL -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X--