Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2851786pxj; Sun, 6 Jun 2021 16:48:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+CJLbE0eGf3POcF84NLx2hZhJ7W82KM1UejSedtb8MkAd9/yppb1OEb5dKJHS6RCoEzZU X-Received: by 2002:aa7:d0cc:: with SMTP id u12mr13484858edo.48.1623023297136; Sun, 06 Jun 2021 16:48:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623023297; cv=none; d=google.com; s=arc-20160816; b=B6n5W4FP4QXsQnYyswrt3gDXmFAdcvgpHE+GWWXsJOwHj0s0CIwahFmEZVtajJEb+v CUnUI52kE+b/+FOiXJW8jgc2WyFwqzEYjEpNXbD6Y4TryRgdcy1MDpvEB5aPvNPa9t2y qmQjuqE+EaSOenGvD3VwGwc77udSdIXzt/yLcWEa4BMqF6S0See3WSJJsYo8ZmFwEC7w DtdbhQDJ8FkpH5wjLCgprKfd/AU31GojnqOkXxfaIQtsyDveJYMNPtFjgPJ7WfLa+7VP yGNUZlEichVVt/HszeVOLoqieLylgWoCSml9K2vjwGloa1wSfpO2IzRdvZeLO9wzCG++ l+lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=KZD8IflcYIe/9eJ/2AgNYmJumSxANKmiOTOD3q934Es=; b=SAkGsTA/otTB2A3Xcoa3W8IF0NBYYS5jUO7OUQk+tKtmdTwhTfgo3CtoCudwyVxHIk HtnI0NaxaXOj8m+bQB6mFjICzqVLmirWhr/+qL84Aiqwxv1f4fNk212BacJo9ZdikZny PSNhBH2AxUHWjMaVlL8p1XJZ1VHFzrQNS42AD2GStri26gmAM7ra5Iy7bifG9Qw1Zwb/ vSdEgUP+MWq2Ixvi0hI9xFT/9JXaQCA5l17UkUJS8XdHfDCVO5KyQsFYEx9lEQ1FTryA xJrDMVek4dey3wJ8ptVvb/MCOdbndbL47UcRT7zAyjXp/xMprTaFb/I/7N6hF5JrwNH2 Xg9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b="IP/khOwC"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i14si4135043edc.516.2021.06.06.16.47.55; Sun, 06 Jun 2021 16:48:17 -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=@rasmusvillemoes.dk header.s=google header.b="IP/khOwC"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230192AbhFFXk5 (ORCPT + 99 others); Sun, 6 Jun 2021 19:40:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230183AbhFFXk5 (ORCPT ); Sun, 6 Jun 2021 19:40:57 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0BFCC061766 for ; Sun, 6 Jun 2021 16:39:06 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 131so19629812ljj.3 for ; Sun, 06 Jun 2021 16:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KZD8IflcYIe/9eJ/2AgNYmJumSxANKmiOTOD3q934Es=; b=IP/khOwCT+DU5R4G2+yFmZ2yVUMLZcvGBxyvkyuT/8uPP0uN6eXT0YzsPvySt8Pj+Z Gji8ZqiVa/B++AYQ9jDfxTICg+7XfQxfYM2XYaeWTi+t4D9icri3bTYUczGSY9vzAWjZ RNPUAVYaRPGzXUAMcuLQtW6m3NkMhGjcooMYA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KZD8IflcYIe/9eJ/2AgNYmJumSxANKmiOTOD3q934Es=; b=RgMDuG74LQ3QFipTTUOOYWEneHB3UCrOGw9lLuHtOzFPcqG73/+NBVqr+JiESs9EyG DvlLL3qGBvp88XN/RXr8D4T/L/9BKIgShwPLeHclaVZUnin7zUtfOny6yq/mcnXu3XO8 3/2smpBqHf5zLazHHVRmjHzfJZqFkG7ub7W0fdGFSwNB98IeIE708ZcJ4utexHSfXl5p w0XJQhFqyc1Hmvcu2OLiJv/qAwopkgxgDITzXRJsuB7hBtNFu/vHSbO5Jczci3X5TMIw RY1EdwIkJGFiruwNVV0DSIO2wicK8Q2Q7AiccJn/9AJu1Ec0xtdmaLLLr52MyX4Oo/2E 8R5g== X-Gm-Message-State: AOAM5306jud2V2xezwrVyhgVj0Gta2Cj9fA4tOFFOEmGbqo8zE6sWa7W tIwQu8gtE4IytdPQ0oNL+4Xnuw== X-Received: by 2002:a2e:b819:: with SMTP id u25mr12357920ljo.182.1623022744877; Sun, 06 Jun 2021 16:39:04 -0700 (PDT) Received: from [172.17.20.50] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id u10sm1631787lji.16.2021.06.06.16.39.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 16:39:04 -0700 (PDT) Subject: Re: [RFC] LKMM: Add volatile_if() To: Linus Torvalds , Alexander Monakov Cc: Jakub Jelinek , Alan Stern , Segher Boessenkool , "Paul E. McKenney" , Peter Zijlstra , Will Deacon , 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 References: <20210604205600.GB4397@paulmck-ThinkPad-P17-Gen-1> <20210604214010.GD4397@paulmck-ThinkPad-P17-Gen-1> <20210605145739.GB1712909@rowland.harvard.edu> <20210606001418.GH4397@paulmck-ThinkPad-P17-Gen-1> <20210606012903.GA1723421@rowland.harvard.edu> <20210606185922.GF7746@tucnak> From: Rasmus Villemoes Message-ID: Date: Mon, 7 Jun 2021 01:39:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/06/2021 00.38, Linus Torvalds wrote: > Example: variable_test_bit(), which generates a "bt" instruction, does > > : "m" (*(unsigned long *)addr), "Ir" (nr) : "memory"); > > and the memory clobber is obviously wrong: 'bt' only *reads* memory, > but since the whole reason we use it is that it's not just that word > at address 'addr', in order to make sure that any previous writes are > actually stable in memory, we use that "memory" clobber. > > It would be much nicer to have a "memory read" marker instead, to let > the compiler know "I need to have done all pending writes to memory, > but I can still cache read values over this op because it doesn't > _change_ memory". > > Anybody have ideas or suggestions for something like that? The obvious thing is to try and mark the function as pure. But when applied to a static inline, gcc seems to read the contents and say "nah, you have something here that declares itself to possibly write to memory". Replacing with a call to an extern function marked pure does indeed cause gcc to cache the value of y*z, so in theory this should be possible, if one could convince gcc to "trust me, this really is a pure function". https://godbolt.org/z/s4546K6Pj Rasmus