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=-7.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 3A808C433DF for ; Thu, 2 Jul 2020 18:01:14 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0AB1C20760 for ; Thu, 2 Jul 2020 18:01:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JFDymRrS"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="YSECcQsG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AB1C20760 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:Reply-To:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1NAb4YsU3lMDYy+NQc2MmnVx71SgUS4PXLFHcJTSd2k=; b=JFDymRrS7JjF5QkSMvJh/lq3dA O/4hfqbK7tR42oS0ZlJr4hpVeJSVbhQN+gBqmM8GrQnmJ0JjdY4wtlVpC9nONryBT5SUbuFIB1NIi rOx3cFm9YBZScTLOdtYi6yj6yKfX3dzfsaZlVwr1r6NDBAw8R6doDEiaacujpCq052oBv2ffN/pIf ZxLcxRxzcuqWyxbzVsRsQd70HOtSzkDtVXw2NLv1smvO90+5TJfapFhL95PhmIewggEvrSmBxRxSg OOblQSi1Bi/JoCBIu3kvYuxYUMFV6XvStxlK4CiYYJTBOkcTIsVqy4DXpqY1FBL0sIyJB+N6Uzbf6 /9Zocvgw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr3V3-0006e7-Ks; Thu, 02 Jul 2020 17:59:53 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr3Uz-0006bL-7z for linux-arm-kernel@lists.infradead.org; Thu, 02 Jul 2020 17:59:51 +0000 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 69C4F20737; Thu, 2 Jul 2020 17:59:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593712788; bh=vG1vBm6vstM6zzH+k1vdCUTH1v0SmoEIDUIITtr1D/0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=YSECcQsGgN0Kb258rQalKoY0GD0gMkQKjSrIAw4B93WGNrTMgWQ/6hr+oWDw+SXRG xKlKIQ4BaG/mRIGsMf9Tu1kJIwAlxOy0d4WAWr1fTaubryYquozE9wywm8Z/2siJrf mogkDnM5b8tk2Qmi8jhn2YzWtbDFbssSH7swTEv0= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 52653352334B; Thu, 2 Jul 2020 10:59:48 -0700 (PDT) Date: Thu, 2 Jul 2020 10:59:48 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Subject: Re: [PATCH 00/22] add support for Clang LTO Message-ID: <20200702175948.GV9247@paulmck-ThinkPad-P72> References: <20200625085745.GD117543@hirez.programming.kicks-ass.net> <20200630191931.GA884155@elver.google.com> <20200630201243.GD4817@hirez.programming.kicks-ass.net> <20200630203016.GI9247@paulmck-ThinkPad-P72> <20200701114027.GO4800@hirez.programming.kicks-ass.net> <20200701140654.GL9247@paulmck-ThinkPad-P72> <20200701150512.GH4817@hirez.programming.kicks-ass.net> <20200701160338.GN9247@paulmck-ThinkPad-P72> <20200702082040.GB4781@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200702082040.GB4781@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200702_135949_498191_C165DF43 X-CRM114-Status: GOOD ( 16.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: paulmck@kernel.org Cc: linux-arch , Marco Elver , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Kees Cook , Kernel Hardening , Greg Kroah-Hartman , Masahiro Yamada , Linux Kbuild mailing list , Nick Desaulniers , LKML , clang-built-linux , Sami Tolvanen , linux-pci@vger.kernel.org, Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 02, 2020 at 10:20:40AM +0200, Peter Zijlstra wrote: > On Wed, Jul 01, 2020 at 09:03:38AM -0700, Paul E. McKenney wrote: > > > But it looks like we are going to have to tell the compiler. > > What does the current proposal look like? I can certainly annotate the > seqcount latch users, but who knows what other code is out there.... For pointers, yes, within the Linux kernel it is hopeless, thus the thought of a -fall-dependent-ptr or some such that makes the compiler pretend that each and every pointer is marked with the _Dependent_ptr qualifier. New non-Linux-kernel code might want to use his qualifier explicitly, perhaps something like the following: _Dependent_ptr struct foo *p; // Or maybe after the "*"? rcu_read_lock(); p = rcu_dereference(gp); // And so on... If a function is to take a dependent pointer as a function argument, then the corresponding parameter need the _Dependent_ptr marking. Ditto for return values. The proposal did not cover integers due to concerns about the number of optimization passes that would need to be reviewed to make that work. Nevertheless, using a marked integer would be safer than using an unmarked one, and if the review can be carried out, why not? Maybe something like this: _Dependent_ptr int idx; rcu_read_lock(); idx = READ_ONCE(gidx); d = rcuarray[idx]; rcu_read_unlock(); do_something_with(d); So use of this qualifier is quite reasonable. The prototype for GCC is here: https://github.com/AKG001/gcc/ Thanx, Paul _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel