All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Randy Dunlap <randy.dunlap@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	stable <stable@kernel.org>, Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, Eric Dumazet <dada1@cosmosbay.com>,
	Tejun Heo <tj@kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [stable] [PATCH 2.6.29.x - 2.6.31.1] module: fix __module_ref_addr()
Date: Mon, 19 Apr 2010 11:26:43 -0700	[thread overview]
Message-ID: <20100419182643.GG32347@kroah.com> (raw)
In-Reply-To: <20100330022238.GA7480@Krystal>

On Mon, Mar 29, 2010 at 10:22:38PM -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> > On Mon, 2010-03-29 at 14:07 -0700, Greg KH wrote:
> > > On Mon, Mar 29, 2010 at 04:09:46PM -0400, Mathieu Desnoyers wrote:
> > > > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > > > > This patch does not apply to 2.6.34-rc, and the code in upstream looks
> > > > > to have been fixed. Should this go to stable?
> > > > 
> > > > Yes. 2.6.34-rc does not have this issue anymore, but the patch is needed in
> > > > -stable.
> > > 
> > > Why is this not in .34-rc2?  Can you find the specific patch in Linus's
> > > tree that solves this and let stable@kernel.org know about it?
> > > 
> > 
> > Looks like it was this commit:
> > 
> > commit e1783a240f491fb233f04edc042e16b18a7a79ba
> > Author: Christoph Lameter <cl@linux-foundation.org>
> > Date:   Tue Jan 5 15:34:50 2010 +0900
> > module: Use this_cpu_xx to dynamically allocate counters
> > 
> > Mathieu's fix was:
> > 
> > -   return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> > +   return (local_t *) per_cpu_ptr(mod->refptr, cpu);
> > 
> > As Mathieu states in his change log, the bug is that the mod->refptr is
> > outside the assembly obfuscation of the per_cpu_offset(). This allows
> > the compiler to optimize and cause a NULL pointer dereference with the
> > manipulation of per cpu data.
> > 
> > Christoph Lameter's change fixes this bug as a side effect:
> > 
> > -static inline local_t *__module_ref_addr(struct module *mod, int cpu)
> > -{
> > -#ifdef CONFIG_SMP
> > -       return (local_t *) (mod->refptr + per_cpu_offset(cpu));
> > -#else
> > -       return &mod->ref;
> > -#endif
> > -}
> > -
> >  /* Sometimes we know we already have a refcount, and it's easier not
> >     to handle the error case (which only happens with rmmod --wait). */
> >  static inline void __module_get(struct module *module)
> >  {
> >         if (module) {
> > -               unsigned int cpu = get_cpu();
> > -               local_inc(__module_ref_addr(module, cpu));
> > +               preempt_disable();
> > +               __this_cpu_inc(module->refptr->count);
> >                 trace_module_get(module, _THIS_IP_,
> > -                                local_read(__module_ref_addr(module, cpu)));
> > -               put_cpu();
> > +                                __this_cpu_read(module->refptr->count));
> > +               preempt_enable();
> >         }
> >  }
> > 
> > By removing the buggy code all together.
> 
> Exactly. Steven has beaten me on the start line on this one. ;)

Ok, I'm totally confused now :(

What patch should I apply to a stable release, and which stable release?

thanks,

greg k-h

  reply	other threads:[~2010-04-19 18:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-27 14:31 [PATCH 2.6.29.x - 2.6.31.1] module: fix __module_ref_addr() Mathieu Desnoyers
2010-03-29 19:21 ` Steven Rostedt
2010-03-29 20:09   ` Mathieu Desnoyers
2010-03-29 21:07     ` [stable] " Greg KH
2010-03-30  1:08       ` Steven Rostedt
2010-03-30  2:22         ` Mathieu Desnoyers
2010-04-19 18:26           ` Greg KH [this message]
2010-04-20 14:38             ` Mathieu Desnoyers
2010-03-30  2:12       ` Tejun Heo
2010-03-30  2:34         ` Tejun Heo
2010-03-30  3:04           ` Mathieu Desnoyers

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=20100419182643.GG32347@kroah.com \
    --to=greg@kroah.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --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.