lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 9 Feb 2022 15:17:38 -0500 From: Waiman Long <longman@...hat.com> To: Namhyung Kim <namhyung@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>, Boqun Feng <boqun.feng@...il.com>, linux-kernel <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, rostedt <rostedt@...dmis.org>, Byungchul Park <byungchul.park@....com>, Radoslaw Burny <rburny@...gle.com>, Tejun Heo <tj@...nel.org>, rcu <rcu@...r.kernel.org>, cgroups <cgroups@...r.kernel.org>, linux-btrfs <linux-btrfs@...r.kernel.org>, intel-gfx <intel-gfx@...ts.freedesktop.org>, paulmck <paulmck@...nel.org> Subject: Re: [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1) On 2/9/22 14:45, Namhyung Kim wrote: > On Wed, Feb 9, 2022 at 11:28 AM Mathieu Desnoyers > <mathieu.desnoyers@...icios.com> wrote: >> ----- On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhyung@...nel.org 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. Cheers, Longman
Powered by blists - more mailing lists