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=DKIMWL_WL_HIGH,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 B787EC47254 for ; Tue, 5 May 2020 17:30:46 +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 7F952206CC for ; Tue, 5 May 2020 17:30:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BE9iWpc2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F952206CC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GLw7r7+6M1+X0R55awXZMGqjIdszXduxl1kHlsvvlME=; b=BE9iWpc2VqSxB/ dMJO18ExBpknyx/D7SzWerULHWjYqLEDbL92rlTILZA07ea/jh3eDawDOEHPyS+aXAR0x1WFaooaY 29IU0MmBJeofDE9nekFMDIGDQZ8Vmm5V8Ym3iqUGQVnKcHcBwfoz9AvOuhSNBItOrNEf+8a6B5EOJ llvlKR2ccfC7jPxng1aaunEqHsUVZmYsRRPcj/kbuL+OSBEM6Kyst02nfPZWWlXTvrD3cjq+lSDg4 UNf+v/n9eaNQp8bRDjpa21sKpnn5MHcd8phiejRWz46UJM9Y6KY3vLXc3W+xjtR4WMmKvJC+DSkzr BJ1CjqnYBKCg/hlnVPEQ==; 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 1jW1P4-00036m-0n; Tue, 05 May 2020 17:30:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jW1P0-00035B-I1 for linux-arm-kernel@lists.infradead.org; Tue, 05 May 2020 17:30:43 +0000 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 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-Disposition: inline In-Reply-To: <20200505103232.GE23080@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200505_103042_644985_44F55E04 X-CRM114-Status: GOOD ( 21.04 ) 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 , nd@arm.com, Peter Collingbourne , Andrey Konovalov , Kevin Brodsky , linux-mm@kvack.org, Vincenzo Frascino , Will Deacon , linux-arm-kernel@lists.infradead.org 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel