Re: [PATCH v13] fs: Add VirtualBox guest shared folder (vboxsf) support

[Hans de Goede <hdegoede@redhat.com>]

P.S.

On 16-08-19 11:01, Hans de Goede wrote:
> On 16-08-19 09:56, Christoph Hellwig wrote:

<snip>

>>> + * Ideally we would wrap generic_file_read_iter with a function which also
>>> + * does this check, to reduce the chance of us missing writes happening on the
>>> + * host side after open(). But the vboxsf stat call to the host only works on
>>> + * filenames, so that would require caching the filename in our
>>> + * file->private_data and there is no guarantee that filename will still
>>> + * be valid at read_iter time. So this would be in no way bulletproof.
>>
>> Well, you can usually generate a file name from file->f_path.dentry.
>> The only odd case is opened by unliked files.  NFS has a special hack
>> for those called sillyrename (you can grep for that). 
> 
> Right, so since the unlink or a normal rename could happen on the host side
> and there is no notification of that, those will be 2 areas where a stat
> call to verify will fail, which leaves us with 3 options:
> 
> 1) Make stat calls before read() calls, if they fail purge the cache to be safe
> 2) Make stat calls before read(), on failure ignore the stat call
> 3) Treat read() calls like other page-cache reads such as sendfile or mmap
> and only check if the cache is stale at open() time.

I just realized there is a 4th option, which is to make vboxsf read_iter
simply always do:

4) Always evict non dirt pages from page-cache from read_iter, to ensure we
    get the latest version from the host:

So something like this:

	/*
          * Evict non dirt pages from page-cache, so that we reget them from
          * the host in case they have been changed.
          * /
	invalidate_mapping_pages(inode->i_mapping, pos >> PAGE_SHIFT,
				 (pos + len) >> PAGE_SHIFT);
         generic_file_read_iter(...)

This is in essence what the out of tree driver is doing on read(), except
that it does not go through the page-cache at all.

I think this might be the best option, perhaps controlled by a mount
flag ?

Regards,

Hans