All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Jan Beulich <jbeulich@novell.com>,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	linux-kernel@vger.kernel.org, Gautham R Shenoy <ego@in.ibm.com>
Subject: cpu hotplug and lockdep (was: Re: [tip:core/ipi] generic-ipi: eliminate spurious pointlessWARN_ON()s)
Date: Fri, 20 Mar 2009 20:34:48 +0100	[thread overview]
Message-ID: <1237577688.4667.68.camel@laptop> (raw)
In-Reply-To: <1237575134.4667.5.camel@laptop>

On Fri, 2009-03-20 at 19:52 +0100, Peter Zijlstra wrote:
> On Fri, 2009-03-20 at 19:24 +0100, Ingo Molnar wrote:
> > * Eric W. Biederman <ebiederm@xmission.com> wrote:
> > 
> > > Now back to my regularly scheduled hotunplug challenges starting 
> > > with getting lockdep to warn about the dead locks.
> 
> http://programming.kicks-ass.net/kernel-patches/cpu-hotplug/
> 
> The recursive read code needs more work.. 

You'll find some network softirq inversion 'fixes' there, but those are
false, (soft)irq recursion isn't a problem for recursive read locks, but
of course only as long as writes (and thereby all nesting exclusive
locks) are irq-safe so as to not create write in read deadlocks.

Just never gotten around to actually implementing that, ego also offered
to look at that at one point, but I guess he didn't get around to it
either ;-)


  reply	other threads:[~2009-03-20 19:35 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 13:21 [PATCH, resend] eliminate spurious pointless WARN_ON()s Jan Beulich
2009-03-12 13:48 ` Andi Kleen
2009-03-13  8:52   ` Peter Zijlstra
2009-03-13  1:39 ` [tip:core/ipi] generic-ipi: " Jan Beulich
2009-03-13  8:54   ` Peter Zijlstra
2009-03-13  9:21     ` [tip:core/ipi] generic-ipi: eliminate spurious pointlessWARN_ON()s Jan Beulich
2009-03-13  9:43       ` Peter Zijlstra
2009-03-13 10:38         ` Ingo Molnar
2009-03-19 22:14           ` Eric W. Biederman
2009-03-20  8:52             ` Ingo Molnar
2009-03-20  9:58               ` Eric W. Biederman
2009-03-20 18:24                 ` Ingo Molnar
2009-03-20 18:52                   ` Peter Zijlstra
2009-03-20 19:34                     ` Peter Zijlstra [this message]
2009-03-21  7:39                       ` [PATCH 0/2] sysctl: lockdep support Eric W. Biederman
2009-03-21  7:40                         ` [PATCH 1/2] sysctl: Don't take the use count of multiple heads at a time Eric W. Biederman
2009-03-21  7:42                           ` [PATCH 2/2] sysctl: lockdep support for sysctl reference counting Eric W. Biederman
2009-03-30 22:26                             ` Andrew Morton
2009-03-30 22:53                               ` Eric W. Biederman
2009-03-30 23:18                                 ` Andrew Morton
2009-03-30 23:50                                   ` Eric W. Biederman
2009-03-31  8:10                               ` Peter Zijlstra
2009-03-31  8:47                                 ` Eric W. Biederman
2009-03-31  8:17                             ` Peter Zijlstra
2009-03-31 13:40                               ` Eric W. Biederman
2009-03-31 15:35                                 ` Peter Zijlstra
2009-03-31 22:44                                   ` Eric W. Biederman
2009-04-10  9:18                             ` Andrew Morton
2009-03-20 23:40                     ` [tip:core/ipi] generic-ipi: eliminate spurious pointlessWARN_ON()s Eric W. Biederman
2009-03-21 10:20                       ` Peter Zijlstra
2009-03-13  9:31     ` [tip:core/ipi] generic-ipi: eliminate spurious pointless WARN_ON()s Ingo Molnar
2009-03-13 10:36 ` [tip:core/ipi] generic-ipi: eliminate WARN_ON()s during oops/panic Ingo Molnar
2009-03-13 10:36 ` [tip:core/ipi] panic: decrease oops_in_progress only after having done the panic Ingo Molnar
2009-03-13 10:36 ` [tip:core/ipi] panic, smp: provide smp_send_stop() wrapper on UP too Ingo Molnar
2009-03-13 10:36 ` [tip:core/ipi] panic: clean up kernel/panic.c Ingo Molnar

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=1237577688.4667.68.camel@laptop \
    --to=peterz@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=ego@in.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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.