Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp491015ybl; Tue, 7 Jan 2020 09:37:09 -0800 (PST) X-Google-Smtp-Source: APXvYqwRwjv5DaWKrK1hQKTAWgdaipK31KCRGZZ+/mNGr4IC/RoCQSn9a45t02MpBRUuqr+Iv09a X-Received: by 2002:a9d:6f0a:: with SMTP id n10mr998880otq.54.1578418628732; Tue, 07 Jan 2020 09:37:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578418628; cv=none; d=google.com; s=arc-20160816; b=Q6Z/Ta4dQkVsgwjaZ9+VEDhNuM9INndkhQKTrhY+Z9Svj034OnKDW5kVet0Hl/cdnP DLiveedg2Xg7mpAfw/I76n5vLJTmrKm+P6pC7sLwK/LAHOOQ3z0k7kueAOm5XvuHYkOn y04IF4KLIxFIYwvza/TVLwWBqUySqnhwTHfihETn/RoqT2Hp7EO/H8k6fN9prWjLSdo1 ApUhJFYmDkuwuSMaUxTqr7m0IgN63yNBOF6jIB9qph/5Y/uALE9SR+KzBojPPI1/9LVq ZgGPAaY1jESZFiX//cNk+tAF0vpOXjgzDKXcIVlnu8hPdt5etD6oJNCg/9dD2sNfWj+K yRUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:from:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date; bh=N3egbq5XEqcZ4zBFzKYvOLUvtOjyz1jW87MJS0fIZMw=; b=muDYSogTNXES6qQlaS1m2iMvxIkhnGXpDNPScWBgCiI6ErbrhmAG1yfAsqyWUPg6PV 6wI/rKFLYLw8Hyvee8VS1GKzOs2uYWlNMa1NbYphuoEdjV90D9m0fiAunhda75/n/ppv TIf1khuv9t2qNr9KslnBBJgfedfYvTl2ZuFBhrYXtgAE7djMuEq/Sv7fAcqxgNQuJZPW imJY5tA/jzWx18gpxo9CPeZoI6Ov4HUe0+jtCVwFUrOATHsL44AHbHJydWbdfDHFUujX sLVw9TcKylRAiWoPcsbYhbeN7d2GlqPidGZN/a5X3k2Eqm6Y/XEAW5eZ4XSComrW6uT4 fxlg== 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 a5si348486oie.17.2020.01.07.09.36.56; Tue, 07 Jan 2020 09:37:08 -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 S1728538AbgAGRfa (ORCPT + 99 others); Tue, 7 Jan 2020 12:35:30 -0500 Received: from fieldses.org ([173.255.197.46]:53664 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728321AbgAGRfa (ORCPT ); Tue, 7 Jan 2020 12:35:30 -0500 Received: by fieldses.org (Postfix, from userid 2815) id 19CA11C7B; Tue, 7 Jan 2020 12:35:30 -0500 (EST) Date: Tue, 7 Jan 2020 12:35:30 -0500 To: Chris Down Cc: "Darrick J. Wong" , linux-fsdevel@vger.kernel.org, Al Viro , Jeff Layton , Johannes Weiner , Tejun Heo , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] fs: inode: Reduce volatile inode wraparound risk when ino_t is 64 bit Message-ID: <20200107173530.GC944@fieldses.org> References: <20191220024936.GA380394@chrisdown.name> <20191220213052.GB7476@magnolia> <20191221101652.GA494948@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191221101652.GA494948@chrisdown.name> User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 21, 2019 at 10:16:52AM +0000, Chris Down wrote: > Darrick J. Wong writes: > >On Fri, Dec 20, 2019 at 02:49:36AM +0000, Chris Down wrote: > >>In general, userspace applications expect that (device, inodenum) should > >>be enough to be uniquely point to one inode, which seems fair enough. > > > >Except that it's not. (dev, inum, generation) uniquely points to an > >instance of an inode from creation to the last unlink. I thought that (dev, inum) was supposed to be unique from creation to last unlink (and last close), and (dev, inum, generation) was supposed to be unique for all time. > I didn't mention generation because, even though it's set on tmpfs > (to prandom_u32()), it's not possible to evaluate it from userspace > since `ioctl` returns ENOTTY. We can't ask userspace applications to > introspect on an inode attribute that they can't even access :-) Is there any reason not to add IOC_GETVERSION support to tmpfs? I wonder if statx should return it too? --b.