Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp897336ybl; Wed, 4 Dec 2019 12:52:33 -0800 (PST) X-Google-Smtp-Source: APXvYqzbi1Kqawk1KaGZ6ychui9ITEOyDAtM0ItQIgRfuWFyyH4sC6jfn/lXPaWJeafbPnT+jxXx X-Received: by 2002:aca:b10a:: with SMTP id a10mr4454178oif.26.1575492753317; Wed, 04 Dec 2019 12:52:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575492753; cv=none; d=google.com; s=arc-20160816; b=ouhyMjJflyT46fjrWtIZV7+BKNMChaDX7gFuNwQikIvMfqMz/zg57l8r0uIgoKrgDD 7hD25LEJMo81v3lF9gCueESkVsNke8yiuZKt06L0IaZq5RxX187LWcEWEovJcy0gkmQN RARjej1rHSoNzIjdFr+PKCCCgFXDMOKiCAq8EHU9UH2BHRxUlvT6KIB8LYfiurcyfpuj gZLpsiiASng0FQ695eWQkDIrsOoN6Kstq65Zpz8VzAClX4siLNi3z2qnW6aqZaJN099Z YmHFZmm8UYPIIjYgHdkaTAUbA6vrNbQvZh6i5cxBuVl8vLfygcRtGfmz2gAIwNZVlAhZ RBRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hq3LxKYOOomc+/QE33SRTklsyQdBe2jME5WH5NYH7Hk=; b=EXq+2zL3fTIwNZq6hltf1JYN4ezv26Zvu1p2CYuah1KKmDwa79Rj8+w9D6MMDqC0C0 OOZTetXERe6H4T+In4LLkH16wzcC/U72NmFsGU6eiR0lmeXEPzt2jOFTQL6mkX8o7OmM NIQhAw0CX4PckPTF46O8tBKKxzpGg+Hhy0op5AzAtW1D6bTikDdVsMLIakatgwTmHo1Y c159xP6m34g94w80AzaQraQwKGUGFJDfFFXh2klscSBfEBOQPfYIhhdaEXdGsZg/eesa LlFQEPfqe4uUWOQbjyXaRpRfKeVgB3q8Zv7KEujU+FtWDmI6Ic0I/OzGh4Egc4Hx3Uhz LbCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=XofnVsh9; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v8si3930377otk.227.2019.12.04.12.52.20; Wed, 04 Dec 2019 12:52:33 -0800 (PST) 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=@soleen.com header.s=google header.b=XofnVsh9; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728117AbfLDUu3 (ORCPT + 99 others); Wed, 4 Dec 2019 15:50:29 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:33733 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727961AbfLDUu3 (ORCPT ); Wed, 4 Dec 2019 15:50:29 -0500 Received: by mail-ed1-f68.google.com with SMTP id l63so691015ede.0 for ; Wed, 04 Dec 2019 12:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hq3LxKYOOomc+/QE33SRTklsyQdBe2jME5WH5NYH7Hk=; b=XofnVsh9JkrhplZ0OE7AUH7DsGvWdzLDYNfCfoxP0l7uUCOPFmiZWxdtwZzblCYEz8 nzcH3SxfKhsCeer285czBZtVUVdiqAvyDPXXHbvpBPdshfdh4w4FF5Ng8H+oA31OjfUI vZPAxNhB2mjGDNunaPVs6r6Df+EF+XB70UgvdAQdXKp02x6VP+txnFgTTh5mY2PbTWBh aPKP8kNjSZ9Nvrd6ldUJWoy7jknWIGTYAA4U6EpTMVIIsriQ4TSB6X2dF7Rx8utkpo3r RjUET3r64LH2ttN2w9Ab+JOyQfISd+xC71qLWTi6TcfKwVeInFWLiTuMVy3Xo0/BLupS 8Apg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hq3LxKYOOomc+/QE33SRTklsyQdBe2jME5WH5NYH7Hk=; b=MA6l8HLgbcU+S72xdTUZ5x3gBPoTIypWBlvYrBtWHU9Jzjhzm8Ic3KEdRl1Y2mwYGW 9IMK5+7LRdCWAVNYdCaTYrLL4dBwRwGlrYyJN29N3a7NlHhI7GBGIbKwrvdUC81FhdRY Q8NhijLDE/gjSWfVaqIW35lH+7yjNdo9pM3/27z8WQPq8b2PvsNhPeY7FMLT6wMtFMHw KGBSZEu35cC+i4KjRp3dJs9Dx4JjCdoCCJf4GtVUQcRju+8ZRq7lN1/Gxuz+XGdhyXs7 u3vUyPn2hKz5hM0gIrB2D7kqRg8UlCM43fCjcoEcOZoXNPReKJ8kH96pRRCFjAplqpau H06w== X-Gm-Message-State: APjAAAVapB7uZC/yMyp6MH6tUv2+d2N2pIV1lkovkxBSM4cWQUr2j9na c+vcgxr1dO6EVhlwqum6e8exVTap8n5B9r2F4PtTrQ== X-Received: by 2002:a17:906:3798:: with SMTP id n24mr5230843ejc.15.1575492627075; Wed, 04 Dec 2019 12:50:27 -0800 (PST) MIME-Version: 1.0 References: <20191127184453.229321-1-pasha.tatashin@soleen.com> <20191127184453.229321-3-pasha.tatashin@soleen.com> <20191128145151.GB22314@lakrids.cambridge.arm.com> In-Reply-To: <20191128145151.GB22314@lakrids.cambridge.arm.com> From: Pavel Tatashin Date: Wed, 4 Dec 2019 15:50:15 -0500 Message-ID: Subject: Re: [PATCH 2/3] arm64: remove uaccess_ttbr0 asm macros from cache functions To: Mark Rutland Cc: James Morris , Sasha Levin , LKML , Catalin Marinas , Will Deacon , steve.capper@arm.com, Linux ARM , Marc Zyngier , James Morse , Vladimir Murzin , Thomas Gleixner , Greg Kroah-Hartman , allison@lohutok.net, info@metux.net, alexios.zavras@intel.com, Stefano Stabellini , boris.ostrovsky@oracle.com, jgross@suse.com, Stefan Agner , Masahiro Yamada , xen-devel@lists.xenproject.org, Russell King - ARM Linux admin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 28, 2019 at 9:51 AM Mark Rutland wrote: > > On Wed, Nov 27, 2019 at 01:44:52PM -0500, Pavel Tatashin wrote: > > We currently duplicate the logic to enable/disable uaccess via TTBR0, > > with C functions and assembly macros. This is a maintenenace burden > > and is liable to lead to subtle bugs, so let's get rid of the assembly > > macros, and always use the C functions. This requires refactoring > > some assembly functions to have a C wrapper. > > [...] > > > +static inline int invalidate_icache_range(unsigned long start, > > + unsigned long end) > > +{ > > + int rv; > > Please make this 'ret', for consistency with other arm64 code. We only > use 'rv' in one place where it's short for "Revision and Variant", and > 'ret' is our usual name for a temporary variable used to hold a return > value. OK > > > + > > + if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)) { > > + isb(); > > + return 0; > > + } > > + uaccess_ttbr0_enable(); > > Please place a newline between these two, for consistency with other > arm64 code. OK > > > + rv = asm_invalidate_icache_range(start, end); > > + uaccess_ttbr0_disable(); > > + > > + return rv; > > +} > > + > > static inline void flush_icache_range(unsigned long start, unsigned long end) > > { > > __flush_icache_range(start, end); > > diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S > > index db767b072601..a48b6dba304e 100644 > > --- a/arch/arm64/mm/cache.S > > +++ b/arch/arm64/mm/cache.S > > @@ -15,7 +15,7 @@ > > #include > > > > /* > > - * flush_icache_range(start,end) > > + * __asm_flush_icache_range(start,end) > > * > > * Ensure that the I and D caches are coherent within specified region. > > * This is typically used when code has been written to a memory region, > > @@ -24,11 +24,11 @@ > > * - start - virtual start address of region > > * - end - virtual end address of region > > */ > > -ENTRY(__flush_icache_range) > > +ENTRY(__asm_flush_icache_range) > > /* FALLTHROUGH */ > > > > /* > > - * __flush_cache_user_range(start,end) > > + * __asm_flush_cache_user_range(start,end) > > * > > * Ensure that the I and D caches are coherent within specified region. > > * This is typically used when code has been written to a memory region, > > @@ -37,8 +37,7 @@ ENTRY(__flush_icache_range) > > * - start - virtual start address of region > > * - end - virtual end address of region > > */ > > -ENTRY(__flush_cache_user_range) > > - uaccess_ttbr0_enable x2, x3, x4 > > +ENTRY(__asm_flush_cache_user_range) > > alternative_if ARM64_HAS_CACHE_IDC > > It's unfortunate that we pulled the IDC alternative out for > invalidate_icache_range(), but not here. Good point. I will fix that in a separate patch. Thank you, Pasha