On Thu, Sep 5, 2024 at 9:13 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > On Thu, Sep 5, 2024 at 6:01 PM Bart Van Assche <bvanassche@xxxxxxx> wrote: > > On 9/4/24 3:34 PM, Amit Sunil Dhamne wrote: > > > However, I have seen almost 30+ instances of the prior > > > method > > > (https://lore.kernel.org/all/20240822223717.253433-1-amitsd@xxxxxxxxxx/) > > > of registering lockdep key, which is what I followed. > > > > Many of these examples are for spinlocks. It would be good to have a > > variant of spin_lock_init() that does not instantiate a struct > > lock_class_key and instead accepts a lock_class_key pointer as argument. > > > > > However, if that's is not the right way, it brings into question the > > > purpose > > > of lockdep_set_class() considering I would always and unconditionally use > > > __mutex_init() if I want to manage the lockdep class keys myself or > > > mutex_init() if I didn't. > > What I'm proposing is not a new pattern. There are multiple examples > > in the kernel tree of lockdep_register_key() calls followed by a > > __mutex_init() call: > > > > $ git grep -wB3 __mutex_init | grep lockdep_register_key | wc -l > > 5 > > I see pros and cons for both approaches, but I take Bart's as the simpler one. > However, since it might be confusing, what I would suggest is to add a > respective wrapper to mutex.h and have a non-__ named macro for this > case. To be clear, something like #define mutex_init_with_lockdep(...) do { ... __mutex_init(); } while (0) in the mutex.h. -- With Best Regards, Andy Shevchenko
