All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Pavel Machek <pavel@ucw.cz>, Daniel Colascione <dancol@google.com>
Cc: linux-kernel@vger.kernel.org, rppt@linux.ibm.com,
	timmurray@google.com, joelaf@google.com, surenb@google.com,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roman Gushchin <guro@fb.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Dennis Zhou (Facebook)" <dennisszhou@gmail.com>,
	Prashant Dhamdhere <pdhamdhe@redhat.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2] Document /proc/pid PID reuse behavior
Date: Tue, 20 Nov 2018 10:05:21 +0100	[thread overview]
Message-ID: <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> (raw)
In-Reply-To: <20181119105426.GD28607@amd>

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 <dancol@google.com>
>> ---
>>  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/filesystems/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 after the process ID (PID).
>>  The link  self  points  to  the  process reading the file system. Each process
>>  subdirectory has the entries listed in Table 1-1.
>>  
>> +Note that an open a file descriptor to /proc/<pid> or to any of its
>> +contained files or subdirectories does not prevent <pid> being reused
>> +for some other process in the event that <pid> exits. Operations on
> 
> "does not" -> "may not"?
> 
> We want to leave this unspecified, so that we can change it in future.

Why can't the documentation describe the current implementation, and
change in the future if the implementation changes? I doubt somebody
would ever rely on the pid being reused while having the descriptor
open. How would that make sense?
 									Pavel
> 
> 


  parent reply	other threads:[~2018-11-20  9:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 15:06 [PATCH] Document /proc/pid PID reuse behavior Daniel Colascione
2018-11-01  7:08 ` Mike Rapoport
2018-11-05 13:22 ` [PATCH v2] " Daniel Colascione
2018-11-06  6:01   ` Mike Rapoport
2018-11-07 17:16     ` Matthew Wilcox
2018-11-07 18:21       ` Daniel Colascione
2018-11-06 13:05   ` Michal Hocko
2018-11-07 15:48     ` Daniel Colascione
2018-11-07 16:00       ` Michal Hocko
2018-11-07 16:10         ` Daniel Colascione
2018-11-07 16:19           ` Michal Hocko
2018-11-19 11:16           ` Aleksa Sarai
2018-11-07 17:04         ` Martin Steigerwald
2018-11-08 12:02           ` David Laight
2018-11-08 12:27             ` Matthew Wilcox
2018-11-08 13:42               ` David Laight
2018-11-08 14:07                 ` Matthew Wilcox
2018-11-08 14:14                   ` David Laight
2018-11-08 13:25           ` Michal Hocko
2018-11-19 10:54   ` Pavel Machek
2018-11-19 16:24     ` Daniel Colascione
2018-11-20  8:50       ` Pavel Machek
2018-11-20  9:05     ` Vlastimil Babka [this message]
2018-11-20  9:18       ` Pavel Machek
2018-11-20 17:39         ` Matthew Wilcox
2018-11-20 17:48           ` Daniel Colascione
2018-11-20 17:59             ` Matthew Wilcox
2018-11-20 16:37       ` Joel Fernandes
2018-11-20 16:49       ` Jonathan Corbet
2018-11-20 16:57         ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dancol@google.com \
    --cc=dennisszhou@gmail.com \
    --cc=guro@fb.com \
    --cc=joelaf@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=pdhamdhe@redhat.com \
    --cc=rppt@linux.ibm.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=surenb@google.com \
    --cc=timmurray@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.