All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <waiman.long@hp.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: Linux 3.16-rc6
Date: Thu, 24 Jul 2014 16:38:28 -0400	[thread overview]
Message-ID: <53D16EC4.1000801@hp.com> (raw)
In-Reply-To: <20140724183643.GM3935@laptop>

On 07/24/2014 02:36 PM, Peter Zijlstra wrote:
> On Thu, Jul 24, 2014 at 11:18:16AM -0700, Linus Torvalds wrote:
>> On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra<peterz@infradead.org>  wrote:
>>> So going by the nifty picture rostedt made:
>>>
>>> [   61.454336]        CPU0                    CPU1
>>> [   61.454336]        ----                    ----
>>> [   61.454336]   lock(&(&p->alloc_lock)->rlock);
>>> [   61.454336]                                local_irq_disable();
>>> [   61.454336]                                lock(tasklist_lock);
>>> [   61.454336]                                lock(&(&p->alloc_lock)->rlock);
>>> [   61.454336]<Interrupt>
>>> [   61.454336]     lock(tasklist_lock);
>> So this *should* be fine. It always has been in the past, and it was
>> certainly the *intention* that it should continue to work with
>> qrwlock, even in the presense of pending writers on other cpu's.
>>
>> The qrwlock rules are that a read-lock in an interrupt is still going
>> to be unfair and succeed if there are other readers.
> Ah, indeed. Should have checked :/
>
>> So it sounds to me like the new lockdep rules in tip/master are too
>> strict and are throwing a false positive.
> Right. Waiman can you have a look?

Yes, I think I may have a solution for that.

Borislav, can you apply the following patch on top of the lockdep patch 
to see if it can fix the problem?

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index d24e433..507a8ce 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3595,6 +3595,12 @@ void lock_acquire(struct lockdep_map *lock, 
unsigned int
         raw_local_irq_save(flags);
         check_flags(flags);

+       /*
+        * An interrupt recursive read in interrupt context can be 
considered
+        * to be the same as a recursive read from checking perspective.
+        */
+       if ((read == 3) && in_interrupt())
+               read = 2;
         current->lockdep_recursion = 1;
         trace_lock_acquire(lock, subclass, trylock, read, check, 
nest_lock, ip);
         __lock_acquire(lock, subclass, trylock, read, check,


  reply	other threads:[~2014-07-24 20:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21  4:22 Linux 3.16-rc6 Linus Torvalds
2014-07-23  9:53 ` Borislav Petkov
2014-07-24  0:37   ` Linus Torvalds
2014-07-24  1:53     ` David Rientjes
2014-07-24  6:43     ` Peter Zijlstra
2014-07-24  8:41       ` Borislav Petkov
2014-07-24 12:25         ` Borislav Petkov
2014-07-24 12:58           ` Peter Zijlstra
2014-07-24 16:34             ` Borislav Petkov
2014-07-24 18:18             ` Linus Torvalds
2014-07-24 18:36               ` Peter Zijlstra
2014-07-24 20:38                 ` Waiman Long [this message]
2014-07-24 21:45                   ` Borislav Petkov
2014-07-25 17:23                     ` Waiman Long
2014-07-24 22:06                   ` John Stoffel
2014-07-24 22:06                     ` John Stoffel
2014-07-25 16:10                   ` Peter Zijlstra
2014-07-28 16:37                     ` Waiman Long
2014-07-28 16:42                       ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D16EC4.1000801@hp.com \
    --to=waiman.long@hp.com \
    --cc=bp@alien8.de \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.