From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87669C4743C for ; Fri, 4 Jun 2021 17:39:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 70AF2610C7 for ; Fri, 4 Jun 2021 17:39:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229930AbhFDRlG (ORCPT ); Fri, 4 Jun 2021 13:41:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229864AbhFDRlF (ORCPT ); Fri, 4 Jun 2021 13:41:05 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C9DAC061766 for ; Fri, 4 Jun 2021 10:39:03 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id u22so12564708ljh.7 for ; Fri, 04 Jun 2021 10:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n9fPMUfjUiK0FrRER6EH6PeTXMziUWqxljccly8zx7c=; b=MJ0NfISVyYy/x/kclYN0s9fJRn5RliOT0U+w0BfCWBnLtWRtfPyvQRs2IIykEPgYRA iPmdQbb2zzRdZQzIE2X5p3HF4kbmJgxzs1DJCeD2N6RMTL7zDRAxmbT8zPfNnpdiIRZD KX2qRRFcTYEo6EAz4KL2o5iAZ1t2awg7AqCwY= 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=n9fPMUfjUiK0FrRER6EH6PeTXMziUWqxljccly8zx7c=; b=uByxfP5iwYKiRy9Qw4U7AqXUSohHEsQxJkLh9sHC/z5xbMaWZoV5nU7Uw8JXfzq4n9 oJ3FuyOKsNlQi6/i2Zmvgj8A1NsxpKzOJ4p97t2wy3CLymrEBXF8XtMIGw4hNH6IjKFy C2w0BoCGRMzOV8bU5G5ds7lYnwscgZli3qaLgARdJwu7SnEjd7CWQ92GDSdxBcra7QZZ uYso/KqA6p9oVkqiY6xyl1Sej79v2vHtP/66ATY3JCao7ecEQWgACxw8dNS95uwK4cNQ uQbRflRW4aFL/cRWMA2M5GzmzIvD+f11azwGYaLJxDHdmfZRdILqTnQdZqfU+8wYVYpt MfZw== X-Gm-Message-State: AOAM531rnzxs690MJ5AaF+FMV2hPfF1+/aog1rq3Fxxe1eKyS0ETbh+w YZ34SY4nzeKghOp4cquoOo4l4sR/MNMR5vUC X-Google-Smtp-Source: ABdhPJxcQDyF91HoyNIEVBz16X0WTOg/ErQai8uV2IakL8gxGcZ49DcN9NiEEF4uFYsgVaDPSe+RTg== X-Received: by 2002:a05:651c:211f:: with SMTP id a31mr4199067ljq.39.1622828341755; Fri, 04 Jun 2021 10:39:01 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id h25sm669075lfe.268.2021.06.04.10.38.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Jun 2021 10:39:00 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id r198so11905713lff.11 for ; Fri, 04 Jun 2021 10:38:59 -0700 (PDT) X-Received: by 2002:a05:6512:baa:: with SMTP id b42mr3435945lfv.487.1622828339731; Fri, 04 Jun 2021 10:38:59 -0700 (PDT) MIME-Version: 1.0 References: <20210604172407.GJ18427@gate.crashing.org> In-Reply-To: <20210604172407.GJ18427@gate.crashing.org> From: Linus Torvalds Date: Fri, 4 Jun 2021 10:38:43 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] LKMM: Add volatile_if() To: Segher Boessenkool Cc: Peter Zijlstra , Will Deacon , "Paul E. McKenney" , Alan Stern , Andrea Parri , Boqun Feng , Nick Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Linux Kernel Mailing List , linux-toolchains@vger.kernel.org, linux-arch Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Jun 4, 2021 at 10:27 AM Segher Boessenkool wrote: > > > Of course, we might want to make sure that the compiler doesn't go > > "oh, empty asm, I can ignore it", > > It isn't allowed to do that. GCC has this arguable misfeature where it > doesn't show empty asm in the assembler output, but that has no bearing > on anything but how human-readable the output is. That sounds about right, but we have had people talking about the compiler looking inside the asm string before. So it worries me that some compiler person might at some point go all breathy-voice on us and say "I am altering the deal. Pray I don't alter it any further". Side note: when grepping for what "barrier()" does on different architectures and different compilers, I note that yes, it really is just an empty asm volatile with a "memory" barrier. That should in all way sbe sufficient. BUT. There's this really odd comment in that talks about some "ECC" compiler: /* Intel ECC compiler doesn't support gcc specific asm stmts. * It uses intrinsics to do the equivalent things. */ and it defines it as "__memory_barrier()". This seems to be an ia64 thing, but: - I cannot get google to find me any documentation on such an intrinsic - it seems to be bogus anyway, since we have "asm volatile" usage in at least arch/ia64/mm/tlb.c So I do note that "barrier()" has an odd definition in one odd ia64 case, and I can't find the semantics for it. Admittedly I also cannot find it in myself to care. I don't think that "Intel ECC" compiler case actually exists, and even if it does I don't think itanium is relevant any more. But it was an odd detail on what "barrier()" actually might mean to the compiler. Linus