[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