Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp12020165ybi; Fri, 26 Jul 2019 03:28:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqxed0+V1HD5pguJPJWtcmjo8Jd9f1XQGo3kJQFlHnIx37dUCQ59522ZB87oosVt/ld1naOT X-Received: by 2002:a17:902:bd06:: with SMTP id p6mr98211851pls.189.1564136884565; Fri, 26 Jul 2019 03:28:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564136884; cv=none; d=google.com; s=arc-20160816; b=RpChyc45D6895mHs1EP94RETGP5JyzavniXMV7ommADaYZG2NAPDnDi4wAhS7AsqEx obqmVV4I9T84M2vhCKEDsZx8GRM1nnlbpVgsKK6q0mtz93yLiTG1Luh7bHM9x2g6+N0U s20gkzHXkOnbwMk4crtCcn5orpZAS/x8gKTb5dxAQwVFCAXo3vMEiRyYwTk3q8Zeprep JQB8rS+0Vb0Y5aNmY50s2W7tML97MJeao8xALzEXRQAMFmZZQSbvNJlKQiRuUFnBJFMK hR5ygINOCCQNwDbqN/88pr6MCTdATkInbFBZoWr4vcwiyI2CMTqKvy7kM/d5y/EoKBBU LqBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:references :subject:cc:to:mime-version:from:date:message-id; bh=locjuxA+B6LFcRAmIH8a7DnCCvqk9o6gd8vnLIngEhM=; b=e075Cqj2S4VEiRr2csFo7h4JqaPeNNHXSgW+5QzO/tODepHAKMa1lW8Xhc4Ds3pr/Q nLD5yEVkPdaW0ythhmxUwrhXkQfz3KQ6kK8tafx6IrbqU+P0tWyfB6UERjtM93x/Rzub xpqXE3JNNfV139xTzwV1ngqvV+iDtKBHvOdcLTx7fqCAI6k2iXv5CsPPJw+S6BDfOUAf kzKC8RO67iPBilgnvGkpMgTJrIPlZer7SMr5gFBclNA0Ak327g3bMwobIgZVHWQDq8wG 7DrVa2cAUxstax68ben+apf9DLLWYUmFpqGSpZL1d5DJYyDrbG9YENrGsUkeiMzDfRgU v3uQ== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r11si21404943pjq.108.2019.07.26.03.27.49; Fri, 26 Jul 2019 03:28:04 -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; 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726417AbfGZKZY (ORCPT + 99 others); Fri, 26 Jul 2019 06:25:24 -0400 Received: from emh04.mail.saunalahti.fi ([62.142.5.110]:33226 "EHLO emh04.mail.saunalahti.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbfGZKZY (ORCPT ); Fri, 26 Jul 2019 06:25:24 -0400 X-Greylist: delayed 424 seconds by postgrey-1.27 at vger.kernel.org; Fri, 26 Jul 2019 06:25:22 EDT Received: from toshiba (85-76-77-1-nat.elisa-mobile.fi [85.76.77.1]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 3008430034; Fri, 26 Jul 2019 13:18:17 +0300 (EEST) Message-ID: <5D3AD35E.FB77B44F@gmail.com> Date: Fri, 26 Jul 2019 13:18:06 +0300 From: Jari Ruusu MIME-Version: 1.0 To: Greg Kroah-Hartman CC: linux-kernel@vger.kernel.org, stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Linus Torvalds , Thomas Gleixner , Ingo Molnar , Sasha Levin Subject: Re: [PATCH 4.19 079/271] x86/atomic: Fix smp_mb__{before,after}_atomic() References: <20190724191655.268628197@linuxfoundation.org> <20190724191701.954991110@linuxfoundation.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Greg Kroah-Hartman wrote: > [ Upstream commit 69d927bba39517d0980462efc051875b7f4db185 ] > > Recent probing at the Linux Kernel Memory Model uncovered a > 'surprise'. Strongly ordered architectures where the atomic RmW > primitive implies full memory ordering and > smp_mb__{before,after}_atomic() are a simple barrier() (such as x86) > fail for: > > *x = 1; > atomic_inc(u); > smp_mb__after_atomic(); > r0 = *y; [snip] > --- a/arch/x86/include/asm/atomic.h > +++ b/arch/x86/include/asm/atomic.h > @@ -54,7 +54,7 @@ static __always_inline void arch_atomic_add(int i, atomic_t *v) > { > asm volatile(LOCK_PREFIX "addl %1,%0" > : "+m" (v->counter) > - : "ir" (i)); > + : "ir" (i) : "memory"); > } > > /** Shouldn't those clobber contraints actually be: "memory","cc" That is because addl subl (and other) machine instructions actually modify the flags register too. gcc docs say: The "cc" clobber indicates that the assembler code modifies the flags register. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189