On Mon, May 23, 2022 at 05:28:16PM -0400, J. Bruce Fields wrote:
> On Mon, May 23, 2022 at 05:15:55PM -0400, Jeff Layton wrote:
> > On Mon, 2022-05-23 at 16:29 -0400, J. Bruce Fields wrote:
> > > On Mon, May 23, 2022 at 03:36:27PM -0400, Jeff Layton wrote:
> > > > The other lockowner _is_ involved. It's the one holding the conflicting
> > > > lock. nfs4_set_lock_denied copies info from the conflicting lockowner
> > > > into the LOCK/LOCKT response. That's safe now because it holds a
> > > > reference to the owner. At one point it wasn't (see commit aef9583b234a4
> > > > "NFSD: Get reference of lockowner when coping file_lock", which fixed
> > > > that).
> > >
> > > I doubt that commit fixed the whole problem, for what it's worth. What
> > > if the client holding the conflicting lock expires before we get to
> > > nfs4_set_lock_denied?
> > >
> >
> > Good point -- stateowners can't hold a client reference.
> >
> > clientid_t is 64 bits, so one thing we could do is just keep a copy of
> > that in the lockowner. That way we wouldn't need to dereference
> > so_client in nfs4_set_lock_denied.
> >
> > Maybe there are better ways to fix it though.
>
> I kinda feel like lock and testlock should both take a
>
> struct conflock {
> void *data
> void (*copier)(struct file_lock, struct conflock)
> }
>
> and the caller should provide a "copier" that they can use to extract
> the data they want while the flc_lock is held.
>
> I'm probably overthinking it.
But in any case note the problem isn't just the copy of the clientid_t;
nfs4_put_stateowner also dereferences the client.
--b.
