From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
ppc-dev <linuxppc-dev@lists.ozlabs.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: linux-next: PowerPC WARN_ON_ONCE() after merge of the final tree (tip related)
Date: Fri, 16 Apr 2010 14:32:12 +0200 [thread overview]
Message-ID: <20100416123208.GA5162@nowhere> (raw)
In-Reply-To: <1271414323.4807.1931.camel@twins>
On Fri, Apr 16, 2010 at 12:38:43PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-04-15 at 19:15 +0200, Frederic Weisbecker wrote:
> > > that looks rather ugly. Why not do a raw:
> > >
> > > this_cpu_inc(lockdep_stats.redundant_hardirqs_on);
> > >
> > > which basically open-codes debug_atomic_inc(), but without the warning?
> >
> >
> > Because that would open a race against interrupts that might
> > touch lockdep_stats.redundant_hardirqs_on too.
>
>
> How so, its a pure per-cpu variable right? so either the increment
> happens before the interrupts hits, or after, in either case there
> should not be a race with interrupts.
In x86 yeah, I guess the compiler simply loads the address
and does an inc directly, which is atomic wrt interrupts.
But what about another arch that would need an intermediate
load of the value:
load val, reg
add reg, 1
<---interrupt here
store reg, val
next prev parent reply other threads:[~2010-04-16 12:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-15 6:12 linux-next: boot failure after merge of the final tree (tip related) Stephen Rothwell
2010-04-15 6:48 ` Benjamin Herrenschmidt
2010-04-15 6:49 ` linux-next: PowerPC WARN_ON_ONCE() " Ingo Molnar
2010-04-15 6:55 ` David Miller
2010-04-15 7:32 ` Ingo Molnar
2010-04-16 1:51 ` Benjamin Herrenschmidt
2010-04-16 1:56 ` Benjamin Herrenschmidt
2010-04-15 10:04 ` Stephen Rothwell
2010-04-15 13:00 ` Frederic Weisbecker
2010-04-15 14:03 ` Ingo Molnar
2010-04-15 17:15 ` Frederic Weisbecker
2010-04-16 10:38 ` Peter Zijlstra
2010-04-16 12:32 ` Frederic Weisbecker [this message]
2010-04-15 17:24 ` Frederic Weisbecker
2010-04-15 17:39 ` 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=20100416123208.GA5162@nowhere \
--to=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).