Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2944088imu; Mon, 19 Nov 2018 08:25:25 -0800 (PST) X-Google-Smtp-Source: AFSGD/VQvbtBPFk554C3Vb4R/IfzmIrhlVq0KxrAXe6KNjebr2E02f9cAdMHWr1bYBInOtUjWpk1 X-Received: by 2002:a63:6cc8:: with SMTP id h191mr7998010pgc.366.1542644725174; Mon, 19 Nov 2018 08:25:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542644725; cv=none; d=google.com; s=arc-20160816; b=GhaBr21mRvNDOJILH8D0l7LuFvs6Y4p1JLcMWJzZvaPdM9gez3F5KHGLSiQpnnv+eh PTzHN5w8YhG0XUR5RBS4lWvuk87YjGg487IHvNPOmLVwFdvALMrqCK1FWBtx8oBxtZTA v8VmV9V/kojUQlo6APCRyQS6+A2Qp9pe7JA/5+TO1Z/xRTuWU0oo7UYPfdhwO6os9a6+ wlccvSFpFG030nUKjw5vT7i3vgILGPC/j4TIWbcH537YhFvFBrpSD8R3Bh84zEVD2l5p ndu+GSIXxEganDXJdDWZ3gIOz0A0l5jgU4XVmqgFali59qEyNdUHXl45L0BFGgdPHscA IqZA== 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 :references:in-reply-to:mime-version:dkim-signature; bh=b/dNaTvz6Bhl24QHJ1GX7PHoKH/Ynzj09/enaeXKn6k=; b=Gfyepom/fMFECSvis4i3M5Newvmu5gHJ+mQDE8qYN9EAPeCa7ZW0N2LfklsCRNR9vv aXfJ9468wMWubdIc+kWzT9f/K5B6qRO9G/IVIIkBoPBvDQTx+QXFcS0UVYm5wXzBAqyb wXiy5Vsk5bBH881XWU2Pgp/jif4Ken/nQ5/vILVKs9pEU4uqt7x5ZX3eIzHl7yIF0vdK sORmknQxYa3oXQpYCCSLpi/iUbH9JAv6ptwAM5DU8hAxtE+NT5I2GXtUcCK3lUyjy+q6 S9Yu9dt7sajHgPja/LXh4OSRGjNmNaD9zD3x3vDWrslyRshksw//8/dOxfvOs1wBirPZ XJzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=L6mQaLBx; 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 s13si17174714pgh.583.2018.11.19.08.25.09; Mon, 19 Nov 2018 08:25:25 -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=L6mQaLBx; 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 S1730024AbeKTCsJ (ORCPT + 99 others); Mon, 19 Nov 2018 21:48:09 -0500 Received: from mail-vs1-f68.google.com ([209.85.217.68]:35037 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729937AbeKTCsJ (ORCPT ); Mon, 19 Nov 2018 21:48:09 -0500 Received: by mail-vs1-f68.google.com with SMTP id e7so18116424vsc.2 for ; Mon, 19 Nov 2018 08:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b/dNaTvz6Bhl24QHJ1GX7PHoKH/Ynzj09/enaeXKn6k=; b=L6mQaLBx1jcDiwBhZpdROTnuyCRBdcapfT7uRtrNPM99BCVmZlEH+5YGsDBrT079HI bA15jwju7thTg33v0zQusbxauwrGKIlbqfvAZ/Pgujx2RhN65agYakrPWUl33eX5w7E7 CypPXjaEtWtUTJ4I8QQGi50rvp+EOoBuUquBhcg51U0C+c8Yr4+ls0FgV7H3PbtFU0l7 cWSSHrhn9h5ZIYVwskRfET1FeFKF3EbqCLTJ3YYDT+bvdyOvHMRXUx7TfcSeBZJqR8M6 9s67GrBsr0FUz9aA7Kr6/NFZcCVAYnUrHrG+sypCZoTXQF9e8l+LUfVvW8wVK9cv1glG RPeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b/dNaTvz6Bhl24QHJ1GX7PHoKH/Ynzj09/enaeXKn6k=; b=oQD3HyJhd2VZvAL0wmqn2elLKfDEjbV+RZEEfwoqx0ed0C2cPwrLeBk2E/pCoRwLlE 0M5lwUYtW4uZd6YAnpo5JI/EzJ3LOQdFr4Ed7Al/AQShOjdAgGWTXTRwmDG/Nx7xoKAy vBewK8rp+B6wP8zzEjhrDYgnymstBMNuC1YwPSo0YrbM4PA44yHMjkQIRM6tVXtQSc// XMGzAtLNYj9UA7vVJOpOCPm45GsqcW+TzjM0UmqhDigwRq5JpJIPQoclonmN5m1sF0Q7 rwrPpn218+gHdc0U6KZGbYB/MMNl1Ehi4MJ6OnvRCaAALTDebRCYft6e3evpYW9wlLs8 IEwA== X-Gm-Message-State: AGRZ1gInNI2raBWuaQaxB0Q12XOCNgL2qxvXOmg5QCfzVSg3P03UDjcw 1hDP2Kf8NHGyf8eNz+uYmr9FmKc/WYaD6s0fiAVF1w== X-Received: by 2002:a67:6346:: with SMTP id x67mr9209047vsb.114.1542644643395; Mon, 19 Nov 2018 08:24:03 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a67:f48d:0:0:0:0:0 with HTTP; Mon, 19 Nov 2018 08:24:02 -0800 (PST) In-Reply-To: <20181119105426.GD28607@amd> References: <20181031150625.147369-1-dancol@google.com> <20181105132205.138695-1-dancol@google.com> <20181119105426.GD28607@amd> From: Daniel Colascione Date: Mon, 19 Nov 2018 08:24:02 -0800 Message-ID: Subject: Re: [PATCH v2] Document /proc/pid PID reuse behavior To: Pavel Machek Cc: linux-kernel , Mike Rapoport , Tim Murray , Joel Fernandes , Suren Baghdasaryan , Jonathan Corbet , Andrew Morton , Roman Gushchin , Mike Rapoport , Vlastimil Babka , "Kirill A. Shutemov" , "Dennis Zhou (Facebook)" , Prashant Dhamdhere , "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 Mon, Nov 19, 2018 at 2: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. No. "Does not". I'm sick and tired of procfs behavior being vague and unspecified to the point where even kernel developers have an incorrect mental model of how it all works. With Christian Brauner's good work in place and hopefully my own work to follow, we're moving firmly in the direction of procfs handles being struct pid references. Instead of waffling further, let's just buy into this model and do the best job we can of making it work well.