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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F1FD2C47247 for ; Tue, 5 May 2020 17:30:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC90520721 for ; Tue, 5 May 2020 17:30:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC90520721 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 3AAFB8E0005; Tue, 5 May 2020 13:30:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35B1C8E0003; Tue, 5 May 2020 13:30:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2707B8E0005; Tue, 5 May 2020 13:30:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0154.hostedemail.com [216.40.44.154]) by kanga.kvack.org (Postfix) with ESMTP id 0D4B28E0003 for ; Tue, 5 May 2020 13:30:42 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AE90C8248D51 for ; Tue, 5 May 2020 17:30:41 +0000 (UTC) X-FDA: 76783355082.16.woman65_7a67d1df5d318 X-HE-Tag: woman65_7a67d1df5d318 X-Filterd-Recvd-Size: 3953 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 17:30:41 +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 39A4B31B; Tue, 5 May 2020 10:30:40 -0700 (PDT) Received: from C02TF0J2HF1T.local (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CE3D63F305; Tue, 5 May 2020 10:30:36 -0700 (PDT) Date: Tue, 5 May 2020 18:30:29 +0100 From: Catalin Marinas To: Szabolcs Nagy Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Vincenzo Frascino , Richard Earnshaw , Kevin Brodsky , Andrey Konovalov , Peter Collingbourne , linux-mm@kvack.org, linux-arch@vger.kernel.org, nd@arm.com Subject: Re: [PATCH v3 23/23] arm64: mte: Add Memory Tagging Extension documentation Message-ID: <20200505173029.GB81129@C02TF0J2HF1T.local> References: <20200421142603.3894-1-catalin.marinas@arm.com> <20200421142603.3894-24-catalin.marinas@arm.com> <20200505103232.GE23080@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200505103232.GE23080@arm.com> 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 Tue, May 05, 2020 at 11:32:33AM +0100, Szabolcs Nagy wrote: > The 04/21/2020 15:26, Catalin Marinas wrote: > > +PROT_MTE > > +-------- > > + > > +To access the allocation tags, a user process must enable the Tagged > > +memory attribute on an address range using a new ``prot`` flag for > > +``mmap()`` and ``mprotect()``: > > + > > +``PROT_MTE`` - Pages allow access to the MTE allocation tags. > > + > > +The allocation tag is set to 0 when such pages are first mapped in the > > +user address space and preserved on copy-on-write. ``MAP_SHARED`` is > > +supported and the allocation tags can be shared between processes. > > + > > +**Note**: ``PROT_MTE`` is only supported on ``MAP_ANONYMOUS`` and > > +RAM-based file mappings (``tmpfs``, ``memfd``). Passing it to other > > +types of mapping will result in ``-EINVAL`` returned by these system > > +calls. > > + > > +**Note**: The ``PROT_MTE`` flag (and corresponding memory type) cannot > > +be cleared by ``mprotect()``. > > i think there are some non-obvious madvise operations that may > be worth documenting too for mte specific semantics. > > e.g. MADV_DONTNEED or MADV_FREE can presumably drop tags which > means that existing pointers can no longer write to the memory > which is a change of behaviour compared to the non-mte case. > (affects most malloc implementations that will have to deal > with this when implementing heap coloring) there might be other > similar problems like MADV_WIPEONFORK that wont work as > currently expected when mte is enabled. > > if such behaviour changes cause serious problems to existing > software there may be a need to have a way to opt out from > these changes (e.g. MADV_ flag variant that only affects the > memory content but not the tags) or to make that the default > behaviour. (but i can't tell how widely these are used in > ways that can be expected to work with PROT_MTE) Thanks. I'll document this behaviour as it may not be obvious. For the record (as we discussed this internally), I think the kernel behaviour is entirely expected. On mmap(PROT_MTE), the kernel would return pages with tags set to 0. On madvise(MADV_DONTNEED), the kernel may free the pages but map them back on access using the same conditions they were previously given to the user, i.e. tags set to 0. There isn't any expectations for the kernel to preserve the tags of MADV_DONTNEED/FREE pages (which defeats the point of dontneed/free). -- Catalin