On Tue, Sep 02, 2025 at 11:41:45AM +0200, Miklos Szeredi wrote: > On Fri, 29 Aug 2025 at 17:39, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > IMMUTABLE | APPEND seem to be captured in KSTAT_ATTR_VFS_FLAGS, so maybe > > that just needs to include the last three, and then we can use it to > > clear those bits from the fuse server's reply. > > Hmm. Fuse kernel module passes IMMUTABLE, APPEND and DAX through the > fileattr interfaces. I.e. it doesn't query the respective VFS flags > not does it try to set them. > > For IMMUTABLE and APPEND I can imagine the server being able to handle > these mostly (i.e. reject ops should be rejected). It would be nice > if the VFS was also aware. I wonder if we can fix this at this > point. You can, kind of -- either send the server FS_IOC_FSGETXATTR or FS_IOC_GETFLAGS right after igetting an inode and set the VFS immutable/append flags from that; or we could add a couple of flag bits to fuse_attr::flags to avoid the extra upcall. You'd also have to update the S_IMMUTABLE/S_APPEND flags based on the results of FS_IOC_FSSETXATTR/FS_IOC_SETFLAGS. https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=djwong-wtf&id=16584b3fcdaaeb789f22847e9f82964957493a18 (I didn't enable any of that for non-iomap files to avoid changing expected behaviors) > As for DAX, I don't see how the current behavior makes any sense, but > again not seeing clearly what the best solution is. Currently fuse > doesn't support DAX in the traditional sense, but does have DAX > functionality in virtiofs and in will in famfs. Is this flag useful > in that case? At this point, STATX_ATTR_DAX means that S_DAX is set on the VFS inode, and no other code is allowed to set that statx file attribute bit, per dax.rst: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/dax.rst The flag is very much needed for virtiofs/famfs (and any future fuse+iomap+fsdax combination), because that's how application programs are supposed to detect that they can use load/store to mmap file regions without needing fsync/msync. > I also fell that all unknown flags should also be masked off, but > maybe that's too paranoid. That isn't a terrible idea. --D > Thanks, > Miklos >
