Re: [PATCH] usb: roles: Fix a false positive recursive locking complaint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux