lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <0365d4f7-29b7-45be-956f-57555d1b1648@linux.alibaba.com>
Date: Mon, 28 Oct 2024 15:32:20 +0800
From: Jingbo Xu <jefflexu@...ux.alibaba.com>
To: Miklos Szeredi <miklos@...redi.hu>,
 "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 hliang@...ux.alibaba.com
Subject: fuse: auto_inval_data in writethrough mode


Hi FUSE folks,

I'd like to share and discuss an issue of fuse's auto_inval_data feature
in writethrough mode.

auto_inval_data is introduced since v3.6 commit
eed2179efe1aac145bf6d54b925b750976380fa6 ("fuse: invalidate inode
mapping if mtime changes"), which invalidates the page cache
automatically when a changed mtime timestamp is detected.  This is used
to help the cache consistency when the fuse file could be modified by
bypass, e.g. the backing file is modified directly through the backing
filesystem (e.g. the backing ext4) rather than fuse mountpoint.  For
example, when the file data is modified not through FUSE filesystem, the
mtime of the file will be changed; when the FUSE filesystem is doing a
file operation that relying on the latest attribute, it will update the
file attribute (calling fuse_update_attributes()) and (in some
conditions) send a FUSE_GETATTR to server to refresh the cached
attribute.  When the FUSE_GETATTR is replied, fuse client will find that
the latest mtime is different with the one cached in kernel, which is a
hint that the file data has been modified without kernel noticing this.
And then the fuse client will invalidate the whole address space, so
that the following data accessing will re-initiate FUSE_READ request to
fetch latest data from fuse server.

We noticed an interesting phenomenon when auto_inval_data works in
writethrough mode.  In writethrough mode, the local cached mtime (in
kernel) is not trusted, instead the fuse server is the only one trusted
to maintain mtime (see commit b36c31ba95f0fe0a03c727300d9c4c54438a5636
("fuse: don't update file times")).  Thus a generic write(2) routine in
writethrough mode won't update the local cached mtime in kernel
(inode->i_mtime).  When processing FUSE_WRITE requests, the fuse server
will update file's mtime.  Assuming there's no modification to the file
from other than the fuse client, a later file access to the fuse file
will found a new mtime (retrieved from fuse server) and auto_inval_data
is triggered.

In above example, the file is modified only from fuse filesystem, but an
*extra* redundant invalidation is always required when doing a read
following a write.

I'm not sure if this is a known issue or not, neither if it's a
deliberate design, or actually we could optimize this (if there's any
good solution to it).


-- 
Thanks,
Jingbo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ