From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Collingbourne Subject: Re: [PATCH 00/22] arm64: Memory Tagging Extension user-space support Date: Fri, 13 Dec 2019 10:05:10 -0800 Message-ID: References: <20191211184027.20130-1-catalin.marinas@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20191211184027.20130-1-catalin.marinas@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Catalin Marinas Cc: linux-arch@vger.kernel.org, Richard Earnshaw , Kostya Kortchinsky , Kostya Serebryany , Szabolcs Nagy , Marc Zyngier , Kevin Brodsky , linux-mm@kvack.org, Evgenii Stepanov , Andrey Konovalov , Vincenzo Frascino , Will Deacon , Linux ARM List-Id: linux-arch.vger.kernel.org On Wed, Dec 11, 2019 at 10:40 AM Catalin Marinas wrote: > Hi, > > 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. > - 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. If we could disable the zero page for tagged mappings only and let the pages be faulted as they are read, that would work for us. Peter [1] https://reviews.llvm.org/D70762 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f66.google.com ([209.85.221.66]:43786 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728550AbfLMSFY (ORCPT ); Fri, 13 Dec 2019 13:05:24 -0500 Received: by mail-wr1-f66.google.com with SMTP id d16so382439wre.10 for ; Fri, 13 Dec 2019 10:05:23 -0800 (PST) MIME-Version: 1.0 References: <20191211184027.20130-1-catalin.marinas@arm.com> In-Reply-To: <20191211184027.20130-1-catalin.marinas@arm.com> From: Peter Collingbourne Date: Fri, 13 Dec 2019 10:05:10 -0800 Message-ID: Subject: Re: [PATCH 00/22] arm64: Memory Tagging Extension user-space support Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Catalin Marinas 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 Message-ID: <20191213180510.zVev99I0A1M-TwOvi9T0hA4nuyd7MA2Cy2IXbwEmRQA@z> On Wed, Dec 11, 2019 at 10:40 AM Catalin Marinas wrote: > Hi, > > 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. > - 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. If we could disable the zero page for tagged mappings only and let the pages be faulted as they are read, that would work for us. Peter [1] https://reviews.llvm.org/D70762 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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 2D96FC47409 for ; Fri, 13 Dec 2019 21:11:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 651B624682 for ; Fri, 13 Dec 2019 21:11:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Z6qcTDjw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 651B624682 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E99BB8E0010; Fri, 13 Dec 2019 13:05:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E491E8E0001; Fri, 13 Dec 2019 13:05:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5F4B8E0010; Fri, 13 Dec 2019 13:05:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id BE48C8E0001 for ; Fri, 13 Dec 2019 13:05:24 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 501793ABF for ; Fri, 13 Dec 2019 18:05:24 +0000 (UTC) X-FDA: 76260895368.13.toes15_2f201f4a2e23b X-HE-Tag: toes15_2f201f4a2e23b X-Filterd-Recvd-Size: 4147 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Dec 2019 18:05:23 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id g17so437013wro.2 for ; Fri, 13 Dec 2019 10:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+EYduUcDZi5305eYv3iFGbrJoeNChzA396oztTfjBXU=; b=Z6qcTDjwl590xiTBev2JIOwenrYEXB53zCVflq2uJiIg3qv1Y9pXnAAZ8WZv8/mbi5 X0KUBgnta6sFq5Afijzj0YTeDIfXsvC9j24/4+0BSsiuDaf096c1ID9XuihGm2bC0lCH iutnIo99KWUoEkaz6vzXVOzJz9WWMkA63FWcn0CpaeIYDX5Yo88LOdRRXYFwSqSJ8S36 lbHWSDHF3oYzpnHTFfYPkXypPOmtnnDo4cN9a6p48tvFYzTEmGQ7sELy1hAaQWoPN2XV 2M24u/AfNr7632cMFNo12oBXbt/X0+MrSVvmcen+7LrM173sKJQtNlfIecsOG+UNybBQ Imaw== 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=+EYduUcDZi5305eYv3iFGbrJoeNChzA396oztTfjBXU=; b=DwRjI4Tp08/KS4DlK5NUhiy2Ky1YgyRqDlVTzyaE6NbMdL6oyPtMslkOfu93ZwAuwF PSQMyI4IdbZ5VB04cdR04J1iHWpmNbbHk7oY2C//IdLZe72kgBFxZYKiU00GOFUePSIB gEu+Q5lZkaiXszzcAfSRD1w099jAC90cGjUYqYO4HPNaEFVOfvKUH4kCCAmr62fLiaYA cMFzxdaaKacfH/lVFQbdy8dIkMZyAU9bYFtP6SdXCGqFpYsf2bjChV7fvIMy/v+vqjHz P6x6lw9vIT927Olq75u/NTRGwj0fDHYpgg6PPh7EvfQRmv8Wg9ZTilZpFSjz9Vki0Hnw RiFg== X-Gm-Message-State: APjAAAXr15CeHvmsiY/iwpko7aUSpfU0SWqicAURz44xoisQIUg6O0JA fK/dUIbEczutKJUO892eFPd2KYdknyTbWvPMzTOxhg== X-Google-Smtp-Source: APXvYqxP7jBF9PnXnDysL/SrUBCGW3Lv4EcU5tUKWTw5jUIPDgtI/jqhKpKkKz3Y5IvwtOULGC1TyfC1kP6l9kY7Leo= X-Received: by 2002:a5d:4984:: with SMTP id r4mr13660823wrq.137.1576260322155; Fri, 13 Dec 2019 10:05:22 -0800 (PST) MIME-Version: 1.0 References: <20191211184027.20130-1-catalin.marinas@arm.com> In-Reply-To: <20191211184027.20130-1-catalin.marinas@arm.com> From: Peter Collingbourne Date: Fri, 13 Dec 2019 10:05:10 -0800 Message-ID: Subject: Re: [PATCH 00/22] arm64: Memory Tagging Extension user-space support To: Catalin Marinas 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 Content-Type: text/plain; charset="UTF-8" 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, Dec 11, 2019 at 10:40 AM Catalin Marinas wrote: > Hi, > > 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. > - 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. If we could disable the zero page for tagged mappings only and let the pages be faulted as they are read, that would work for us. Peter [1] https://reviews.llvm.org/D70762 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=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,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 53A82C00454 for ; Fri, 13 Dec 2019 22:31:21 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 2D57E20706 for ; Fri, 13 Dec 2019 22:31:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AsIkno4K"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="Z6qcTDjw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D57E20706 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mj/R0D0EPZbrWkA4zDJUpo9heAuasv9sHbL8ZqymGwQ=; b=AsIkno4KBAgRtI u6dmW8TM3sQubfhupyRoPF74BjXnRCzzeCzLV3DABOV7pebhGNJAC0N1OMziPdjnn739hHqnsXs9+ smUaVKCWZEW+hZER3mW+i/1uOoQPGtuHFPkkeEB6Zzh63OfYzSf23DqRL5ZqOUnb8CMH67ZUBv9Vt syMvlnVUOK96kCc04OzJgCWliOn7a2Qfm2LBD9MMvqA7LefLFQBS5l/7SvPUrlFOVDC6QDWOOTrh4 JVe3bXiBbb1GSsospt3k7XhMXbmO7Ta8CQH97Uv1Hv9Xch5dwewc0ZvDlxtCj3bg5AEMl75fMyvY7 uNjhS2eaQ5Lo/CN4ZZZw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ifpJh-0005eW-So; Fri, 13 Dec 2019 18:05:29 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ifpJe-0005dN-BU for linux-arm-kernel@lists.infradead.org; Fri, 13 Dec 2019 18:05:27 +0000 Received: by mail-wr1-x444.google.com with SMTP id t2so452113wrr.1 for ; Fri, 13 Dec 2019 10:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+EYduUcDZi5305eYv3iFGbrJoeNChzA396oztTfjBXU=; b=Z6qcTDjwl590xiTBev2JIOwenrYEXB53zCVflq2uJiIg3qv1Y9pXnAAZ8WZv8/mbi5 X0KUBgnta6sFq5Afijzj0YTeDIfXsvC9j24/4+0BSsiuDaf096c1ID9XuihGm2bC0lCH iutnIo99KWUoEkaz6vzXVOzJz9WWMkA63FWcn0CpaeIYDX5Yo88LOdRRXYFwSqSJ8S36 lbHWSDHF3oYzpnHTFfYPkXypPOmtnnDo4cN9a6p48tvFYzTEmGQ7sELy1hAaQWoPN2XV 2M24u/AfNr7632cMFNo12oBXbt/X0+MrSVvmcen+7LrM173sKJQtNlfIecsOG+UNybBQ Imaw== 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=+EYduUcDZi5305eYv3iFGbrJoeNChzA396oztTfjBXU=; b=Ie3E4tpJungX61H9n7UkQgKV3nPGzmxw46bDArgdquOZoCeJt2exuWseNWuWOOEI6f jSeOupW2Sc26wcZTCZAKoE/2jYwKlArd03YwvMAfeUH3nA+D4OfGgO/f+LVQeZW3jR/p RCGzMIW+fN8GgWMcwHl45ph5A1whzvqFvLc2CPA1pQfABvQE64xfsrEG+kkyLsy63o28 +JSofIFh1aZxm28WUnMSPwI/0jhfe/t5lSF0ebDALNnrl/X4siReNrOnUkZPnx5mqe+b dzhdcI9A7xSCeNetEQXPDna1hiYPFks7drpy4L+Y8JNnHSWqPjx9nwnt+rwsJCZJAbYy Fzsg== X-Gm-Message-State: APjAAAUE3Pw2TLisBT1QuQuxwqx3AwFlO4UWJWCmbQUt+hekdVftkK99 tPGG2fXtuzhW01N40yn3QWgomBwJpcHz8/sxUAWNr6BnioM= X-Google-Smtp-Source: APXvYqxP7jBF9PnXnDysL/SrUBCGW3Lv4EcU5tUKWTw5jUIPDgtI/jqhKpKkKz3Y5IvwtOULGC1TyfC1kP6l9kY7Leo= X-Received: by 2002:a5d:4984:: with SMTP id r4mr13660823wrq.137.1576260322155; Fri, 13 Dec 2019 10:05:22 -0800 (PST) MIME-Version: 1.0 References: <20191211184027.20130-1-catalin.marinas@arm.com> In-Reply-To: <20191211184027.20130-1-catalin.marinas@arm.com> From: Peter Collingbourne Date: Fri, 13 Dec 2019 10:05:10 -0800 Message-ID: Subject: Re: [PATCH 00/22] arm64: Memory Tagging Extension user-space support To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191213_100526_398331_E5404941 X-CRM114-Status: GOOD ( 11.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Richard Earnshaw , Kostya Kortchinsky , Kostya Serebryany , Szabolcs Nagy , Marc Zyngier , Kevin Brodsky , linux-mm@kvack.org, Evgenii Stepanov , Andrey Konovalov , Vincenzo Frascino , Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Dec 11, 2019 at 10:40 AM Catalin Marinas wrote: > Hi, > > 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. > - 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. If we could disable the zero page for tagged mappings only and let the pages be faulted as they are read, that would work for us. Peter [1] https://reviews.llvm.org/D70762 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel