linux-kernel - Re: [PATCH] llist: Fix missing lockless

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]

Date:	Sat, 7 Feb 2015 16:09:55 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Huang Ying <ying.huang@...el.com>,
	linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>,
	Pranith Kumar <bobby.prani@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH] llist: Fix missing lockless_dereference()

On Sun, Feb 08, 2015 at 06:16:25AM +0800, Greg KH wrote:
> On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote:
> > A lockless_dereference() appears to be missing in llist_del_first().
> > It should only matter for Alpha in practice.
> 
> Meta-comment, do we really care about Alpha anymore?  Is it still
> consered an "active" arch we support?  I haven't seen a single
> alpha-related stable patch in _years_ if at all, which implies to me
> that no one is even using it.
> 
> Not that stable patches for architectures are a valid reference for how
> much they are used, but it does give me a good indication of what arches
> have users that actually care about a modern (i.e. within the past 5
> years) kernel.

I get a reasonable number of objections whenever I suggest something that
would cause problems for Alpha.  That said, my most recent suggestion
turns out to be mandated by recent versions of the C standard, so I think
that they have no choice but to get their compiler back-ends up to snuff.

(Before C11, a C compiler could legally compile a byte store as a
non-atomic read-modify-write sequence on the surrounding 32-bit quantity.
C11 and later outlaw this practice because it can introduce data races,
even in programs that use nothing but locking for synchronization.
The fix for this was introduced into gcc 4.7.)

							Thanx, Paul

--
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/