On Wed, Feb 09, 2022 at 03:17:38PM -0500, Waiman Long wrote: > > On 2/9/22 14:45, Namhyung Kim wrote: > > On Wed, Feb 9, 2022 at 11:28 AM Mathieu Desnoyers > > <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > > ----- On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhyung@xxxxxxxxxx wrote: > > > > I'm also concerning dynamic allocated locks in a data structure. > > > > If we keep the info in a hash table, we should delete it when the > > > > lock is gone. I'm not sure we have a good place to hook it up all. > > > I was wondering about this use case as well. Can we make it mandatory to > > > declare the lock "class" (including the name) statically, even though the > > > lock per-se is allocated dynamically ? Then the initialization of the lock > > > embedded within the data structure would simply refer to the lock class > > > definition. > > Isn't it still the same if we have static lock classes that the entry needs > > to be deleted from the hash table when it frees the data structure? > > I'm more concerned about free than alloc as there seems to be no > > API to track that in a place. > > We may have to invent some new APIs to do that. For example, > spin_lock_exit() can be the counterpart of spin_lock_init() and so on. Of > course, existing kernel code have to be modified to designate the point > after which a lock is no longer being used or is freed. The canonical name is _destroy(). We even have mutex_destroy() except it's usage isn't mandatory. The easy way out is doing as lockdep does and hook into the memory allocators and check every free'd hunk of memory for a lock. It does hoever mean your data structure of choice needs to be able to answer: do I have an entry in @range. Which mostly disqualifies a hash-table. Still, I really don't think you need any of this, it's just bloat. A very limited stack unwind for one of the two tracepoints should allow you to find the offending lock just fine.
