Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752863AbaFJRqY (ORCPT ); Tue, 10 Jun 2014 13:46:24 -0400 Received: from mail-ve0-f179.google.com ([209.85.128.179]:42320 "EHLO mail-ve0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752509AbaFJRqX (ORCPT ); Tue, 10 Jun 2014 13:46:23 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 10 Jun 2014 10:46:22 -0700 X-Google-Sender-Auth: anoxhw8yRWJUiDh3-CHust6iPI8 Message-ID: Subject: Re: [PATCH] tell gcc optimizer to never introduce new data races From: Linus Torvalds To: Jiri Kosina Cc: "Paul E. McKenney" , Peter Zijlstra , Andrew Morton , Martin Jambor , Petr Mladek , Linux Kernel Mailing List , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina wrote: > We have been chasing a memory corruption bug, which turned out to be > caused by very old gcc (4.3.4), which happily turned conditional load into > a non-conditional one, and that broke correctness (the condition was met > only if lock was held) and corrupted memory. Just out of interest, can you point to the particular kernel code that caused this? I think that's more interesting than the example program you show - which I'm sure is really nice for gcc developers as an example, but from a kernel standpoint I think it's more important to show the particular problems this caused for the kernel? Linus -- 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/