On Tue, Dec 01, 2020 at 08:59:00PM +0000, Trond Myklebust wrote:
> On Tue, 2020-12-01 at 15:53 -0500, bfields@xxxxxxxxxxxx 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.
