Thread (11 messages) 11 messages, 4 authors, 2016-09-07

Re: [PATCH] mm:Avoid soft lockup due to possible attempt of double locking object's lock in __delete_object

From: nick <hidden>
Date: 2016-08-31 21:28:46


On 2016-08-31 05:08 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 31 Aug 2016 08:54:21 +0100, Catalin Marinas said:
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?
Almost certainly not, but that's never stopped Nicholas before.  He's a well-known
submitter of bad patches, usually totally incorrect, not even compile tested.

He's infamous enough that he's not allowed to post to any list hosted at vger.
Valdis,
Rather then argue since that will go nowhere. I am posing actual patches that have been tested on
hardware. Yes I known that is surprising but it's true.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help