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:   Tue, 1 Dec 2020 16:14:04 -0500
From:   "bfields@fieldses.org" <bfields@fieldses.org>
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "bfields@redhat.com" <bfields@redhat.com>,
        "chuck.lever@oracle.com" <chuck.lever@oracle.com>
Subject: Re: [PATCH 2/2] nfsd: Record NFSv4 pre/post-op attributes as
 non-atomic
Message-ID: <20201201211404.GE21355@fieldses.org>
References: <20201201041427.756749-1-trondmy@kernel.org>
 <20201201041427.756749-2-trondmy@kernel.org>
 <20201201193521.GA21355@fieldses.org>
 <63eaf3aab8814b2d65998123b6ba2e5b979a48d9.camel@hammerspace.com>
 <7181b1e7290dcfe4f92d9a8b00117a81b30f0cce.camel@hammerspace.com>
 <20201201205359.GC21355@fieldses.org>
 <34503d767cffb6b8ffc94dc80ae7632d38a7d68f.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <34503d767cffb6b8ffc94dc80ae7632d38a7d68f.camel@hammerspace.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Tue, Dec 01, 2020 at 08:59:00PM +0000, Trond Myklebust wrote:
> On Tue, 2020-12-01 at 15:53 -0500, bfields@fieldses.org wrote:
> > On Tue, Dec 01, 2020 at 08:27:38PM +0000, Trond Myklebust wrote:
> > > As far as I can tell, there is no need for it at all, since both
> > > the
> > > NFSv3 and NFSv4 client can supply atomic struct change_info4 in the
> > > cases where it is relevant (those cases being recording the changes
> > > to
> > > the parent directory/ies when doing CREATE, OPEN(O_CREAT), LINK,
> > > REMOVE
> > > and RENAME).
> > 
> > I was wondering about that.  We'd need some additional interface to
> > allow nfs to supply that stuff to nfsd, right?
> 
> The only problem is the pre-op attributes, since those are supplied by
> the server but never recorded anywhere. Otherwise, all you really need
> is to hold the inode lock on the directory to prevent the client from
> making updates after the operation is done.

We already have the lock over all those operations.

I was worried that wouldn't prevent a getattr in another thread from
updating the change attribute.  Is that not possible?

My only idea for returning extra information was a hack using
kthread_data() as we're doing in nfsd_breaker_owns_lease(); nfs would
call something like:

	void nfsd_set_cinfo(struct nfs4_change_info *cinfo)
	{
		struct svc_rqst *rqst;

		if (!i_am_nfsd())
			return;
		rqst = kthread_data(current);
		rqst->cinfo = cinfo;
	}

Then nfsd fetches it afterwards.  Maybe there's a better way.

--b.