On Mon, 2018-02-05 at 17:12 +0100, Miklos Szeredi wrote:

On Mon, Feb 5, 2018 at 4:50 PM, James Bottomley
[off-list ref] wrote:

quoted

On Mon, 2018-02-05 at 08:40 -0500, Mimi Zohar wrote:

quoted

On filesystems, such as fuse or remote filesystems, that we can not
detect or rely on the filesystem to tell us when a file has changed,
always re-measure, re-appraise, and/or re-audit the file.

Using the presence or absence of d_revalidate isn't definitive for
uncacheable appraisals: all stacked filesystems have to implement
d_revalidate just in case the underlying has it, but it doesn't mean
their appraisals can't be cached if they're fully built on top of
traditional filesystems (like they are in the Docker/OCI use case).  I
think the original flag approach is better.  The only thing stackable
filesystems argues for is that for them it should probably be a
superblock flag so it can be per-mount point (depending on overlay
composition).

d_revalidate() also strikes me as wrong from the semantic point of
view: it's about whether the path name to inode cache needs re-
evaluating not whether the underlying inode could change arbitrarily.
 These are definitely related but not necessarily equivalent concepts.

True.  A more precise indication is whether cache pages have been
invalidated for a certain inode.   Can we used that?  I.e.
invalidate_inode_pages*() calls down into IMA or sets a flags or
whatever to indicate that the file contents might have changed.

I don't think that works for the FUSE use case.

Mimi