On Mon, 2022-05-23 at 19:35 +0000, Chuck Lever III wrote: > > > On May 23, 2022, at 1:38 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > On Mon, 2022-05-23 at 17:25 +0000, Chuck Lever III wrote: > > > > > > > On May 23, 2022, at 12:37 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > > > > > His suggestion was just to keep a counter in the lockowner of how many > > > > locks are associated with it. That seems like a good suggestion, though > > > > you'd probably need to add a parameter to lm_get_owner to indicate > > > > whether you were adding a new lock or just doing a conflock copy. > > > > > > locks_copy_conflock() would need to take a boolean parameter > > > that callers would set when they actually manipulate a lock. > > > > > > > Yep. You'd also have to add a bool arg to lm_put_owner so that you know > > whether you need to decrement the counter. > > It's the lm_put_owner() side that looks less than straightforward. > Suggestions and advice welcome there. > Maybe add a new fl_flags value that indicates that a particular lock is a conflock and not a lock record? Then locks_release_private could use that to pass the appropriate argument to lm_put_owner. That's probably simpler overall than trying to audit all of the locks_free_lock callers. -- Jeff Layton <jlayton@xxxxxxxxxx>
