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. -- Jeff Layton <jlayton@xxxxxxxxxx>
