Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp443021imu; Wed, 21 Nov 2018 23:27:33 -0800 (PST) X-Google-Smtp-Source: AJdET5coXFpo3F3Vwsozfq3VVi7mB4eMVwoYXipGYCXVq8qaRXyo0iHWDQQcykNopVS/7U3abF8D X-Received: by 2002:a62:1c7:: with SMTP id 190mr10365587pfb.46.1542871653036; Wed, 21 Nov 2018 23:27:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542871653; cv=none; d=google.com; s=arc-20160816; b=UZW45uhzIE2ol27qvQMw8fLD26yIecuN72s5usCkbfEyZz0M9wvUrHo+OC0y7rN4Fh vEfwW8vLSnMBeMAWq8zzVyCiibDIStpiXW4tovdR03ojtX4osW38kxOa4vt2F7JkTtVl FAYT3BxD3FJb0EcbObdrARWVYjbMLrgUr68Ik/ZpKoCJIxwh1nt0AiK5ODsdQoDrrg7g quBVpBC5Acce+E/ucgXf6foaqYqzdi/vBrpGa9/3aBU4VueKsSvRqK/9xpQGIVYWB4T6 lrMHHh5tvhBz0GJi8i6zP2YfoNxtwsOrPmNmN0U8Ysc3H2BstkNU7S9JUVC/W186cT6T oprA== 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=bm0cmdW8xHtpvw83SANYUh6MFHRfj/MqEyWJqmXjk1w=; b=eCW9ISq2MyKAthqCv9H4Zd85gzSpr1wGTZQVLRXEuY5ncRPXakTbN82F9954DpeffD IYwz7dECEIzGINUseDe7q9KJO/wcxXklOAQt6NbrSV+vPWfy9tpXfH7QeO5daKBysKGo FMup/JQH1HFQRhYaNVfqiVJy2UnTo2YimmsBH7ZgXVcelyzrk8qmedQZX7QV7El8kcOl EXfPA1Bj7gaOQKzL9F5Amydht0HjVEESj8oPiHP0TzVgy1Px+Jcf0yzBppMnT3cfjyEb Wj5MLMIrnanr4IzFE/escN+5WvOXUtq5cnrJuiT5x7MRW2nSqe0xabe/i72zuthtDn8F HEZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=MvzMR9dD; 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 c11si41472292pgh.18.2018.11.21.23.27.15; Wed, 21 Nov 2018 23:27:32 -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=MvzMR9dD; 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 S1732950AbeKVHO1 (ORCPT + 99 others); Thu, 22 Nov 2018 02:14:27 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:41217 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730074AbeKVHO1 (ORCPT ); Thu, 22 Nov 2018 02:14:27 -0500 Received: by mail-vs1-f66.google.com with SMTP id t17so4068003vsc.8 for ; Wed, 21 Nov 2018 12:38:33 -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=bm0cmdW8xHtpvw83SANYUh6MFHRfj/MqEyWJqmXjk1w=; b=MvzMR9dDj7CZG/+mAlO7e9BG7xnEPolUnFhZu5OvKAqWr17r0buX+UZI16KXbm2PWk A9UMWcctar1IJgq1+Xz5SJ7QBFUgVZm3lIU5CpBSlaWNEhCphP2zbnzKFbWdRE+E+zbR u7eaW5Uq2tYvToY2OwypWA5BERtcPAJmhYDEykA2FIEdKOiS21WBbBIYCI2uqKGQZlkj R/HP7D+LNfPlCPVGlNhn9sUkD9iFY0+Y2PPAWjo8DzI5ARu8Oa9JiZquTcvFpyOh5Urf xdW7XUynKpn4HE64/hWr2vbvoi3ojIfsFV5ucxH51AAmO9aiWeCB/ov0GW6jtc269XNE mDXw== 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=bm0cmdW8xHtpvw83SANYUh6MFHRfj/MqEyWJqmXjk1w=; b=JyYaODfl21/mpKO45uzSCFnhOWwcbUC9aZYqc9y4R/sr4fyRRr5u1XL8GQ9TV8vRnr zvlCkIPfd7wbPaPTe0BmFyrLeO0DX8TsrtlYHxugfOhdgR/b8tWgmOq/h+jifaScwsfi XcwJ3HpZr2244se25Nxbfihng7O4kTtnNpE5kONFqCS5quNALU0X4A5CaFsbjiH0vcOU V8S6F9smDNa3Ia+3agMH5kptwiltyXXR8wXaF8+x/gyXgama8SOfSkr0lowTvud4SqNY U3dep3s5kqFl1mRF6p7ig68vDx3Nv7anuPH7eswuG1IwMuGla9zNngBUrrxginUF1yzq vqyQ== X-Gm-Message-State: AGRZ1gJT4CgCDKU7hpN94Bxt3FOEB2iNPgSWnxJuSwURibQ5V86IDUkg thdqfRjAvsQt5IFukaUHAYgy71+6NcgtfZsexYHuNA== X-Received: by 2002:a67:6346:: with SMTP id x67mr3386449vsb.114.1542832712373; Wed, 21 Nov 2018 12:38:32 -0800 (PST) MIME-Version: 1.0 References: <20181121201452.77173-1-dancol@google.com> <20181121203150.GK3065@bombadil.infradead.org> In-Reply-To: <20181121203150.GK3065@bombadil.infradead.org> From: Daniel Colascione Date: Wed, 21 Nov 2018 12:38:20 -0800 Message-ID: Subject: Re: [PATCH] Add /proc/pid_generation To: Matthew Wilcox Cc: linux-kernel , Linux API , Tim Murray , Primiano Tucci , Joel Fernandes , Jonathan Corbet , Andrew Morton , Mike Rapoport , Roman Gushchin , Vlastimil Babka , "Dennis Zhou (Facebook)" , Prashant Dhamdhere , "Eric W. Biederman" , rostedt@goodmis.org, tglx@linutronix.de, mingo@kernel.org, linux@dominikbrodowski.net, pasha.tatashin@oracle.com, jpoimboe@redhat.com, ard.biesheuvel@linaro.org, Michal Hocko , David Howells , ktsanaktsidis@zendesk.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 Wed, Nov 21, 2018 at 12:31 PM Matthew Wilcox wrote: > > On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote: > > This change adds a per-pid-namespace 64-bit generation number, > > incremented on PID rollover, and exposes it via a new proc file > > /proc/pid_generation. By examining this file before and after /proc > > enumeration, user code can detect the potential reuse of a PID and > > restart the task enumeration process, repeating until it gets a > > coherent snapshot. > > > > PID rollover ought to be rare, so in practice, scan repetitions will > > be rare. > > Then why does it need to be 64-bit? [Resending because of accidental HTML. I really need to switch to a better email client.] Because 64 bits is enough for anyone. :-) A u64 is big enough that we'll never observe an overflow on a running system, and PID namespaces are rare enough that we won't miss the four extra bytes we use by upgrading from a u32. And after reading about some security problems caused by too-clever handling of 32-bit rollover, I'd rather the code be obviously correct than save a trivial amount of space.