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 011A8C10DCE for ; Thu, 12 Mar 2020 09:50:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C755A2072F for ; Thu, 12 Mar 2020 09:50:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C755A2072F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5A0A06B0003; Thu, 12 Mar 2020 05:50:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5523C6B0006; Thu, 12 Mar 2020 05:50:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4671A6B0007; Thu, 12 Mar 2020 05:50:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id 2CDA16B0003 for ; Thu, 12 Mar 2020 05:50:28 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DA5FBEFC8 for ; Thu, 12 Mar 2020 09:50:27 +0000 (UTC) X-FDA: 76586240094.18.group90_5b5006c83291d X-HE-Tag: group90_5b5006c83291d X-Filterd-Recvd-Size: 3699 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Mar 2020 09:50:27 +0000 (UTC) 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 675A31FB; Thu, 12 Mar 2020 02:50:26 -0700 (PDT) Received: from mbp (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D92E83F67D; Thu, 12 Mar 2020 02:50:24 -0700 (PDT) Date: Thu, 12 Mar 2020 09:50:22 +0000 From: Catalin Marinas To: Richard Henderson Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, Richard Earnshaw , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , Peter Collingbourne , linux-mm@kvack.org, Vincenzo Frascino , Will Deacon Subject: Re: [PATCH v2 19/19] arm64: mte: Add Memory Tagging Extension documentation Message-ID: <20200312095022.GA5801@mbp> References: <20200226180526.3272848-1-catalin.marinas@arm.com> <20200226180526.3272848-20-catalin.marinas@arm.com> <0857cca0-9f75-398d-e755-f645d2d8a594@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0857cca0-9f75-398d-e755-f645d2d8a594@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 11, 2020 at 03:17:54PM -0700, Richard Henderson wrote: > On 2/26/20 10:05 AM, Catalin Marinas wrote: > > + /* > > + * From include/uapi/linux/prctl.h > > + */ > > + #define PR_SET_TAGGED_ADDR_CTRL 55 > > + #define PR_GET_TAGGED_ADDR_CTRL 56 > > + # define PR_TAGGED_ADDR_ENABLE (1UL << 0) > > + # define PR_MTE_TCF_SHIFT 1 > > + # define PR_MTE_TCF_NONE (0UL << PR_MTE_TCF_SHIFT) > > + # define PR_MTE_TCF_SYNC (1UL << PR_MTE_TCF_SHIFT) > > + # define PR_MTE_TCF_ASYNC (2UL << PR_MTE_TCF_SHIFT) > > + # define PR_MTE_TCF_MASK (3UL << PR_MTE_TCF_SHIFT) > > + # define PR_MTE_TAG_SHIFT 3 > > + # define PR_MTE_TAG_MASK (0xffffUL << PR_MTE_TAG_SHIFT) > > Is there a reason not to include TCMA into the set of bits that userland can > control with this prcrl? > > I know that ordinarily TCR_ELx requires expensive syncing, but for this > particular field there is a note about "software may change this control bit on > a context switch". Which I take to mean that the usual TLB-related syncing may > be omitted. TCMA (unlike TCF) is allowed to be cached in the TLB. If we are to allow the user to configure this field, there are two approaches, each with its own problems: 1. per-thread TCMA (as we do with TCF). Since the field is cached in the TLB (ASID-tagged), we'd have to invalidate the TLB for that ASID every time we switch between threads of the same process on a CPU. 2. per-process TCMA. This solves the problem of TLB invalidation, however you'd have to synchronise all the threads that may run on other CPUs. A simple IPI (as in sys_membarrier() for example) is not sufficient since with CnP (CPU threads sharing the TLB) we'd need a synchronous update. This leaves us with a stop_machine() call and I'm not keen on exposing this to user via a syscall. If you have a strong need for TCMA in user space, please raise it and we can discuss about always allowing match-all tags for user tasks. Note that the kernel will have match-all enabled for kernel addresses. -- Catalin