[RFC PATCH] fs: obtain the inode generation number from vfs directly
Christian Brauner
brauner at kernel.org
Tue Aug 27 09:22:17 UTC 2024
On Mon, Aug 26, 2024 at 10:37:12PM GMT, Darrick J. Wong wrote:
> On Tue, Aug 27, 2024 at 10:32:38AM +0800, Hongbo Li wrote:
> >
> >
> > On 2024/8/27 10:13, Darrick J. Wong wrote:
> > > On Tue, Aug 27, 2024 at 01:41:08AM +0000, Hongbo Li wrote:
> > > > Many mainstream file systems already support the GETVERSION ioctl,
> > > > and their implementations are completely the same, essentially
> > > > just obtain the value of i_generation. We think this ioctl can be
> > > > implemented at the VFS layer, so the file systems do not need to
> > > > implement it individually.
> > >
> > > What if a filesystem never touches i_generation? Is it ok to advertise
> > > a generation number of zero when that's really meaningless? Or should
> > > we gate the generic ioctl on (say) whether or not the fs implements file
> > > handles and/or supports nfs?
> >
> > This ioctl mainly returns the i_generation, and whether it has meaning is up
> > to the specific file system. Some tools will invoke IOC_GETVERSION, such as
> > `lsattr -v`(but if it's lattr, it won't), but users may not necessarily
> > actually use this value.
>
> That's not how that works. If the kernel starts exporting a datum,
> people will start using it, and then the expectation that it will
> *continue* to work becomes ingrained in the userspace ABI forever.
> Be careful about establishing new behaviors for vfat.
Is the meaning even the same across all filesystems? And what is the
meaning of this anyway? Is this described/defined for userspace
anywhere?
More information about the Linux-security-module-archive
mailing list