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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 41950C02194 for ; Thu, 6 Feb 2025 12:01:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=QjG9kW5w+73Sfwo4E+EjxFgITF64YIoim638OGxImfM=; b=ucoDMaDnBucs+QYt98vc5rFN3Y qTYG85KfyQ+GZ54uc7t0X+Kyk/PPdF6SyBJkmdvQNw9rsT2av6qThmCLN38acPmDdeWQ3p9E28o5k 1HBCNGkEo+En06VsGNBqdfaaBCvQcvQRVzR5Y11uhvoAu2zZyXEgMT6BYdDCTfn0/QNjvsv68pjoC s3Fq12nI+YsEYeAJuiKDcUOkU5BlzZ+6m+vNc2Yk72YUXID+PIF3asAjbzyDz8YZeJfgzmT2TbSGD q7dChtP3R4X3eoHp/4o5A3db7/17kBAVVDQIjwNFottWyvyuiUeu+56/IJAEcjwPMJyapwBpvq8TO NHJ5ODZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tg0ZK-00000006Dmk-3KJT; Thu, 06 Feb 2025 12:01:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tfzL7-0000000609T-0Aii for linux-arm-kernel@lists.infradead.org; Thu, 06 Feb 2025 10:42:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9DA985C2A94; Thu, 6 Feb 2025 10:41:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D3EAC4CEDD; Thu, 6 Feb 2025 10:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738838552; bh=jfV7FRBl0rJ0JOMqPnXz12hpk6KIsvGmE5SGttHHEos=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=czSQMmQ61T7Kp3fWGXbm1EvX4Rf2+uS96o6ngh21tMvODk939IAhEOjTKwL98Lll6 F01JFcFzACxcJS+fsx9durY1YXOinWFM7t6vSo+hoKVlc6NhlSSlXhO1A9hy1xyoq6 jmSELQBP7o5rxcGrX894ZhJ4kA7dxzuXq6YwKaBf4RhjbqUArkbReY/3PyZ3Ie9YA1 HXWTBgtfN7IIKzush33wnxl3wb9W69RnL+L//hgXZw6rduy1aGAWn9o9A3QEAg62hw 0dG0EpVeYAl6klVxYks0VsWykI0wRTgse3I2VTTphI+8uWsqVAULn2+EIFm8iUg+CW hCdGLcITFTMIQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tfzL3-0015WC-S4; Thu, 06 Feb 2025 10:42:29 +0000 Date: Thu, 06 Feb 2025 10:42:29 +0000 Message-ID: <86seortkve.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: Mark Brown , linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, eauger@redhat.com, fweimer@redhat.com, jeremy.linton@arm.com, oliver.upton@linux.dev, pbonzini@redhat.com, stable@vger.kernel.org, tabba@google.com, wilco.dijkstra@arm.com, will@kernel.org Subject: Re: [PATCH 7/8] KVM: arm64: Mark some header functions as inline In-Reply-To: References: <20250204152100.705610-1-mark.rutland@arm.com> <20250204152100.705610-8-mark.rutland@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, eauger@redhat.com, fweimer@redhat.com, jeremy.linton@arm.com, oliver.upton@linux.dev, pbonzini@redhat.com, stable@vger.kernel.org, tabba@google.com, wilco.dijkstra@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250206_024233_162163_C0750F77 X-CRM114-Status: GOOD ( 28.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 06 Feb 2025 10:03:46 +0000, Mark Rutland wrote: > > [resending as I corrupted MarcZ's email when moving from CC into TO] > > On Wed, Feb 05, 2025 at 09:50:30PM +0000, Mark Brown wrote: > > On Tue, Feb 04, 2025 at 03:20:59PM +0000, Mark Rutland wrote: > > > The shared hyp swtich header has a number of static functions which > > > might not be used by all files that include the header, and when unused > > > they will provoke compiler warnings, e.g. > > > > With at least LLVM 18 we still have some issues with unused statics > > arising from the aliased function definitions: > > > > In file included from arch/arm64/kvm/hyp/nvhe/hyp-main.c:8: > > ./arch/arm64/kvm/hyp/include/hyp/switch.h:699:13: warning: unused function 'kvm_hyp_handle_iabt_low' [-Wunused-function] > > 699 | static bool kvm_hyp_handle_iabt_low(struct kvm_vcpu *vcpu, u64 *exit_code) > > | ^~~~~~~~~~~~~~~~~~~~~~~ > > ./arch/arm64/kvm/hyp/include/hyp/switch.h:701:13: warning: unused function 'kvm_hyp_handle_watchpt_low' [-Wunused-function] > > 701 | static bool kvm_hyp_handle_watchpt_low(struct kvm_vcpu *vcpu, u64 *exit_code) > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > The simplest thing would be to expand the alises into simple wrapper > > functions but that doesn't feel amazing, I don't know what people's > > taste is there? > > Adding 'inline' seems to work, which seems simpler? > > That said, I'm going to go with the below, adding 'inline' to > kvm_hyp_handle_memory_fault() and using CPP defines to alias the > function names: > > | static inline bool kvm_hyp_handle_memory_fault(struct kvm_vcpu *vcpu, > | u64 *exit_code) > | { > | if (!__populate_fault_info(vcpu)) > | return true; > | > | return false; > | } > | #define kvm_hyp_handle_iabt_low kvm_hyp_handle_memory_fault > | #define kvm_hyp_handle_watchpt_low kvm_hyp_handle_memory_fault > > I think that's clearer, and it's more alisnged with how we usually alias > function names in headers. Other than these two cases, __alias() is only > used in C files to create a sesparate exprted symbol, and it's odd to > use it in a header anyhow. > > Marc, please should if you'd prefer otherwise. Nah, that's fine by me. My only issue was with marking functions as inline, and yet storing pointers to these functions. But it looks like the compiler (GCC 12.2 in my case) is doing a good job noticing the weird pattern, and generating only one function, even if we store multiple pointers. Thanks, M. -- Without deviation from the norm, progress is not possible.