Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758827AbbBHAKD (ORCPT ); Sat, 7 Feb 2015 19:10:03 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]:60819 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756039AbbBHAKB (ORCPT ); Sat, 7 Feb 2015 19:10:01 -0500 Date: Sat, 7 Feb 2015 16:09:55 -0800 From: "Paul E. McKenney" To: Greg KH Cc: Mathieu Desnoyers , Huang Ying , linux-kernel@vger.kernel.org, David Howells , Pranith Kumar , stable@vger.kernel.org Subject: Re: [PATCH] llist: Fix missing lockless_dereference() Message-ID: <20150208000955.GG5418@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1423274934-10625-1-git-send-email-mathieu.desnoyers@efficios.com> <20150207221625.GB31119@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150207221625.GB31119@kroah.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15020800-0021-0000-0000-000008618003 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1613 Lines: 33 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/