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_
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 again
On Wed, 2010-04-14 at 23:55 -0700, David Miller wrote:
> From: Ingo Molnar
> Date: Thu, 15 Apr 2010 08:49:40 +0200
>
> > Btw., WARN_ON trapping on PowerPC is clearly a PowerPC bug - there's a good
> > reason we have WARN_ON versus BUG_ON - it should be fixed.
>
> I disagree, an implementation s
On Thu, 2010-04-15 at 09:32 +0200, Ingo Molnar wrote:
> It trades robustness for slightly better space/code efficiency.
>
> Such a trap based mechanism exists on x86 as well and we use it for BUG_ON().
> We intentionally dont use it to generate warnings and dont override __WARN(),
> because it w
* Frederic Weisbecker wrote:
> On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote:
> > >
> > >
> > > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > > index 78325f8..65d4336 100644
> > > --- a/kernel/lockdep.c
> > > +++ b/kernel/lockdep.c
> > > @@ -2298,7 +2298,11 @@ void trace_h
On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote:
> >
> >
> > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > index 78325f8..65d4336 100644
> > --- a/kernel/lockdep.c
> > +++ b/kernel/lockdep.c
> > @@ -2298,7 +2298,11 @@ void trace_hardirqs_on_caller(unsigned long ip)
> >
On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote:
> > In this case, I guess the following fix should be sufficient?
> > I'm going to test it and provide a sane changelog.
> >
> >
> > diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> > index 78325f8..65d4336 100644
> > --- a/kernel/loc
* Frederic Weisbecker wrote:
> On Thu, Apr 15, 2010 at 08:49:40AM +0200, Ingo Molnar wrote:
> >
> > * Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
> > >
> > > [ cut here ]
> > > Badness at
On Thu, Apr 15, 2010 at 08:49:40AM +0200, Ingo Molnar wrote:
>
> * Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
> >
> > [ cut here ]
> > Badness at kernel/lockdep.c:2301
> > NIP: c00a35c8 LR:
Hi Ingo,
On Thu, 15 Apr 2010 08:49:40 +0200 Ingo Molnar wrote:
>
> Ok, we'll fix the warning.
Thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpGux6Rr8FG8.pgp
Description: PGP signature
__
* Stephen Rothwell wrote:
> Hi all,
>
> Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
>
> [ cut here ]
> Badness at kernel/lockdep.c:2301
> NIP: c00a35c8 LR: c00084c4 CTR:
> REGS: c0bf77e0 TRAP: 0700 Not
* David Miller wrote:
> From: Ingo Molnar
> Date: Thu, 15 Apr 2010 08:49:40 +0200
>
> > Btw., WARN_ON trapping on PowerPC is clearly a PowerPC bug - there's a good
> > reason we have WARN_ON versus BUG_ON - it should be fixed.
>
> I disagree, an implementation should be allowed to use the mo
From: Ingo Molnar
Date: Thu, 15 Apr 2010 08:49:40 +0200
> Btw., WARN_ON trapping on PowerPC is clearly a PowerPC bug - there's a good
> reason we have WARN_ON versus BUG_ON - it should be fixed.
I disagree, an implementation should be allowed to use the most
efficient implementation possible fo
13 matches
Mail list logo
