Re: [PATCH v2 0/4] Fix device_lock deadlock on two probe() paths

[Joerg Roedel <jroedel@suse.de>]

On Fri, Aug 18, 2023 at 01:06:43PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 18, 2023 at 05:56:20PM +0200, Joerg Roedel wrote:
> > On Thu, Aug 17, 2023 at 03:33:16PM -0300, Jason Gunthorpe wrote:
> > > Bascially.. Yikes!
> > 
> > Hmm, that is a difficult situation. Even if the problem is a misuse of
> > the APIs we can not just blindly break other drivers by our core
> > changes.
> 
> They are not broken, they just throw a lockdep warning and keep going
> as before. This is what triggers:
> 
> static inline void device_lock_assert(struct device *dev)
> {
> 	lockdep_assert_held(&dev->mutex);
> }
> 
> So non-debug builds won't even see anything.

But this still means that a function is called without holding the
proper lock.

> Historically we've tolerated lockdep warnings as a way to motivate
> people who care to fix their stuff properly. eg the Intel VT-D had a
> lockdep warning at kernel boot for many releases before it was fixed.

There is a difference between knowingly introducing new lockdep warnings
into upstream and letting warnings discovered upstream rot for a while.

I can't send anything with known problems upstream.

Regards,

-- 
Jörg Rödel
jroedel@suse.de

SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman