Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 3 Feb 2021 23:20:35 +0200
From:   Dan Aloni <dan@kernelim.com>
To:     Benjamin Coddington <bcodding@redhat.com>
Cc:     Anna Schumaker <schumaker.anna@gmail.com>,
        Chuck Lever <chuck.lever@oracle.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 0/5] SUNRPC: Create sysfs files for changing IP
Message-ID: <20210203212035.qncen4u3o6pr57h6@gmail.com>
References: <20210202184244.288898-1-Anna.Schumaker@Netapp.com>
 <75F3F315-84AA-41A0-A43A-C531042A9C47@oracle.com>
 <CAFX2JfktYGe4vDtXogFHurdyz4TJx5APj9pb-J5HmsDGC99kaA@mail.gmail.com>
 <20210202192417.ug32gmuc2uciik54@gmail.com>
 <8A686173-B3FF-4122-990C-6E8795D35161@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8A686173-B3FF-4122-990C-6E8795D35161@redhat.com>
Precedence: bulk

On Tue, Feb 02, 2021 at 02:49:38PM -0500, Benjamin Coddington wrote:
> On 2 Feb 2021, at 14:24, Dan Aloni wrote:
> > Also, what do you think would be a straightforward way for a userspace
> > program to find what sunrpc client id serves a mountpoint? If we add an
> > ioctl for the mountdir AFAIK it would be the first one that the NFS
> > client supports, so I wonder if there's a better interface that can work
> > for that.
> 
> I'm a fan of adding an ioctl interface for userspace, but I think we'd
> better avoid using NFS itself because it would be nice to someday implement
> an NFS "shutdown" for non-responsive servers, but sending any ioctl to the
> mountpoint could revalidate it, and we'd hang on the GETATTR.

For that, I was looking into using openat2() with the very recently
added RESOLVE_CACHED flag. However from some experimentation I see that it
still sleeps on the unresponsive mount in nfs_weak_revalidate(), and the
latter cannot tell whether LOOKUP_CACHED flag was passed to
d_weak_revalidate().

> Maybe we can figure out a way to expose the superblock via sysfs for each
> mount.

Essentially this is what fspick() syscall lets you do. I imagine that it
can be implemented entirely under fs/nfs, using fsconfig() from under a
FSCONFIG_SET_STRING passing a special string such as
"report-clients-ids", causing a list of sunrpc client IDs to get written
to the fs_context log.

However even with this interface we may still need to verify that the
path lookup that `fspick` does using `user_path_at` is not blocking on
non-responsive NFS mounts.

-- 
Dan Aloni