Re: [PATCH 2/2] nfsd: Record NFSv4 pre/post-op attributes as non-atomic

["bfields@fieldses.org" <bfields@fieldses.org>]

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.