Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp803217pxb; Tue, 14 Sep 2021 09:03:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx56Y6fnrmg159V1aSw7etzNDpBV9vRKL0iEM9YoqLXBH/UDqzxU3ONZ4yGCo6f8ep6sGNK X-Received: by 2002:ac2:4c97:: with SMTP id d23mr13615857lfl.15.1631635408550; Tue, 14 Sep 2021 09:03:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631635408; cv=none; d=google.com; s=arc-20160816; b=fc1fffkiEVA/hmm8aqe+ayF3nxESKYQ94vZ5BAp0+HZ8TbOhknI/yDKgqG7kXXgoFf 3hoqXirOjmL85PsUrZvf4yrJjcgbc9weU6xW4TH9wy3wyaCYPjSVfB7btQwsed011d8F 4Omv/bwiUGqdVYqhPYvo+skmvvVcAYeCzIH+iO7kGqOcJIamkIpL7Cr00N6QKzfAIVV7 V360s0baABc4HQ6JspoV6fNRuA+EEwgUnsU4jpL5a+Mu5Uuz76eZnq1vY7U8HmAUklqf J/F4Yd4AVxkj5NwsiHwQtxxD1Ss7OZ25BgEQXthZMS0XnHZM2K7W5ksaFP4NCFZ6h/XU 6nYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=8WfBaGEix2qwCuc5aLT/pdew1jBnNlHkDrIeVcI3ZAs=; b=Ldvn/2VNpx+gU0j9d467HO8PVFB5HNpK11DInKZ/gHimbthEZv4SF+wtSsktAUBDXV yBTp7cqNv6lFWrq6tVnOFSrA2YiILRL19XydYDWa2dwyePuSj9tm0bdBUAKJwVTI05px EocIwYpR+G7zyeKR6f4wTjJ1g2+1triUb3PDKnAOKzRCvLvwlPm4KHwSRyd379o28F2X EeyAn01wTP5sG11VzHBqqWlob2y+gf1JCtdGMH6i9mV0asNVkclWmrAFGReu2qmK3OQq UfHNUk44Qh7fskWtcYaCQeTefeW/imu2ej53fai0n69UvAg70DSHcLsnyWN60q6h07dP g32Q== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u7si8246300lfu.369.2021.09.14.09.02.57; Tue, 14 Sep 2021 09:03:28 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233244AbhINQCW (ORCPT + 99 others); Tue, 14 Sep 2021 12:02:22 -0400 Received: from foss.arm.com ([217.140.110.172]:46660 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232916AbhINQCV (ORCPT ); Tue, 14 Sep 2021 12:02:21 -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 CAD22101E; Tue, 14 Sep 2021 09:01:03 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.21.233]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A0A293F5A1; Tue, 14 Sep 2021 09:01:02 -0700 (PDT) Date: Tue, 14 Sep 2021 17:00:56 +0100 From: Mark Rutland To: Amit Daniel Kachhap Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Vincenzo Frascino , Catalin Marinas , Will Deacon Subject: Re: [PATCH] arm64/traps: Avoid unnecessary kernel/user pointer conversion Message-ID: <20210914160056.GA35239@C02TD0UTHF1T.local> References: <20210914152742.27047-1-amit.kachhap@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210914152742.27047-1-amit.kachhap@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 14, 2021 at 08:57:42PM +0530, Amit Daniel Kachhap wrote: > Annotating a pointer from kernel to __user and then back again might > confuse sparse. In call_undef_hook() it can be avoided by not using the > intermediate user pointer variable. When you say "might confuse sparse", does it complain today? If so, can you include an example of what goes wrong? > Note: This patch adds no functional changes to code. > > Cc: Catalin Marinas > Cc: Will Deacon > Signed-off-by: Amit Daniel Kachhap > --- > arch/arm64/kernel/traps.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index b03e383d944a..357d10a8bbf5 100644 > --- a/arch/arm64/kernel/traps.c > +++ b/arch/arm64/kernel/traps.c > @@ -404,7 +404,8 @@ static int call_undef_hook(struct pt_regs *regs) > > if (!user_mode(regs)) { > __le32 instr_le; > - if (get_kernel_nofault(instr_le, (__force __le32 *)pc)) > + if (get_kernel_nofault(instr_le, > + (__le32 *)instruction_pointer(regs))) Can we make `pc` an unsigned long, instead? It'd be nice to handle all three cases consistently, even if that means adding __force to the two user cases. Thanks, Mark. > goto exit; > instr = le32_to_cpu(instr_le); > } else if (compat_thumb_mode(regs)) { > -- > 2.17.1 >