On 2023-08-18 19:24, Joerg Roedel wrote:
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.
Furthermore I'd say it's one thing to have deadlocks or warnings slip in
as part of some functional change, but quite another when the change is
solely reworking the locking in an attempt to make it better. This is
clearly not better.
Thanks,
Robin.
