Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6586447yba; Tue, 14 May 2019 09:58:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqxaGZrsKbcvf8J+JhpV37SArdHvyTCNJ6aofJ+/JOwMjZmzXOlMMB/fMSL9Xhqoys828W4x X-Received: by 2002:a63:d252:: with SMTP id t18mr39594946pgi.131.1557853139394; Tue, 14 May 2019 09:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557853139; cv=none; d=google.com; s=arc-20160816; b=VeLfpVOA3GWyy/gLEgiwRz7Chnl/mb9ySCyILjxzFY8J33yB+9PyUnbeV+1Gd1mthO 9LI3Wd0skCVzP78EbehVaI2I8bWyQO13X+LhEA6mATpmUQ1jBytZrgSbZxg/JUoNtJ+7 AfFIEoLMUt30WMMcTCZ8Vjd0BnadnSBixeMMQ57tP9XZ9UVsEn5HN9ZTS6ZkCdacjIEg ulYroZp3XZaB4RXKj5eNicMaqv4uEW6t4faY985evBhAdKwq/Tz9Aj8OTemhHED7jbAe mYZL8F9cKydA8JHAROTyl8Q58SDjJk1ub4kfb6S//jTMSB7jFuMhLjeS4dsRGLFBiO6W xZ+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QEzjc5Av74DO6+A4a5nv3t2hw4nojszLXPYtxmG0GVc=; b=H3UeYwff2O0lqkRiuO7fFicX+EGwhJcISV+a/Y6WoE3QHcyrVYGbX+AtCqjk+gGdA/ WjjwnMQgDI0tUNdJw3X0tsZcbomzJyTLZC2GFbAv2nR44XjrrOVXEyLWvFs0+PWrd6k/ T3TLAwuOjgwFQouZlS7U2lSpAuS3lDlzAbY2GVlRQsqAVOlajAl59en5UuK9GPg6GuvN 6TMM9UdFK5qVDRTTTqVVGk+OFTbxUYFURvNqgjybfcjjMs1n9/yYERfteugqbTrxWzx+ 0PsbCvAcx3yu7/1HSxZMWaKJ0LaHCosItYl0uuUlWKTfS9CWe15ffXdzi8dzA2HHt8gH YdSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=yufZ3579; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c4si20958624pgn.428.2019.05.14.09.58.44; Tue, 14 May 2019 09:58:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=yufZ3579; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726383AbfENQ4m (ORCPT + 99 others); Tue, 14 May 2019 12:56:42 -0400 Received: from merlin.infradead.org ([205.233.59.134]:38842 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726013AbfENQ4l (ORCPT ); Tue, 14 May 2019 12:56:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QEzjc5Av74DO6+A4a5nv3t2hw4nojszLXPYtxmG0GVc=; b=yufZ3579mTxJxqVm3UxjtQD5j G8gnyWLZ5h5cEkEO2hNZMzp8py+tonmJgQolp3P05OwN049WGISW3OsAuqrUyIA/zfBum0nxgptif toCmg+dlWfxO+b5fjFDTOMTKs6IGnHSidITxnShgHAQFw55M4sZH75X0FtdN6Y58kgTir44IqKXQ+ L20srlxad08fg4EnlYlOwdJYhYtUIDzxJxAoWNRCRG5pzAeaoUe6FXVd/Ts/QWiWVLlC+T4WKLhm+ h5ItBx83ee2mkL0+wlF+jTgE2QHagl6e202XlHLleqZHHazKHE0z39jOiu+aEv1JahvvjWNjnTWzj b0L9Pb4ug==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hQaiu-0000rQ-7W; Tue, 14 May 2019 16:56:16 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5BBDA2029F888; Tue, 14 May 2019 18:56:14 +0200 (CEST) Date: Tue, 14 May 2019 18:56:14 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: huangpei@loongson.cn, Paul Burton , "stern@rowland.harvard.edu" , "akiyks@gmail.com" , "andrea.parri@amarulasolutions.com" , "boqun.feng@gmail.com" , "dlustig@nvidia.com" , "dhowells@redhat.com" , "j.alglave@ucl.ac.uk" , "luc.maranget@inria.fr" , "npiggin@gmail.com" , "paulmck@linux.ibm.com" , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , Huacai Chen Subject: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage Message-ID: <20190514165614.GV2623@hirez.programming.kicks-ass.net> References: <20190424123656.484227701@infradead.org> <20190424124421.636767843@infradead.org> <20190424211759.52xraajqwudc2fza@pburton-laptop> <2b2b07cc.bf42.16a52dc4e4d.Coremail.huangpei@loongson.cn> <20190425073348.GV11158@hirez.programming.kicks-ass.net> <20190425091258.GC14281@hirez.programming.kicks-ass.net> <20190514155813.GG2677@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 14, 2019 at 09:10:34AM -0700, Linus Torvalds wrote: > On Tue, May 14, 2019 at 8:58 AM Peter Zijlstra wrote: > > > > So if two variables share a line, and one is local while the other is > > shared atomic, can contention on the line, but not the variable, cause > > issues for the local variable? > > > > If not; why not? Because so far the issue is line granular due to the > > coherence aspect. > > If I understood the issue correctly, it's not that cache coherence > doesn't work, it's literally that the sc succeeds when it shouldn't. > > In other words, it's not going to affect anything else, but it means > that "ll/sc" isn't actually truly atomic, because the cacheline could > have bounced around to another CPU in the meantime. > > So we *think* we got an atomic update, but didn't, and the "ll/sc" > pair ends up incorrectly working as a regular "load -> store" pair, > because the "sc' incorrectly thought it still had exclusive access to > the line from the "ll". > > The added memory barrier isn't because it's a memory barrier, it's > just keeping the subsequent speculative instructions from getting the > cacheline back and causing that "sc" confusion. > > But note how from a cache coherency standpoint, it's not about the > cache coherency being wrong, it's literally just about the ll/sc not > giving the atomicity guarantees that the sequence is *supposed* to > give. So an "atomic_inc()" can basically (under just the wrong > circumstances) essentially turn into just a non-atomic "*p++". Understood; the problem is that "*p++" is not good enough for local_t either (on load-store architectures), since it needs to be "atomic" wrt all other instructions on that CPU, most notably exceptions. The issue has come up before in this thread; but I don't think it was clearly answered before.