On Tue, Jan 09, 2018 at 09:10:41AM -0500, Jeff Layton wrote: > --- /dev/null > +++ b/include/linux/iversion.h > @@ -0,0 +1,236 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _LINUX_IVERSION_H > +#define _LINUX_IVERSION_H > + > +#include <linux/fs.h> > + > +/* > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for > + * knfsd, but is also used for other purposes (e.g. IMA). The i_version must > + * appear different to observers if there was a change to the inode's data or > + * metadata since it was last queried. > + * > + * Observers see the i_version as a 64-bit number that never changes. I don't understand that sentence. > If it > + * remains the same since it was last checked, then nothing has changed in the > + * inode. If it's different then something has changed. Observers cannot infer > + * anything about the nature or magnitude of the changes from the value, only > + * that the inode has changed in some fashion. As we've discussed before, there may be brief windows where the first two statements aren't quite correct. I think that would be worth a mention if we can keep it concise. Maybe add something like this?: It may be impractical for filesystems to keep i_version updates atomic with respect to the changes that cause them. They should, however, guarantee that i_version updates are never visible before the changes that caused them. Also, i_version updates should never be delayed longer than it takes the original change to reach disk. Or maybe those details are best left to documentation on the relevant parts of the api below (maybe inode_maybe_inc_iversion?). I dunno if it's also worth mentioning that nfsd doesn't actually use the raw i_version--it mixes it with ctime to prevent i_version reuse after reboot. Presumably that doesn't matter to IMA since it doesn't compare i_version across reboots. The documentation here is all very helpful, thanks. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
