On Mon, 2022-05-23 at 16:17 -0400, J. Bruce Fields wrote: > 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. > Probably not. Lock requests should also not be represented by struct file_lock, but that decision was made quite some time ago. We could change these things these days, but it'd be a lot of churn. Even if we did use a different struct for conflocks though, it would still need a way to point at the lockowner (or clone/free its info somehow). It wouldn't materially change what we need to do here. -- Jeff Layton <jlayton@xxxxxxxxxx>
