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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 785D6CA9EA1 for ; Fri, 18 Oct 2019 11:10:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 58FA72064A for ; Fri, 18 Oct 2019 11:10:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409916AbfJRLKe (ORCPT ); Fri, 18 Oct 2019 07:10:34 -0400 Received: from [217.140.110.172] ([217.140.110.172]:35376 "EHLO foss.arm.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S2406077AbfJRLKd (ORCPT ); Fri, 18 Oct 2019 07:10:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A2DAFB42; Fri, 18 Oct 2019 04:10:08 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AE7F03F6C4; Fri, 18 Oct 2019 04:10:05 -0700 (PDT) Date: Fri, 18 Oct 2019 12:10:03 +0100 From: Mark Rutland To: Dave Martin Cc: Paul Elliott , Peter Zijlstra , Catalin Marinas , Will Deacon , Yu-cheng Yu , Amit Kachhap , Vincenzo Frascino , linux-arch@vger.kernel.org, Eugene Syromiatnikov , Szabolcs Nagy , "H.J. Lu" , Andrew Jones , Kees Cook , Arnd Bergmann , Jann Horn , Richard Henderson , Kristina =?utf-8?Q?Mart=C5=A1enko?= , Mark Brown , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Florian Weimer , linux-kernel@vger.kernel.org, Sudakshina Das Subject: Re: [PATCH v2 05/12] arm64: Basic Branch Target Identification support Message-ID: <20191018111003.GC27759@lakrids.cambridge.arm.com> References: <1570733080-21015-1-git-send-email-Dave.Martin@arm.com> <1570733080-21015-6-git-send-email-Dave.Martin@arm.com> <20191011151028.GE33537@lakrids.cambridge.arm.com> <20191011172013.GQ27757@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191011172013.GQ27757@arm.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 11, 2019 at 06:20:15PM +0100, Dave Martin wrote: > On Fri, Oct 11, 2019 at 04:10:29PM +0100, Mark Rutland wrote: > > On Thu, Oct 10, 2019 at 07:44:33PM +0100, Dave Martin wrote: > > > +#define arch_calc_vm_prot_bits(prot, pkey) arm64_calc_vm_prot_bits(prot) > > > +static inline unsigned long arm64_calc_vm_prot_bits(unsigned long prot) > > > +{ > > > + if (system_supports_bti() && (prot & PROT_BTI)) > > > + return VM_ARM64_BTI; > > > + > > > + return 0; > > > +} > > > > Can we call this arch_calc_vm_prot_bits() directly, with all the > > arguments: > > > > static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot, > > unsigned long pkey) > > { > > ... > > } > > #define arch_calc_vm_prot_bits arch_calc_vm_prot_bits > > > > ... as that makes it a bit easier to match definition with use, and just > > definign the name makes it a bit clearer that that's probably for the > > benefit of some ifdeffery. > > > > Likewise for the other functions here. > > > > > +#define arch_vm_get_page_prot(vm_flags) arm64_vm_get_page_prot(vm_flags) > > > +static inline pgprot_t arm64_vm_get_page_prot(unsigned long vm_flags) > > > +{ > > > + return (vm_flags & VM_ARM64_BTI) ? __pgprot(PTE_GP) : __pgprot(0); > > > +} > > > + > > > +#define arch_validate_prot(prot, addr) arm64_validate_prot(prot, addr) > > > +static inline int arm64_validate_prot(unsigned long prot, unsigned long addr) > > Can do, though it looks like a used sparc as a template, and that has a > sparc_ prefix. > > powerpc uses the generic name, as does x86 ... in its UAPI headers. > Odd. > > I can change the names here, though I'm not sure it adds a lot of value. > > If you feel strongly I can do it. I'd really prefer it because it minimizes surprises, and makes it much easier to hop around the codebase and find the thing you're looking for. I'll reply on the other issue in a separate reply. Thanks, Mark.