All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Greg KH <greg@kroah.com>
Cc: Tejun Heo <tj@kernel.org>, Randy Dunlap <randy.dunlap@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Peter Zijlstra <peterz@infradead.org>, stable <stable@kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Eric Dumazet <dada1@cosmosbay.com>, Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [stable] [PATCH] lockdep fix incorrect percpu usage
Date: Tue, 20 Apr 2010 10:33:50 -0400	[thread overview]
Message-ID: <20100420143350.GA14622@Krystal> (raw)
In-Reply-To: <20100419182936.GI32347@kroah.com>

* Greg KH (greg@kroah.com) wrote:
> On Wed, Mar 31, 2010 at 11:43:16AM +0900, Tejun Heo wrote:
> > On 03/31/2010 12:05 AM, Mathieu Desnoyers wrote:
> > > 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 ?
> > 
> > I'll push proper fixes to mainline in a few days.  For -stable, yeah,
> > probably.
> 
> Ok, did a patch ever end up in Linus's tree for this that I can pull
> into the -stable releases?
> 
> thanks,
> 
> greg k-h

Hi Greg,

Here is the updated patch, stating which mainline commit from Tejun fixes it by
refactoring the code. I'll leave the decision to pick this targeted fix or Tejun
refactoring into -stable up to you.


lockdep fix incorrect percpu usage

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.

It should be applied to stable 2.6.23.x to 2.6.33.x (or whichever of these
stable branches are still maintained).

The mainline kernel as of 2.6.34-rc5 is not affected by this problem because
commit 10fad5e46f6c7bdfb01b1a012380a38e3c6ab346 fixed it by refactoring.

(tested on 2.6.33.1 x86_64)

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Randy Dunlap <randy.dunlap@oracle.com>
CC: Eric Dumazet <dada1@cosmosbay.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Tejun Heo <tj@kernel.org>
CC: Ingo Molnar <mingo@elte.hu>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: stable <stable@kernel.org>
---
 kernel/lockdep.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux.trees.git/kernel/lockdep.c
===================================================================
--- linux.trees.git.orig/kernel/lockdep.c	2010-03-19 16:18:34.000000000 -0400
+++ linux.trees.git/kernel/lockdep.c	2010-03-30 09:48:43.000000000 -0400
@@ -600,9 +600,9 @@ static int static_obj(void *obj)
 	 * percpu var?
 	 */
 	for_each_possible_cpu(i) {
-		start = (unsigned long) &__per_cpu_start + per_cpu_offset(i);
-		end   = (unsigned long) &__per_cpu_start + PERCPU_ENOUGH_ROOM
-					+ per_cpu_offset(i);
+		start = (unsigned long) per_cpu_ptr(&__per_cpu_start, i);
+		end   = (unsigned long) per_cpu_ptr(&__per_cpu_start
+						    + PERCPU_ENOUGH_ROOM, i);
 
 		if ((addr >= start) && (addr < end))
 			return 1;


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2010-04-20 14:33 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
2010-03-31  2:43         ` Tejun Heo
2010-04-19 18:29           ` [stable] " Greg KH
2010-04-20 14:33             ` Mathieu Desnoyers [this message]
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=20100420143350.GA14622@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=greg@kroah.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.