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,
next prev parent 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.