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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D809EC2BA83 for ; Thu, 13 Feb 2020 11:23:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A0AA42073C for ; Thu, 13 Feb 2020 11:23:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A0AA42073C 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 428FB6B052B; Thu, 13 Feb 2020 06:23:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D9026B052D; Thu, 13 Feb 2020 06:23:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EDED6B052E; Thu, 13 Feb 2020 06:23:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 167DB6B052B for ; Thu, 13 Feb 2020 06:23:52 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9479C180AD815 for ; Thu, 13 Feb 2020 11:23:51 +0000 (UTC) X-FDA: 76484869062.03.stone87_4868ac2d9060 X-HE-Tag: stone87_4868ac2d9060 X-Filterd-Recvd-Size: 2901 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 11:23:50 +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 2FE651FB; Thu, 13 Feb 2020 03:23:50 -0800 (PST) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6ACBA3F6CF; Thu, 13 Feb 2020 03:23:48 -0800 (PST) Date: Thu, 13 Feb 2020 11:23:46 +0000 From: Catalin Marinas To: Peter Collingbourne Cc: Linux ARM , linux-arch@vger.kernel.org, Richard Earnshaw , Szabolcs Nagy , Marc Zyngier , Kevin Brodsky , linux-mm@kvack.org, Andrey Konovalov , Vincenzo Frascino , Will Deacon , Evgenii Stepanov , Kostya Kortchinsky , Kostya Serebryany Subject: Re: [PATCH 00/22] arm64: Memory Tagging Extension user-space support Message-ID: <20200213112346.GA639258@arrakis.emea.arm.com> References: <20191211184027.20130-1-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Dec 13, 2019 at 10:05:10AM -0800, Peter Collingbourne wrote: > On Wed, Dec 11, 2019 at 10:40 AM Catalin Marinas > wrote: > > This series proposes the initial user-space support for the ARMv8.5 > > Memory Tagging Extension [1]. > > Thanks for sending out this series. I have been testing it on Android > with the FVP model and my in-development scudo changes that add memory > tagging support [1], and have not noticed any problems so far. Thanks for the comments so far and the testing. I'll post a v2 next week. > > - Clarify whether mmap(tagged_addr, PROT_MTE) pre-tags the memory with > > the tag given in the tagged_addr hint. Strong justification is > > required for this as it would force arm64 to disable the zero page. > > We would like to use this feature in scudo to tag large (>128KB on > Android) allocations, which are currently allocated via mmap rather > than from an allocation pool. Otherwise we would need to pay the cost > (perf and RSS) of faulting all of their pages at allocation time > instead of on demand, if we want to tag them. Would the default tag of 0 be sufficient here? We disable match-all for user-space already, so 0 is not a wildcard. -- Catalin