lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1270001013.19685.6677.camel@gandalf.stny.rr.com>
Date:	Tue, 30 Mar 2010 22:03:33 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>, stable <stable@...nel.org>
Subject: Re: [PATCH] modules fix incorrect percpu usage

On Tue, 2010-03-30 at 16:24 -0400, Mathieu Desnoyers wrote:

> > Why do you beleive this should be backported to -stable?  What are the
> > user-visible effects of this change?
> > 
> 
> As for the user-visible impact of this specific patch, I guess nobody noticed
> any problem because we've been lucky enough that the compiler did not generate
> the inappropriate optimization pattern there.
> 
> This inappropriate use of per_cpu_ptr() elsewhere (in __module_ref_addr() from
> module.h) caused a NULL pointer exception on Randy's machine.
> 
> So either we consider that the code is better left untouched, or we apply this
> patch to module.c in order to prevent compiler optimizations from subtly
> breaking the generated assembly with specific configurations of the current or
> future versions of the compiler. At that level, it becomes a policy question
> about what should go in -stable, for which I will defer to Greg and you. I would
> perfectly understand if you consider that it does not belong to -stable, because
> there is no perceived user impact so far.

I don't know. A possible "NULL pointer dereference" seems to me to be a
pretty big user visible impact.

I guess the question is, what's the risk of adding this change?

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ