Re: [PATCH] fs: inode: Reduce volatile inode wraparound risk when ino_t is 64 bit

From: Chris Down
Date: Tue Jan 07 2020 - 12:44:11 EST

J. Bruce Fields writes:
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.

Sure, but I mean, we don't really protect against even the first case.

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?

We can, but that seems like a tangential discussion/patch series. For the second case especially, that's something we should do separately from this patchset, since this demonstrably fixes issues encountered in production, and extending a user-facing APIs is likely to be a much more extensive discussion.

(Also, this one in particular has advanced quite a lot since this v1 patch :-))