Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp903406imu; Tue, 20 Nov 2018 08:39:14 -0800 (PST) X-Google-Smtp-Source: AFSGD/X+9E0K1y+hA2yg+bVUBeNd5eDV26A8uy5+yrvonc980kzIrNzciuPLdx286eBQZMYsY3ng X-Received: by 2002:a63:89c2:: with SMTP id v185mr2346563pgd.97.1542731954024; Tue, 20 Nov 2018 08:39:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542731953; cv=none; d=google.com; s=arc-20160816; b=vYiN37HWkgIcuZyDeUbSSHy40t7Ja2VQGqzlDDu6sLCGuPCAz2mylIqBx+eaxRgboD hqoGmWUUjNTK7OrURrW1AUiksGPMTtt0d8xhOJi6Q322O86A5FQu1hvFtVcu5IorL9ig Cgt9ckWKz9oNSSSsF7n8Mjp39RSGAvhN7CtqxKvqoojEPjpJLorkgXgxlVcFM/Xm3yku 5k71Bipq6NwOxWK4tMl76ZfL4U1eqq5XkNjNaKUQqJw7DHPOZv8wZpQLydjCyx16odUd G9jTV2PBunJUSEAFV9SwT9VvEqneQ6dRnFmZWjsCM5D+yM9TEYhSGsjrU2zJCuuOtdLT 6G4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=W4G16yYEKxuiLGGqPZ/spDOvHty0DanvYfCipwMzgm0=; b=xMV9Bb+t6bcX23amunSZrdZb47alfBE3RBL6F2fu4DlqPS2ev0ZxWtkbQte5pT99/y uj38HmiRg4wRLjcaWmp7unbOQ5/7mt9OUPWMdYEbkCkRm03M0TjE1F1bV+x8btANLGGx IYMjq4CZvRwBM6eSVa3dOJW2o3iCzK5sNoziKtlbw7h8wBWaUcP1ztidQTA0pOYHDp5E yMUiJzLM5I2P3kBsfbjCovKkgB+E2YfIC+7YrvRRbbhIFnAKYtWZazfh6zZYzGnpzbTH i6sVeEjGBioJZj190gT+2Sshoe8etErC1Tn5rQj9mwjcQQuiovAzZo+Dj/lItZVjJVYK mRvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bTmh6Lie; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s13si10448890pgc.509.2018.11.20.08.38.58; Tue, 20 Nov 2018 08:39:13 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=bTmh6Lie; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729953AbeKUDHX (ORCPT + 99 others); Tue, 20 Nov 2018 22:07:23 -0500 Received: from mail-qk1-f195.google.com ([209.85.222.195]:39458 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726243AbeKUDHX (ORCPT ); Tue, 20 Nov 2018 22:07:23 -0500 Received: by mail-qk1-f195.google.com with SMTP id q70so3204036qkh.6 for ; Tue, 20 Nov 2018 08:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W4G16yYEKxuiLGGqPZ/spDOvHty0DanvYfCipwMzgm0=; b=bTmh6LieD+FvZkomC4SuYevLJFEXF5A5p4Jh5iFgx7VdjSdQFSpbqBT3CfowwCkBnt AonXRRVAFg94QT0Dd7z1Mx63vdDi3V4TG8bZfATMySL1dnlrIhK61HmosxAsBVmKHZXI VnHms7t/O0wEtT+H77cFvYS+2rSTL0+nuXEU8NyUw+MiFNgiEATYDEMy6kKpnq+Pa3dz eH5CQrlX3Q7Wq+oVLuhuDRm7yzSD4l1Xj22lSgQyFNHNbpjya3iprQ263U7pN1lkb7Qm 6Fcd2PMEcRr7z0OOzIyGCCDCkbJ0qqhjEyecMfFNecDz25sLnMQ+XyF54Jq+b+bU147I 4dkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W4G16yYEKxuiLGGqPZ/spDOvHty0DanvYfCipwMzgm0=; b=qhUDwj/n9d5H2/l6guAr/MxK0RfXRUCnf6acUm6IJmvyQN43l5JvUhd37bd2XP/qE/ JfKAzlb4g9/IgW1MzbOUcuDYP/N6S0lV4pc1oiDllxWD6iQX2ymNEAGZ4YcD66JFTtEE /mTlkuzAkevHX0HTlZpADIJUFsB6C04KP75s7aNmAbaRafDKE8niXI3BbKAjQRr3e15a GfTkCxRQn6jn1Ov9eABgaXqmG+DOCD7sm/Xy5Aq7o4tEJPLE7zsHma9lwFv2EIY5MsRz C01GzQIKvLZrwtDhfqBRWg0XHgsjMujw/lFJRL+wdiIytL05c8Ppk67JOgrEZIixrFvU 5f0g== X-Gm-Message-State: AA+aEWaQ1/+vDit+ow/sTWOHu6+75kCVjqtzGBxo5CmzcAs9AV+Z6RTW cUVKfgydFnQQImIQJJ4CvhFFIZKZ65BtEq3VqfqJxA== X-Received: by 2002:a37:10cf:: with SMTP id 76mr2315147qkq.99.1542731841261; Tue, 20 Nov 2018 08:37:21 -0800 (PST) MIME-Version: 1.0 References: <20181031150625.147369-1-dancol@google.com> <20181105132205.138695-1-dancol@google.com> <20181119105426.GD28607@amd> <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> In-Reply-To: <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> From: Joel Fernandes Date: Tue, 20 Nov 2018 08:37:09 -0800 Message-ID: Subject: Re: [PATCH v2] Document /proc/pid PID reuse behavior To: Vlastimil Babka Cc: pavel@ucw.cz, Daniel Colascione , LKML , rppt@linux.ibm.com, Tim Murray , Suren Baghdasaryan , Jonathan Corbet , Andrew Morton , guro@fb.com, rppt@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, dennisszhou@gmail.com, pdhamdhe@redhat.com, "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 20, 2018 at 1:05 AM 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/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/ 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 > > > > "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? > Agreed. I am also of the opinion that this should be documented. - Joel