Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1217350yba; Tue, 2 Apr 2019 04:54:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqwn6BMz59RQI9IQFpR8KpixynxZzVYMnAWoSUpOi6Qxou3Bfh1hW9BNU+SYfbuOcxdpkR1x X-Received: by 2002:a63:4101:: with SMTP id o1mr13628630pga.17.1554206076447; Tue, 02 Apr 2019 04:54:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554206076; cv=none; d=google.com; s=arc-20160816; b=m7L2ekMnAJJnWbX/PtEhb4Wh8ydugWYMpccsytLBtq5A0zD4i2BMJ3HXeF+DI8i/kw NkZ3YESXX4OfOfTSfzwhdKneP/P2vsV2kKYWsB4THp3ZBOuf/oG1PsWFsfGapf543BDR Zb7BvK0iyKDwVjRFxoVGwLpdtpdtRZrEIFU02podz8zatkBbXsK0e92G5UfzbaAnbMot 8Osv0imb292kDXNssTLkpwVzRHU0/JFEJgkChknSnxHyq3UXCyglZoLD4yPlauKuxm1m Sxj3fbQuhbQOalAfuEHfCZvLb2t3jnLJR49vys/lr3/sXnaXNAkiksU7hm6epA8UP2pk 9ibA== 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=zUjXHBpjHSxq+1LD4/mMegqIsw7rgr06JRKbCdsX+lk=; b=ggbRWpI67KIPJhcW9honcxhAgREYG8TAFiziOBoO64R02T/fw8QOnOwCE8AHkBlzaC UujYv3vsJZm8W5NcRl2pgKtcRuexvS/PT4j6zhgIB1/ThEllI6bUGFuxU7znBQR9tOeg KtU+lOWkR6gab689r5KMLFMdzi3iPvbrMKSoZruU2eGa98y7vPAr9HyCVUSa2BW0HxVN FVdrNFtqVsbzYyElyWidWOXN9Ddc98yMx8ie6oRNiUHKYswA+w3r7gHMJ6d9n4DfLwXg S/txA7cCbeVWbX9/e4wL6nRRB1esfwUgh112v6JRKRFQCebhYmPj7z6t4Suu5okAHI5O Rdjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QT6jpJCa; 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 cc18si11883784plb.363.2019.04.02.04.54.21; Tue, 02 Apr 2019 04:54:36 -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=QT6jpJCa; 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 S1730528AbfDBLcK (ORCPT + 99 others); Tue, 2 Apr 2019 07:32:10 -0400 Received: from mail-vs1-f68.google.com ([209.85.217.68]:44065 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730516AbfDBLcJ (ORCPT ); Tue, 2 Apr 2019 07:32:09 -0400 Received: by mail-vs1-f68.google.com with SMTP id j184so7533105vsd.11 for ; Tue, 02 Apr 2019 04:32:09 -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=zUjXHBpjHSxq+1LD4/mMegqIsw7rgr06JRKbCdsX+lk=; b=QT6jpJCaH1Ddd0JkqGvNiSjfSvzz4HbCdiXPoYN2+Yim5Df9TndLnrB05wmajX4kRt U3t9NmrREsnEYS+iGSLNaXuIbaLaDBcmSttg6Kw+PdjySyyp8mr0wut274zQbPQmEoaq vVsOzqvPY4tDrnz9eU8ufYL1fCKK2vAJnicIz6sxt73qeCZyEIWLXd+YQXF5AHwAN+Qd luj6rLNwpj6hcYHIbwu0wqXBhjmVGL+/bP1E4NHXRpSvlR195TF65hT2B909PcLK32lS LlbpYNZ9hHqpzPKO98DVXxXRsEN14uBYdk51BT/0AExWzKyRlIJNt8N7N4/Ks6owXKLG xnuQ== 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=zUjXHBpjHSxq+1LD4/mMegqIsw7rgr06JRKbCdsX+lk=; b=gLu7EnCUkSW4oYOCU1vqPT5yWv45FqQiXZYkiLpE2db9lRYH+AQz4leljBC7DUJv/T jwFkT+Bz1nRNiJd4Dhl/QbUeCDTJRCLTBihRuvV0KrJB3t/crBDG25TksiqW2ppeurLu R2Qvempd5E2OuuwGLfb7x7vJpkJs1muhVDupXLuAa2T0+3RzMf6+rx5AYhiPNTCjZAfr ff/+YEWfIbbBgdPZw/Ek/JVFgO20DVCGpplU8rytc0xxgQzrnGAOh8TgHLE0eLz7upqI +j1vn3LRd5ePrHPoAOu7d+728qqvNb6/oo2A/MwdctR056QI0pvYUsM+xHxAy++ZT5O/ snEA== X-Gm-Message-State: APjAAAXfP9js1h+DHoehfM/HEWf/RHSO5AwCFR46aUOY2T/Kk6atKW0L TOm6Yf5Nry7+n0Jt8SzAXcFhpZjMIx45WQyqwRhY2w== X-Received: by 2002:a67:ba03:: with SMTP id l3mr32723043vsn.96.1554204728590; Tue, 02 Apr 2019 04:32:08 -0700 (PDT) MIME-Version: 1.0 References: <20190401162408.249668-1-glider@google.com> <20190402072659.GH12232@hirez.programming.kicks-ass.net> In-Reply-To: From: Alexander Potapenko Date: Tue, 2 Apr 2019 13:31:57 +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 10:59 AM Alexander Potapenko wro= te: > > On Tue, Apr 2, 2019 at 9:27 AM Peter Zijlstra wrot= e: > > > > > > > > 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/bit= ops.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"); Updated the patch. I took the liberty of not adding the symbolic names to reduce the diff. If you think that's necessary I can do that in a separate patch. > > ? > > > > And the very same for _all_ other sites touched in this patch. > > > > -- > 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 --=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