From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org,
Randy Dunlap <randy.dunlap@oracle.com>,
Eric Dumazet <dada1@cosmosbay.com>,
Rusty Russell <rusty@rustcorp.com.au>, Tejun Heo <tj@kernel.org>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Steven Rostedt <rostedt@goodmis.org>, stable <stable@kernel.org>
Subject: Re: [PATCH] lockdep fix incorrect percpu usage
Date: Tue, 30 Mar 2010 11:05:51 -0400 [thread overview]
Message-ID: <20100330150551.GA22312@Krystal> (raw)
In-Reply-To: <1269959111.5258.142.camel@laptop>
* Peter Zijlstra (peterz@infradead.org) wrote:
> On Tue, 2010-03-30 at 09:45 -0400, Mathieu Desnoyers wrote:
> > * Peter Zijlstra (peterz@infradead.org) wrote:
> > > On Mon, 2010-03-29 at 23:34 -0400, Mathieu Desnoyers wrote:
> > > > Should use per_cpu_ptr() to obfuscate the per cpu pointers (RELOC_HIDE is needed
> > > > for per cpu pointers).
> > > >
> > > > git blame points to commit:
> > > >
> > > > lockdep.c: commit 8e18257d29238311e82085152741f0c3aa18b74d
> > > >
> > > > But it's really just moving the code around. But it's enough to say that the
> > > > problems appeared before Jul 19 01:48:54 2007, which brings us back to 2.6.23.
> > > >
> > > > So it should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these
> > > > stable branches are still maintained) and to mainline 2.6.34-rc2.
> > >
> > > well, definately not to mainline, since that code is utterly busted in
> > > mainline due to recent per-cpu changes.
> >
> > How recent ? I'm based on
> >
> > commit f57d4e859a8acd63f878cd0534ec4b990b1710dc
> > Merge: 0528faa... eed6351...
> > Author: Ingo Molnar <mingo@elte.hu>
> > Date: Mon Mar 29 18:56:00 2010 +0200
> >
> > from -tip and I see the problem there, both in module.c and lockdep.c.
>
> Yeah, its basically been busted since the early merge window period,
> hopefully Tejun's patches will make it in soon:
>
> http://lkml.org/lkml/2010/3/10/79
I see. These patches are "on their way" to mainline, so it's better not to
create conflicts. So the lockdep patch should only be applied to -stable, but
separate module.c patch should apply to both -stable and mainline. Am I
correct ?
Thanks,
Mathieu
>
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-03-30 15:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 3:34 [PATCH] lockdep fix incorrect percpu usage Mathieu Desnoyers
2010-03-30 8:47 ` Peter Zijlstra
2010-03-30 13:45 ` Mathieu Desnoyers
2010-03-30 14:25 ` Peter Zijlstra
2010-03-30 15:05 ` Mathieu Desnoyers [this message]
2010-03-31 2:43 ` Tejun Heo
2010-04-19 18:29 ` [stable] " Greg KH
2010-04-20 14:33 ` Mathieu Desnoyers
2010-04-21 10:52 ` Tejun Heo
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=20100330150551.GA22312@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=randy.dunlap@oracle.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=stable@kernel.org \
--cc=tj@kernel.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.