On Mon, May 23, 2022 at 03:43:28PM -0400, Jeff Layton wrote: > 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. Should conflock parameters really be represented by file_lock structures at all? It always seemed a little wrong to me. But, that's a bit of derail, apologies. --b.
