Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp316577ybt; Wed, 8 Jul 2020 00:16:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQsHkU6DgyHUTbHpsQcRD3izZVQwqM41m7dXqkhRmUCOhG1AQltA+RIWso1vgtyuyaLplp X-Received: by 2002:a50:fe0c:: with SMTP id f12mr58591992edt.360.1594192616366; Wed, 08 Jul 2020 00:16:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594192616; cv=none; d=google.com; s=arc-20160816; b=V8336VjYjmQwSAmfmyj6llU2kOBkqM9155SX8LjcV34iqY6r7XOp4yfdHzt3D8xclH HjQVDzprU7qSdXB5VPb//iGAUTcHwyar7sC0lZXR8WoyFmWzhcA0ilIdcLtnPTs25esx zZasdkwjY3ET6+ybbS0KP7nQHKTCz0SqDaLfyXNfNQ+DX7HziYhzEYzD5//uWafNa7OF eqPKaksf9iSYgt3ARz2LUDVLxiNXpo0ExDeV6OpsSdRjz7ueKwbSi4EXUpkoMNRIdLKB kerkG0CxhhEfGYTy6Iup5qSGxFrCY4Veom/4VuVsFy/dOis5Ss79eHydR1yUqqmSMEh1 T0Cg== 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=rUN87HHcT0D+VYtpGAgTAdZG4A7i97yXdShp42YthWM=; b=SpdzFmVAAk+JbiHjuWdgcIA/sQwB2RFw+1TW+W0HSZc27ad6+0qoQvfyzoWa4MPkpd 4UZefU9jibE2eBcKxLxnK9HfVJMP0/VegoldqINm3581+5/4f0tCzbnvAYu95ePp9+pd Sugfk3jojmQ/pl7u4tm2ALGYg0lbj1mx9PJYad+b4axjlcijGpXr8g0FOwxVs0x6JCpV /FmD7hHEwXP/kSvBSspIHCgH5xmLZ1WEF9rIlnfh7ynloAN4lyRKvGKcX4oVMQYU5A+E P9hrWw/rniKmSQ34FuVldMo7iTJY3Fj0DY7HitmlGToE2H3ORiCotuN+7Om/tXU1zzR4 MOIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="M/+llDmn"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f16si13446837edy.386.2020.07.08.00.16.33; Wed, 08 Jul 2020 00:16:56 -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=@google.com header.s=20161025 header.b="M/+llDmn"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729980AbgGHHP5 (ORCPT + 99 others); Wed, 8 Jul 2020 03:15:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729881AbgGHHP5 (ORCPT ); Wed, 8 Jul 2020 03:15:57 -0400 Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDFBEC08C5DC for ; Wed, 8 Jul 2020 00:15:56 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id n24so34018573otr.13 for ; Wed, 08 Jul 2020 00:15:56 -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; bh=rUN87HHcT0D+VYtpGAgTAdZG4A7i97yXdShp42YthWM=; b=M/+llDmnnVb41HXbwGOiq6jmJPUaW8FTQkCNy2QnRSJcNvFQz7To2Zi1x1XHAnSlcW rN5mobyMuuy1YzbBp6BTqhI+EhsEyXpb6bsBmx8xuUAxPfRdmb1/kJsYyQSwF2pR5W7L ku19jswToojrU0/+xLzKSohGM0llFTFrYsyezI+Vp3B93TVjmqqvLUSqbUY4T0bfUXMN V8uy+jzabbSJzuAiBle2nPlVZyitMpOPiPSmzzJKZnxrCPFcszkCdZtKxd9mdvot52z5 HaKvIw0BWdmUzd+Cr5U5fPoJRINu0Qj4C+VR0J7bv/yKZrkqf03UcNkhw7GLtzfpib7q 2d6g== 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=rUN87HHcT0D+VYtpGAgTAdZG4A7i97yXdShp42YthWM=; b=LXGT0znRp4ajyilZmWKfdrh3VFe/vUF7+nPCyHru/K6hGfACLbIfLVBnCZ3VxXy7xG QXvevSmbIKwNkS4cNRdHRWITO0l0KCZM4gLeLmhPBTaV3JRw4XOG3lVlu37unRSvgJHH afsocKI8o4xFAWdpmaqzKglgUDMHnbrbzrDSliux4M/JC+CNsFFr8K6UecGXlZmZsOOi d/+pGpi82ynw093rzqocyG/iixDIKmIkDZ4gmws0JA92YLiEnx/DLe/eMor8725PLM/+ c9nQuhKKsrTKqVL1QI3rWmk/qApxnD6qXI8MK9PDspyyGjb7FvQ1EvwkVJqdB4Jzplkz LjXg== X-Gm-Message-State: AOAM5317o9tCN/VPyeHz3/wwjFVbZiXXTJwesKklzJBiS64XqwvI/QYp AfsnfT+US0yPMtWRwxNcuga/l9vfARo0UyCSv+9jcQ== X-Received: by 2002:a9d:2788:: with SMTP id c8mr32372097otb.251.1594192556026; Wed, 08 Jul 2020 00:15:56 -0700 (PDT) MIME-Version: 1.0 References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-19-will@kernel.org> <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> <20200702072301.GA15963@willie-the-truck> <20200706160023.GB10992@arm.com> <20200706163455.GV9247@paulmck-ThinkPad-P72> <20200706170556.GE10992@arm.com> <20200706173628.GZ9247@paulmck-ThinkPad-P72> <20200707102915.GI10992@arm.com> <20200707225122.GJ9247@paulmck-ThinkPad-P72> In-Reply-To: From: Marco Elver Date: Wed, 8 Jul 2020 09:15:44 +0200 Message-ID: Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y To: Nick Desaulniers Cc: "Paul E. McKenney" , Dave Martin , Peter Zijlstra , Will Deacon , Sami Tolvanen , Mark Rutland , "Michael S. Tsirkin" , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, Alan Stern , Matt Turner , kernel-team , Kees Cook , Arnd Bergmann , Boqun Feng , Josh Triplett , Ivan Kokshaysky , Linux ARM , Richard Henderson , LKML , linux-alpha@vger.kernel.org, Steven Rostedt 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, 8 Jul 2020 at 01:01, Nick Desaulniers wrote: > > I'm trying to put together a Micro Conference for Linux Plumbers > conference focused on "make LLVM slightly less shitty." Do you all > plan on attending the conference? Would it be worthwhile to hold a > session focused on discussing this (LTO and memory models) be > worthwhile? I would welcome sessions on LLVM, and would try to attend. Apart from general improvements to the LLVM ecosystem, we should also emphasize the benefits LLVM provides and how we can enable them (one reason we want LTO is to get CFI). Regarding LTO and memory models, I'm not sure. Given the current state of things, such a discussion needs to be carefully framed to not go in circles, because we're trying to figure out things at the intersection of architecture, what the compiler does, the C standard, and the kernel wants. And because some of these boxes are difficult to change (standard, arch, compiler) or difficult to precisely define behaviour (compiler), we might end up going in circles. From what I see there are efforts to fix the situation at the root (standard), and we might have means to get the compiler to tell us what it's doing. But these happen extremely slowly. So, if we do this, we need to be careful to not end up re-discussing what we discussed here, but rather try and make it a continuation that hopefully leads to some constructive output. Thanks, -- Marco