Messages in this thread |  | | Date | Tue, 7 Jan 2020 22:00:15 -0500 | From | "J. Bruce Fields" <> | Subject | Re: [PATCH] fs: inode: Reduce volatile inode wraparound risk when ino_t is 64 bit |
| |
On Tue, Jan 07, 2020 at 05:44:07PM +0000, Chris Down wrote: > 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,
Oh, of course, I'm not objecting to this patchset at all, it's a "why not also do this?" question.
> since this demonstrably fixes issues encountered in production, and > extending a user-facing APIs is likely to be a much more extensive > discussion.
Though if it's a question of just a new implementation of an existing ioctl, I doubt it's such a big deal. (Not that I'm volunteering to write the patch.)
--b.
|  |