Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp916149imu; Tue, 20 Nov 2018 08:51:07 -0800 (PST) X-Google-Smtp-Source: AFSGD/WelE8fjnZIPq3ZyWSyB6MknQvyTEU+eD3AjFXma9VD+et+cWNxRxvplLOZzyRX38g5ijwb X-Received: by 2002:a63:7a5b:: with SMTP id j27mr2602675pgn.112.1542732667386; Tue, 20 Nov 2018 08:51:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542732667; cv=none; d=google.com; s=arc-20160816; b=ybqRM1ID9GMT4owjH2r4/eRkLHUyAc2VtLKiA8SkBR+E9YaYbu6ST9ad0y6Q+CuJBY sjexHseBmcNlyV6WN8RLfDt2fdIxULlHu/+fS6VehyHMKEsdRlSDFwByZQU42tKiIrDB GfdXpLbD2Ufbi0DO64PI9p84g7KqOHPpn8RwD+ieWqDtMHiLLHyuRUSjtUNzXDgk3VzI Cd9b8IOZa+exvausi0RcmwzozngzrEgRhk3by9/mXR9WzMOcWj05se4ip7pBlqtRjn+s eGbU99Ae/r39z/dzh9/r6HGG1Hw46VA9eZXK/H6gmLQp4/ccCUN7RanOPEnHUZsZM3lw 6rkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=ztf9osfOHjGeyYpa7QEnzEQQYPCcuaQuTBdM+dktOms=; b=OpBklliKmZwXG0rPdhMJ+9G/8t2+PVARFCiPDvDtW+9nTMp0M6bO9mYZxo4ztiPWMM jDWcnkA7mTG4tCdfAb/oW5wpk3HrbmLvSCpeO5bkg4zfurwZqSKedVjDHrblq9TOBHqw uGO2KM+YLTvUSM/aGDc/jXCcErT9KlWFpwVMBZmk/tyrdXK5iadSIds075sLxT/u20J5 SqZXFsMMQ8cD+mexzEQaaKi9g0jXw0U7OblXsIRtRfBfNPAqtOMXxlEgB74wzaA4vi9S fWMqZcF43NABXoz5BabiN14JZRGkP9dajTiOqh6IWy2W/AikpbV29Dmym5dlShYHgYlR id0w== 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 b10si27651664plz.233.2018.11.20.08.50.52; Tue, 20 Nov 2018 08:51:07 -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 S1730213AbeKUDT4 (ORCPT + 99 others); Tue, 20 Nov 2018 22:19:56 -0500 Received: from ms.lwn.net ([45.79.88.28]:55940 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbeKUDT4 (ORCPT ); Tue, 20 Nov 2018 22:19:56 -0500 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 6971535A; Tue, 20 Nov 2018 16:49:51 +0000 (UTC) Date: Tue, 20 Nov 2018 09:49:50 -0700 From: Jonathan Corbet To: Vlastimil Babka Cc: Pavel Machek , Daniel Colascione , linux-kernel@vger.kernel.org, rppt@linux.ibm.com, timmurray@google.com, joelaf@google.com, surenb@google.com, 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: <20181120094950.11978b68@lwn.net> In-Reply-To: <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> References: <20181031150625.147369-1-dancol@google.com> <20181105132205.138695-1-dancol@google.com> <20181119105426.GD28607@amd> <1c5caa66-3c61-cb57-754a-f099200c73b2@suse.cz> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Nov 2018 10:05:21 +0100 Vlastimil Babka wrote: > 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? In the hopes of ending this discussion, I'm going to go ahead and apply this. Documenting current behavior is good, especially in situations where that behavior can surprise people; if the implementation changes, the docs can change with it. Thanks, jon