Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp4987928img; Tue, 26 Mar 2019 23:03:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqzr1xv+0tmiO2g0zRoHvWa5HZMyWr+oOWjOlwAuRxlheI3NpA8vW6MKVCUKOLBRqj4IYh2b X-Received: by 2002:a63:d015:: with SMTP id z21mr31939892pgf.215.1553666628768; Tue, 26 Mar 2019 23:03:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553666628; cv=none; d=google.com; s=arc-20160816; b=iyOKFpgHPnJJs8v4xNjhSeUDozwCpMutivp1Pz+X562NNa+j4pmLDxamO/hsToNRW4 psjHNhxq2TGanOofwGppdP9iKSPSF9NYfE4bPOHVECUq8MIhVoQ8KewsE/s1So544rf4 pGmpFph26pWXVZI/bHNLeAb3blPRTaJGFqipdZy4ET9jemlgajy9VKNeOS4Q1owFGB3I BU/ruU5ogsqOli73XY0yRAQCyQajZXFLi9KtfTeNUUFhe4SJ/Yk+Eb4dDyE1biKZBXfq 1ltY0wxqNFKX6t1pDkWuGrckMYMRjfKVm6PwV07GaJUkbgsH9lc0HDuo8GWyrb3FfAbv CN1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:message-id :user-agent:mime-version:in-reply-to:references:cc:to:subject:from :date:dkim-signature; bh=KzoF20xLXXHyuCyJwFWJTRtr4sQQnjQpJ/lE1vgkmDI=; b=qJo0E/103DQOdg6PYLDITSUFYTze354SHbi7/ASO76GaFxIhsMIV86DLuLNSW/DGX3 NZjmVMYHsoy2TBeiDx4xP7RZ0/3ht2B/DCH3tkBO2zLVDsFMTBkCzPztRH1hyTXRqeKX SAo34rsCWjXpq96eZCP3PpDHCaSReUs0hRfwk8D9TpY6kYCxf6eGDIAV4H9u3TA1LBzy U96+Vrx/JfBtrGpxGQx/LeD8ivKhhk4f+/EBt0usuOM458bUY35q376rOKjrqlhid4PC SnHjQTaGuM/9YDJ+5NIuOzvh+iGXVUSx4UJ7TP36nVObqJR6TNmmUQsWA092ChEp1AWe yS4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OMzUCZ+S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id u6si17131312pgr.456.2019.03.26.23.03.32; Tue, 26 Mar 2019 23:03:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OMzUCZ+S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1732754AbfC0GCZ (ORCPT + 99 others); Wed, 27 Mar 2019 02:02:25 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:34982 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725730AbfC0GCY (ORCPT ); Wed, 27 Mar 2019 02:02:24 -0400 Received: by mail-pl1-f193.google.com with SMTP id p19so2801575plo.2 for ; Tue, 26 Mar 2019 23:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :user-agent:message-id:content-transfer-encoding; bh=KzoF20xLXXHyuCyJwFWJTRtr4sQQnjQpJ/lE1vgkmDI=; b=OMzUCZ+SoT5qG9yhUgwjX7tjNPt4pdrwVBKikzC8q4ys0U+U7jlniqAK67wQfpn2Sb ycL2UxyNUjumwbILINLWnq/pk+DeQjNZAnF7oC/Q7YwV0tNl4dPnnNyoeMIYuJIkrITH HQtirbdtYx7gOu7gvMyTjQd/3V0MgNfR0kec7bRMlp37RyhZ/RPwlrp3El9CQzfCrVUO FIaFeD0tRgDQIJFdbMOYrjTzpJidV74U8FjXIJzX9+zEeQsrJAeVSYpjJu2jf5E4kLVD hKLiITEYF51aeNiB8DeaRm9eu+j/tl/nSK9VJKebZmzf/dJF2OSWgtgfj63NwJ6cz+Xm guvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:user-agent:message-id:content-transfer-encoding; bh=KzoF20xLXXHyuCyJwFWJTRtr4sQQnjQpJ/lE1vgkmDI=; b=CEUT1I0SDyh9E/LsFhCB8DNHlLGQJIpCnALIEc14kTVxewUEwbvi4hxNbHsX+47A73 wTsj9YNB31CetNrcSw9RtJlNeb6DFpfgFAIHIO6/xgupPtoSqAgoLO4Z7TMOADX07X0/ Ykzwl79i2gnRPq9wh1C8MKYXULADXvdUXUo87QR/ON5Q4kaafePkn8Nz/wiFx2B4/7/U +atrhEAv+WyYLzfM4rb1hxi2TN0BurKTz7tKn/WKsty1YgDgjoqAuw0lX2YZ6H4aBybl B3z5Ybkh2AM9kl5/9F1RQTFf2yAAbopcWjl+ImiNX6IlAPkcXwhdq5j9nRlbWg2IIlDg NEDg== X-Gm-Message-State: APjAAAW9zoky7GTI8COCnQpBJvA6EegO5zlYn2rNWpbN64psjX5Mgk2j NLpneAq9XYJmv8/ZcVQ92Ok= X-Received: by 2002:a17:902:6b8c:: with SMTP id p12mr35900971plk.282.1553666543898; Tue, 26 Mar 2019 23:02:23 -0700 (PDT) Received: from localhost (14-202-58-188.tpgi.com.au. [14.202.58.188]) by smtp.gmail.com with ESMTPSA id w123sm31329456pfw.72.2019.03.26.23.02.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Mar 2019 23:02:23 -0700 (PDT) Date: Wed, 27 Mar 2019 16:02:16 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2] arch/powerpc: Rework local_paca to avoid LTO warnings To: Alastair D'Silva Cc: Andrew Morton , Benjamin Herrenschmidt , Christophe Leroy , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, =?iso-8859-1?q?Mahesh=0A?= Salgaonkar , Michal Hocko , Michael Ellerman , "Naveen N. Rao" , Paul Mackerras , =?iso-8859-1?q?Mike=0A?= Rapoport References: <20190313034208.13134-1-alastair@au1.ibm.com> <20190314023125.10076-1-alastair@au1.ibm.com> <1553579424.0r39b9otz6.astroid@bobo.none> <8d8a97e145758b92c2760012373f5217877a035c.camel@au1.ibm.com> In-Reply-To: <8d8a97e145758b92c2760012373f5217877a035c.camel@au1.ibm.com> MIME-Version: 1.0 User-Agent: astroid/0.14.0 (https://github.com/astroidmail/astroid) Message-Id: <1553665102.ow7h62jw1u.astroid@bobo.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alastair D'Silva's on March 27, 2019 2:37 pm: > On Tue, 2019-03-26 at 15:58 +1000, Nicholas Piggin wrote: >> Alastair D'Silva's on March 14, 2019 12:31 pm: >> > From: Alastair D'Silva >> >=20 >> > When building an LTO kernel, the existing code generates warnings: >> > ./arch/powerpc/include/asm/paca.h:37:30: warning: register of >> > =E2=80=98local_paca=E2=80=99 used for multiple global register= variables >> > register struct paca_struct *local_paca asm("r13"); >> > ^ >> > ./arch/powerpc/include/asm/paca.h:37:30: note: conflicts with >> > =E2=80=98local_paca=E2=80=99 >>=20 >> Isn't this a bogus warning? It doesn't look like there's a way to=20 >> define it any other way. >=20 > There isn't any other way to define it as a global. However, the > warning is legitimate. >=20 > The compiler sees that there are multiple global register variables, > all pointing at the same register. It's one variable though, so it's not a legitimate warning (unless there is a way to declare a "reference" to it that we are not doing). >=20 > The compiler can only determine this when LTO is used, as otherwise it > only sees the one in the current compilation unit, whicd disappears by > the time the kernel is linked. >=20 >>=20 >> > This patch reworks local_paca into an inline getter & setter >> > function, >> > which addresses the warning. >> >=20 >> > Changelog: >> > V2 >> > - Address whitespace issues >> > - keep new implementation close to where the old implementation >> > was >> >=20 >> > Signed-off-by: Alastair D'Silva >> > --- >> > arch/powerpc/include/asm/paca.h | 37 +++++++++++++++++++++++++-- >> > ------ >> > arch/powerpc/kernel/paca.c | 2 +- >> > 2 files changed, 29 insertions(+), 10 deletions(-) >> >=20 >> > diff --git a/arch/powerpc/include/asm/paca.h >> > b/arch/powerpc/include/asm/paca.h >> > index e843bc5d1a0f..2fa0b43357c9 100644 >> > --- a/arch/powerpc/include/asm/paca.h >> > +++ b/arch/powerpc/include/asm/paca.h >> > @@ -34,19 +34,38 @@ >> > #include >> > #include >> > =20 >> > -register struct paca_struct *local_paca asm("r13"); >> > - >> > #if defined(CONFIG_DEBUG_PREEMPT) && defined(CONFIG_SMP) >> > extern unsigned int debug_smp_processor_id(void); /* from >> > linux/smp.h */ >> > -/* >> > - * Add standard checks that preemption cannot occur when using >> > get_paca(): >> > - * otherwise the paca_struct it points to may be the wrong one >> > just after. >> > - */ >> > -#define get_paca() ((void) debug_smp_processor_id(), local_paca) >> > -#else >> > -#define get_paca() local_paca >> > #endif >> > =20 >> > +static inline struct paca_struct *get_paca_no_preempt_check(void) >> > +{ >> > + register struct paca_struct *paca asm("r13"); >> > + >> > + return paca; >> > +} >>=20 >> Problem is it now changes the global register variable to a local=20 >> register variable. The compiler would presumably be within its rights >> to "cache" that return value or use another register for it, which >> is not really what we want. >>=20 >>=20 >=20 > I've confirmed that at least with GCC 8.2.0, the generated assembler is > similar, but yes, the compiler may be free to take a copy into another > register (although that would be a terrible optimisation), and then > operate on that value. Yep. >=20 > Subsequent uses would still have to call the function (ie. fetch the > data from r13) regardless, so I believe this scenario is safe. >=20 > Can you think of a scenario where this is a problem? It wouldn't be the subsequent use but the one use. If you're preempted then you can't be using a stale r13 value. Quite possibly any bug like that would already be buggy now, the cases where it matters tend to need asm to access it. And it's something we need to really audit and have proper accessors and preempt warnings that Ben always harped on about. But to just work around this warning it seems pretty dangerous to change this and hope. Thanks, Nick =