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@xxxxxxx
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
