From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40BABC433E4 for ; Fri, 24 Jul 2020 10:44:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 19E2E20748 for ; Fri, 24 Jul 2020 10:44:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=themaw.net header.i=@themaw.net header.b="SkiyG8rG"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="DDKQ+Kvl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726753AbgGXKoP (ORCPT ); Fri, 24 Jul 2020 06:44:15 -0400 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]:50817 "EHLO wnew1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726301AbgGXKoO (ORCPT ); Fri, 24 Jul 2020 06:44:14 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id ADCC1734; Fri, 24 Jul 2020 06:44:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 24 Jul 2020 06:44:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=fm3; bh= IMuqW1eWzjwrdDQGfj1YeCfnnLSlRPZHrKpHRGXycSw=; b=SkiyG8rGyUhOHAi+ Xm//2tMphHh+kJKydj+txJBwL4Xx4H/yQ2qcqHgrMGdmCF8OKvcuuFIh37S1fkpb OI5LAzXDcejvcHWBz+/jE/GAQPcidrNhLCSHaAneN0sH2ef4f7T/ofyW9z1bUyRs jUPU5TjEE3dzAr/xK027OCDsADyuyqPoAUi0iCfy0xCv2jhe3mjyyNBQNxpQYqxY Sdu3Z5+1fME1nqb6Eqmzmuxf29yLE35xkZoybiLjX6Ib6fCdmz8Ybf3NMdvOsGOX 1g5AHa4jiGKu/4cbvyEQ++XCX6XBQhuYc+rVsaPF16SGs69SWbi7jCEF5GlSS3Id srb5gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=IMuqW1eWzjwrdDQGfj1YeCfnnLSlRPZHrKpHRGXyc Sw=; b=DDKQ+KvlQlo1JLHV147fAh+wsfencJqlBsZt5ED5qpR2KU7E+GHrantXi 5q8oHCait0ejOx7vEW6ZxKW0DqL3qU75nAhFZRcA2A99pcYF7ZwssD6KmDXIdryP MgCp/946byGHEtBLH2BURuzRJRmWvHnbC1/uGOv3s2ZtgPx1G2PJ7JU7EvKIRf31 zxHh7b23ST9YUE+LfaY2c6GHp+/E1+bxDUO7zldoMYpKoCY/7qpYF3Gpol1y9JBa R6FsEo2TRLR6XfJva4DI84F+41QsCCwhcJLb+9/qIkwS7qoq4XRWvPNLoQ/eczS+ k0RKkN/QwevkU7fc/yYNlmLCq8lhA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrheefgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkuffhvfffjghftggfggfgsehtjeertddtreejnecuhfhrohhmpefkrghnucfm vghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnhepfe efteetvdeguddvveefveeftedtffduudehueeihfeuvefgveehffeludeggfejnecukfhp peduudekrddvtdekrdefjedrudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehrrghvvghnsehthhgvmhgrfidrnhgvth X-ME-Proxy: Received: from mickey.themaw.net (unknown [118.208.37.175]) by mail.messagingengine.com (Postfix) with ESMTPA id A8F2E3280065; Fri, 24 Jul 2020 06:44:05 -0400 (EDT) Message-ID: <865566fb800a014868a9a7e36a00a14430efb11e.camel@themaw.net> Subject: Re: [PATCH 13/17] watch_queue: Implement mount topology and attribute change notifications [ver #5] From: Ian Kent To: David Howells , Miklos Szeredi Cc: Linus Torvalds , Al Viro , Casey Schaufler , Stephen Smalley , nicolas.dichtel@6wind.com, Christian Brauner , andres@anarazel.de, Jeff Layton , dray@redhat.com, Karel Zak , keyrings@vger.kernel.org, Linux API , linux-fsdevel@vger.kernel.org, LSM , linux-kernel@vger.kernel.org Date: Fri, 24 Jul 2020 18:44:01 +0800 In-Reply-To: <2003787.1595585999@warthog.procyon.org.uk> References: <1293241.1595501326@warthog.procyon.org.uk> <158454378820.2863966.10496767254293183123.stgit@warthog.procyon.org.uk> <158454391302.2863966.1884682840541676280.stgit@warthog.procyon.org.uk> <2003787.1595585999@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2020-07-24 at 11:19 +0100, David Howells wrote: > David Howells wrote: > > > > What guarantees that mount_id is going to remain a 32bit entity? > > > > You think it likely we'd have >4 billion concurrent mounts on a > > system? That > > would require >1.2TiB of RAM just for the struct mount allocations. > > > > But I can expand it to __u64. > > That said, sys_name_to_handle_at() assumes it's a 32-bit signed > integer, so > we're currently limited to ~2 billion concurrent mounts:-/ I was wondering about id re-use. Assuming that ids that are returned to the idr db are re-used what would the chance that a recently used id would end up being used? Would that chance increase as ids are consumed and freed over time? Yeah, it's one of those questions ... ;) Ian