Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1112950yba; Tue, 2 Apr 2019 02:32:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZzJN+gJEgNe9qjxLT4+qBdCert2H2jddXtGF687AnGmn14ZRd1yl271enmvi0Ye+yP+5M X-Received: by 2002:a62:482:: with SMTP id 124mr64566672pfe.191.1554197570924; Tue, 02 Apr 2019 02:32:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554197570; cv=none; d=google.com; s=arc-20160816; b=aRYUo8IpRQPgRrmhcCpCD0Lb/GbW8LIhhUHg+Kbn7uleGjJNM78HhK4Nen6dKioFEE yd5CQcl0Fm7xXtxGG7LVcXggZ7jiGVjVL75aF53si4X8O5YmHjLhMscDm/sYouVnhQtn DfkGCFN1rxRa8ZUqpXolQNFxqC/EXW0f69puDnDFQUmCDvNki+0WiJs2Y0iQU+MTLy1y ParcK2+PUE46esvpbGmYZZvo6NH75v4LBSiaR8/N7WvuB3zqsO5w5oYTPuy0TQE13SBZ wvPFDEDVnTkUEHrP7j4EYWNLaWXAeHDtjH1jWqjkNAd+Wxm42MNtjNsPDGH+6op6NSJz /CAQ== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=dxJR51sd3lzu7/GkvEOOlaHvkyuImjHaHiMHEm4CQnc=; b=JjiMNLZ8gf1gZKAsNTctuwktDsKx3H1yfhbHwcelM4p6tjsx/hcrRuj6lCk14Z7G9k vlbAxfxRBLPBbrjzOkxT6dP+dDBDokKta4i0PP0fW/ijCcgz4EbpjL1UVEwVQs90q74f CcGkJZVqY8sM3d4Nxip1isPKVpVr7dGuW6HjuzwZa5Lh0RVNxS5AbEuIJvwWT1XMaZlz VKflEEvpuO2s8Se9+F+e9ZfuAXveJWK8/0mlJkH5LSWhBRFhwYvR23tO+/kpBfY1zw4z qLy0L95HfWDm0wpDttjWPaQDn0ZmSMdHLP3LhxRZRRuYgQPR7rB2Q+B3/1qWZ601iGpG Gw2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=lg2UWz3t; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k126si10854421pgk.109.2019.04.02.02.32.35; Tue, 02 Apr 2019 02:32:50 -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=pass header.i=@google.com header.s=20161025 header.b=lg2UWz3t; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729701AbfDBI7S (ORCPT + 99 others); Tue, 2 Apr 2019 04:59:18 -0400 Received: from mail-vs1-f67.google.com ([209.85.217.67]:43133 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729162AbfDBI7R (ORCPT ); Tue, 2 Apr 2019 04:59:17 -0400 Received: by mail-vs1-f67.google.com with SMTP id i207so7278626vsd.10 for ; Tue, 02 Apr 2019 01:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dxJR51sd3lzu7/GkvEOOlaHvkyuImjHaHiMHEm4CQnc=; b=lg2UWz3tyV8smhoQC59sB3bHcmqRvNsvigTSM7ZvF6zsi6GgenAOWySUIW46i8YPa5 OK/o9fAdMFoIMQHQ4eh2nkIgiqjgitlCrCgfF8OjK5O8hSm6xWsxdeGxFHIkySgxiNHt VLugPpMvLqU81ec3lqV+L3QchMKVCN239Hvfsg5vbzFz5nTMrytSoYbqDF/TNZdwWFve kaJxJs141S+29XSiDNS1gdC4eCKr/n3m+Z4u06kUrn6aE5zzXFvW3o9y3RcbQ/z+8DTe 8/4jyZF8QIfq680PcpcDF0BYEvGPxz+4KASCRVvrRSevjkunUlgyK493oRaQjq1seno/ z4fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dxJR51sd3lzu7/GkvEOOlaHvkyuImjHaHiMHEm4CQnc=; b=aGtNu7TA8ezl2ZdC4kRZ73Jsf8E+RC/GBn6uhUosBRlph6H5Kndn+UQUXOJEgT6hjG 2vpsfNGU8CGvhpZlrkNPbPtTZQBpssRG6WP7nCbEeKZf2sYMItd+edJV4PDbVT7mZCn/ g6jYo6LB/GkV3TZbCCuyeuGC5CI0FiaZna7l2usPOLXbhRyyJr1wPtLXPV74L3cPsANB MSbwwX/pflUlr+hd52oEP16+Cc7237k29ug6K2YV12Extf+cfDRjlBf5WzKftX6EH2MF 0+M/SqKW46ijv8K5doEE3bkgEhF4FMXAa7Jwd4iZmWPZFBxew8vsivAIu+dN1npoXRjB pD7g== X-Gm-Message-State: APjAAAWjZ1pQuvMvQ7lSdTk7d9WntN0s/wNbVjIEIhy2xNzXGiYqvVEG OzqSEqN+tHc/pZqy0/qhRJuvOtAwFhHvRsbb0QgTvA== X-Received: by 2002:a67:83c5:: with SMTP id f188mr40470869vsd.163.1554195556253; Tue, 02 Apr 2019 01:59:16 -0700 (PDT) MIME-Version: 1.0 References: <20190401162408.249668-1-glider@google.com> <20190402072659.GH12232@hirez.programming.kicks-ass.net> In-Reply-To: <20190402072659.GH12232@hirez.programming.kicks-ass.net> From: Alexander Potapenko Date: Tue, 2 Apr 2019 10:59:05 +0200 Message-ID: Subject: Re: [PATCH] x86/asm: use memory clobber in bitops that touch arbitrary memory To: Peter Zijlstra Cc: Paul McKenney , "H. Peter Anvin" , LKML , Dmitriy Vyukov , James Y Knight , x86@kernel.org, Ingo Molnar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 2, 2019 at 9:27 AM Peter Zijlstra wrote: > > > > On Mon, Apr 01, 2019 at 06:24:08PM +0200, Alexander Potapenko wrote: > > diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitop= s.h > > index d153d570bb04..20e4950827d9 100644 > > --- a/arch/x86/include/asm/bitops.h > > +++ b/arch/x86/include/asm/bitops.h > > @@ -111,7 +111,7 @@ clear_bit(long nr, volatile unsigned long *addr) > > } else { > > asm volatile(LOCK_PREFIX __ASM_SIZE(btr) " %1,%0" > > : BITOP_ADDR(addr) > > - : "Ir" (nr)); > > + : "Ir" (nr) : "memory"); > > } > > } > > clear_bit() doesn't have a return value, so why are we now still using > "+m" output ? You're right, "m" should suffice. I'll update the patch. By the way, now that we've added the memory barriers we can probably remove the barrier() call from __clear_bit_unlock() and update the comment accordingly. For clear_bit() the memory barrier is missing on the IS_IMMEDIATE(nr) path, so this one should be kept as is. > AFAICT the only reason we did that was to clobber the variable, which > you've (afaiu correctly) argued to be incorrect. > > So whould we not write this as: > > asm volatile (LOCK_PREFIX __ASM_SIZE(btr) " %[nr], %[addr]" > : : [addr] "m" (*addr), [nr] "Ir" (nr) > : "memory"); > > ? > > And the very same for _all_ other sites touched in this patch. --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg