Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Wed, 25 Oct 2023 16:21:54 +0200
From:   Jan Kara <jack@suse.cz>
To:     Amir Goldstein <amir73il@gmail.com>
Cc:     Miklos Szeredi <miklos@szeredi.hu>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        Benjamin Coddington <bcodding@redhat.com>,
        Jeff Layton <jlayton@kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        Christian Brauner <brauner@kernel.org>,
        Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org,
        linux-unionfs@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] fuse: derive f_fsid from s_dev and connection start time
Message-ID: <20231025142154.witld2g5iici24fr@quack3>
References: <20231025114228.23167-1-amir73il@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231025114228.23167-1-amir73il@gmail.com>
Precedence: bulk

On Wed 25-10-23 14:42:28, Amir Goldstein wrote:
> Use s_dev number and connection start time to report f_fsid in statfs(2).
> 
> The s_dev number could be easily recycled, so we use lower 32bits of the
> connection start time to try to avoid the recycling of f_fsid.
> The anon bdev number is only 20 bits (major is 0), so we could use more
> bits from connection start time, but avoiding f_fsid recycling is not
> critical, so 32bit is enough.
> 
> If the server does not support NFS export, fuse client still advertizes
> ->s_export_op, but those are non compliant operations that often cannot
> decode file handles, or worse, decode file hanldes to wrong objects.
> 
> In this case, leave f_fsid zero to signal fanotify and aware users to
> avoid exporting this incompliant fuse filesystem to NFS.
> 
> This allows fuse client to be monitored by fanotify filesystem watch
> for local client file access if server supports NFS export.
> 
> For example, with inotify-tools 4.23.8.0, the following command can be
> used to watch local client access over entire nfs filesystem:
> 
>   fsnotifywatch --filesystem /mnt/fuse
> 
> Note that fanotify filesystem watch does not report remote changes on
> server.  It provides the same notifications as inotify, but it watches
> over the entire filesystem and reports file handle of objects and fsid
> with events.
> 
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
> 
> Miklos,
> 
> I'd like to explain why I chose to tie setting fuse f_fsid with fuse
> server NFS export capability.
> 
> Since v6.6-rc7, fanotify permits sb/mount watch only for filesystems
> that know how to decode ALL file handles (not only how to encode).
> fanotify checks for the ->fh_to_dentry() method, which fuse always
> implements regardless of server NFS export support.
> 
> At first I considered assigning s_export_op depending on server NFS
> export support, but that would break the exising fuse best-effort decode
> behavior, whatever it is worth.
> 
> Currently, fanotify sb watch does not support fuse because of zero f_fsid,
> so I decided to keep it this way for the incomplete NFS export case.

OK, so this will keep fanotify not able to support inotify functionality in
this corner case. I'm fine with that but I'm making sure I understand the
implications.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR