From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C30FC433F5 for ; Thu, 30 Aug 2018 09:51:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B96EE2073D for ; Thu, 30 Aug 2018 09:51:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B96EE2073D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728198AbeH3Nw4 (ORCPT ); Thu, 30 Aug 2018 09:52:56 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:38612 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727988AbeH3Nw4 (ORCPT ); Thu, 30 Aug 2018 09:52:56 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2881E7A9; Thu, 30 Aug 2018 02:51:37 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id ECC633F721; Thu, 30 Aug 2018 02:51:36 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 252941AE3490; Thu, 30 Aug 2018 10:51:49 +0100 (BST) Date: Thu, 30 Aug 2018 10:51:49 +0100 From: Will Deacon To: Peter Zijlstra Cc: Vineet Gupta , Eugeniy Paltsev , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "tglx@linutronix.de" , "linux-snps-arc@lists.infradead.org" , Alexey Brodkin , "yamada.masahiro@socionext.com" , "linux-arm-kernel@lists.infradead.org" , "linux-arch@vger.kernel.org" Subject: Re: Patch "asm-generic/bitops/lock.h: Rewrite using atomic_fetch_" causes kernel crash Message-ID: <20180830095148.GB5942@arm.com> References: <1535567633.4465.23.camel@synopsys.com> <20180830094411.GX24124@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180830094411.GX24124@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 30, 2018 at 11:44:11AM +0200, Peter Zijlstra wrote: > On Wed, Aug 29, 2018 at 09:16:43PM +0000, Vineet Gupta wrote: > > On 08/29/2018 11:33 AM, Eugeniy Paltsev wrote: > > > Hi Guys, > > > Since v4.19-rc1 we are getting a serious regression on platforms with ARC architecture. > > > The kernel have become unstable and spontaneously crashes on LTP tests execution / IO tests or > > > even on boot. > > > > > > I don't know exactly what breaks but bisect clearly assign the blame to this commit: > > > 84c6591103db ("locking/atomics, asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*()") > > > https://github.com/torvalds/linux/commit/84c6591103dbeaf393a092a3fc7b09510825f6b9 > > > > > > Reverting the commit solves this problem. > > > > > > I tested v4.19-rc1 on ARM (wandboard, i.mx6, 32bit, quard core, ARMv7) which uses same > > > generic bitops implementation and it works fine. > > > > > > Do you have any ideas what went wrong? > > > > Back in 2016, Peter had fixed this file due to a problem I reported on ARC. See > > commit f75d48644c56a ("bitops: Do not default to __clear_bit() for > > __clear_bit_unlock()") > > That made __clear_bit_unlock() use the atomic clear_bit() vs. non-atomic > > __clear_bit(), effectively making clear_bit_unlock() and __clear_bit_unlock() same. > > > > This patch undoes that which could explain the issues you see. @Peter, @Will ? > > Right, so the thinking is that on platforms that suffer that issue, > atomic_set*() should DTRT. And if you look at your spinlock based atomic > implementation, you'll note that atomic_set() does indeed do the right > thing. > > arch/arc/include/asm/atomic.h:108 Yeah, the bit_spin_lock()/__bit_spin_unlock() race described in f75d48644c56a boils down to concurrent atomic_long_set_release() vs atomic_long_fetch_or_acquire(), which really needs to work. I'll keep digging. In the meantime, Vineet, do you have any useful crash logs and do you only see the crashes in certain configurations (e.g. SMP but !CONFIG_ARC_HAS_LLSC)? Will