On Mon, 26 Feb 2024 at 04:54, Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: > > open_by_handle_at(2) can fail with -ESTALE with a valid handle returned > by a previous name_to_handle_at(2) for evicted fuse inodes, which is > especially common when entry_valid_timeout is 0, e.g. when the fuse > daemon is in "cache=none" mode. > > The time sequence is like: > > name_to_handle_at(2) # succeed > evict fuse inode > open_by_handle_at(2) # fail > > The root cause is that, with 0 entry_valid_timeout, the dput() called in > name_to_handle_at(2) will trigger iput -> evict(), which will send > FUSE_FORGET to the daemon. The following open_by_handle_at(2) will send > a new FUSE_LOOKUP request upon inode cache miss since the previous inode > eviction. Then the fuse daemon may fail the FUSE_LOOKUP request with > -ENOENT as the cached metadata of the requested inode has already been > cleaned up during the previous FUSE_FORGET. The returned -ENOENT is > treated as -ESTALE when open_by_handle_at(2) returns. > > This confuses the application somehow, as open_by_handle_at(2) fails > when the previous name_to_handle_at(2) succeeds. The returned errno is > also confusing as the requested file is not deleted and already there. > It is reasonable to fail name_to_handle_at(2) early in this case, after > which the application can fallback to open(2) to access files. > > Since this issue typically appears when entry_valid_timeout is 0 which > is configured by the fuse daemon, the fuse daemon is the right person to > explicitly disable the export when required. > > Also considering FUSE_EXPORT_SUPPORT actually indicates the support for > lookups of "." and "..", and there are existing fuse daemons supporting > export without FUSE_EXPORT_SUPPORT set, for compatibility, we add a new > INIT flag for such purpose. > > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > Signed-off-by: Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> Applied, thanks. Miklos
