On Wed, 2016-08-31 at 09:24 -0400, nick wrote:

On 2016-08-31 03:54 AM, Catalin Marinas wrote:

quoted

On Tue, Aug 30, 2016 at 02:35:12PM -0400, Nicholas Krause wrote:

quoted

This fixes a issue in the current locking logic of the function,
__delete_object where we are trying to attempt to lock the passed
object structure's spinlock again after being previously held
elsewhere by the kmemleak code. Fix this by instead of assuming
we are the only one contending for the object's lock their are
possible other users and create two branches, one where we get
the lock when calling spin_trylock_irqsave on the object's lock
and the other when the lock is held else where by kmemleak.

Have you actually got a deadlock that requires this fix?

Yes I have got a deadlock that this does fix.

Why don't you share the backtrace with us?

Claiming you have a deadlock, but not sharing
it on the list means nobody can see what the
problem is you are trying to address.

It would be good if every email with a patch
that you post starts with an actual detailed
problem description.

Can you do that?

-- 

All Rights Reversed.