Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1223pxk; Wed, 2 Sep 2020 12:38:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBJ/NpdKBaGxctgZvmg8UYY7/3MimGpqnhuy8gyB24TttNaDBwPWbby6dk4fqFuOyCelMi X-Received: by 2002:a17:906:2c04:: with SMTP id e4mr1585938ejh.147.1599075538840; Wed, 02 Sep 2020 12:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599075538; cv=none; d=google.com; s=arc-20160816; b=RI6GElEGOWpjNZRlbt/A5wcI7JXaoOMyveOec73JVWfdn8RDU3ZZ3192cvPSDE18F8 49JxkO2S5J376BcEW9HQUzzhmlJi3gygCy2g0/key+B6EZ14FV3J2hnggf33MQwStqPu vI9vEtgIArwzDyG3HjAsQRYw0KcF9L5gnHdX/j2yRFz8BMCWa8v0N4lb5r12YV3MQADk kRaT+73QPlyCZoHEmCSIfNLVz8/CR/wonLlxiyjVr/1IN/LgAWM8S85hS69Cb/Sx3KFD GezfggwnIYOAC5fp6+ley/t4nVt1YZuXIhDiTOxLV0VF2Nbfh0AZj0XFSUNxD/0/XAez hEeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=4UOQrf/1Zuzh+bE0/siV6+xA8AEKujMA/kbnLKMMbYE=; b=z0suCsqyooEXrDl6YRDKaK5h40NmVOvEvZtg2NzAKYGkp7DEBAO8fI9E/+2EZyfIT7 E8s33rWSBFIBE/+OOQ9wAzm0L27ewYYl41cuO/XTuKP4syLRD6/n2k+Hj/CO1kq7rp/Y m6/jzd1Nr1VvH8O6sopMKX8pruVKWHe1rcyPvdpN7lYILerwQmVV8LuKjCsLq8kRfh0r 2b3e4HPPpukORnH9rKH1K8wFw23Vl1+5Cej1YmlPtpy7meFYVGGMC+bCy1fYnypQh9XQ h+glsfOHfRx934UowcRud8n2Gtk3SiFI4AFMrjrZuxfJSZHrywvVBaijJhAwz/wclhoA 0/xw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S0L8enuh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g3si360815ejw.227.2020.09.02.12.38.36; Wed, 02 Sep 2020 12:38:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=S0L8enuh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728005AbgIBSTl (ORCPT + 99 others); Wed, 2 Sep 2020 14:19:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726247AbgIBSTk (ORCPT ); Wed, 2 Sep 2020 14:19:40 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B36EC061244 for ; Wed, 2 Sep 2020 11:19:38 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id y11so331893lfl.5 for ; Wed, 02 Sep 2020 11:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4UOQrf/1Zuzh+bE0/siV6+xA8AEKujMA/kbnLKMMbYE=; b=S0L8enuhf0rblLouu8TzfTWlxrEfFtsBaukqEHzPXCMsnPPkHfqx2B5lhfOBH4Y1dp OS6eKvRVq7pHrnJg2iDw+kFEyA0yMb2GYevHYR6eLRg6yW5pWyPEd1qqvaX38pLOGrkx oBEFq14DIcUd9FTycvG7PD8HTSJVm2Fz8Uh/fYKNL1IxIoGjKvEQo4QHJoC0w12yw1Du 2r72o2ZSp/cepht/QKjhKEp30RORtY5gkWn2mh38SRUsqpBdd2HWMIuqWDnhnKk2vuVw 0COx77sts5iz0dkm9PTir7u+yKcV9n7kk3nOdRCjU70Pnybq28GcyX5wnPaUTNJjfLWb Du5w== 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; bh=4UOQrf/1Zuzh+bE0/siV6+xA8AEKujMA/kbnLKMMbYE=; b=r9LPgmxlsaLHcVphGF3VWAMsxkbt1InJ+oTMqloN0GV+hviwXJYe90aSW2/aBOhyy7 kgK+A/EVKn+MkaX+RuOLHh5yHV8rSLKqIm/44oP1qtzN2k985M5uz/rRUvXUO5nWYMPe H/aEarO0fkXynKw8DcOn3W+p02x9WQGpB19NlNJsq0tMcsj9pe/F/1NMxdh5+ZvKTInE kYed46pbwPHfSBlsDxg/SSZXB57lLgP9mwzs9WZZyc8iEE4hzqQtIGj0EyMl2AAsb0xL I5TfKaeZKtzadjDU7YTEj0GyjChCU32CYXNfjsDgEQQZoooxcI0yPwbXubfPHo8Syvf6 /Tmg== X-Gm-Message-State: AOAM530F7h0tQKmcxdub8tVh0T6yzwgyHO7GYUtAyXA9jrl8+gGE1XcS OdYMzrD0K/blmC3wPex2+1UfluOXJxfeLXtt0LQ= X-Received: by 2002:a19:7e02:: with SMTP id z2mr3938053lfc.130.1599070776561; Wed, 02 Sep 2020 11:19:36 -0700 (PDT) MIME-Version: 1.0 References: <20200823212550.3377591-1-nivedita@alum.mit.edu> <20200902153346.3296117-1-nivedita@alum.mit.edu> In-Reply-To: <20200902153346.3296117-1-nivedita@alum.mit.edu> From: Miguel Ojeda Date: Wed, 2 Sep 2020 20:19:25 +0200 Message-ID: Subject: Re: [PATCH v2] x86/asm: Replace __force_order with memory clobber To: Arvind Sankar Cc: Linus Torvalds , Sedat Dilek , Segher Boessenkool , Thomas Gleixner , Nick Desaulniers , "Paul E. McKenney" , Ingo Molnar , Arnd Bergmann , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "Kirill A. Shutemov" , Kees Cook , Peter Zijlstra , Juergen Gross , Andy Lutomirski , Andrew Cooper , LKML , clang-built-linux , Will Deacon , nadav.amit@gmail.com, Nathan Chancellor Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 2, 2020 at 5:33 PM Arvind Sankar wrote: > > + * The compiler should not reorder volatile asm, however older versions of GCC > + * had a bug (which was fixed in 8.1, 7.3 and 6.5) where they could sometimes > + * reorder volatile asm. The write functions are not a problem since they have > + * memory clobbers preventing reordering. To prevent reads from being reordered > + * with respect to writes, use a dummy memory operand. I see you added the information to the commit message, but I'd still reword this to something like: "The compiler should not reorder volatile asm, however GCC 4.9.x and 5.x have a bug where they could sometimes reorder volatile asm. The bug was fixed in 8.1, 7.3 and 6.5. The write functions are not a problem since they have memory clobbers preventing reordering. To prevent reads from being reordered with respect to writes, use a dummy memory operand." The important point is that 4.9.x and 5.x *have* the bug and that is the reason for having the hack. In the old wording it seems like the bug is no more. Then one wonders why the hack is still there (i.e. perhaps because we don't trust it, perhaps to support the rest of the minor versions which are newer, perhaps to avoid regressions, perhaps only the comment was updated, etc.). Cheers, Miguel