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,URIBL_BLOCKED,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 A76E6C433FF for ; Fri, 2 Aug 2019 10:20:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 88EEF2073D for ; Fri, 2 Aug 2019 10:20:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391161AbfHBKUk (ORCPT ); Fri, 2 Aug 2019 06:20:40 -0400 Received: from foss.arm.com ([217.140.110.172]:49040 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389243AbfHBKUk (ORCPT ); Fri, 2 Aug 2019 06:20:40 -0400 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 E44A3344; Fri, 2 Aug 2019 03:20:38 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 26BB63F71F; Fri, 2 Aug 2019 03:20:34 -0700 (PDT) Date: Fri, 2 Aug 2019 11:20:32 +0100 From: Catalin Marinas To: Dave Hansen Cc: Andrey Konovalov , Kevin Brodsky , Linux ARM , Linux Memory Management List , LKML , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, kvm@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Will Deacon , Mark Rutland , Andrew Morton , Greg Kroah-Hartman , Kees Cook , Yishai Hadas , Felix Kuehling , Alexander Deucher , Christian Koenig , Mauro Carvalho Chehab , Jens Wiklander , Alex Williamson , Leon Romanovsky , Luc Van Oostenryck , Dave Martin , Khalid Aziz , enh , Jason Gunthorpe , Christoph Hellwig , Dmitry Vyukov , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Robin Murphy , Szabolcs Nagy Subject: Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel Message-ID: <20190802102031.GB4175@arrakis.emea.arm.com> References: <8c618cc9-ae68-9769-c5bb-67f1295abc4e@intel.com> <13b4cf53-3ecb-f7e7-b504-d77af15d77aa@arm.com> <96fd8da4-a912-f6cc-2b32-5791027dbbd5@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96fd8da4-a912-f6cc-2b32-5791027dbbd5@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Thu, Aug 01, 2019 at 08:36:47AM -0700, Dave Hansen wrote: > On 8/1/19 5:48 AM, Andrey Konovalov wrote: > > On Thu, Aug 1, 2019 at 2:11 PM Kevin Brodsky wrote: > >> On 31/07/2019 17:50, Dave Hansen wrote: > >>> On 7/23/19 10:58 AM, Andrey Konovalov wrote: > >>>> The mmap and mremap (only new_addr) syscalls do not currently accept > >>>> tagged addresses. Architectures may interpret the tag as a background > >>>> colour for the corresponding vma. > >>> > >>> What the heck is a "background colour"? :) > >> > >> Good point, this is some jargon that we started using for MTE, the idea being that > >> the kernel could set a tag value (specified during mmap()) as "background colour" for > >> anonymous pages allocated in that range. > >> > >> Anyway, this patch series is not about MTE. Andrey, for v20 (if any), I think it's > >> best to drop this last sentence to avoid any confusion. Indeed, the part with the "background colour" and even the "currently" adverb should be dropped. Also, if we merge the patches via different trees anyway, I don't think there is a need for Andrey to integrate them with his series. We can pick them up directly in the arm64 tree (once the review finished). > OK, but what does that mean for tagged addresses getting passed to > mmap/mremap? That sentence read to me like "architectures might allow > tags for ...something...". So do we accept tagged addresses into those > syscalls? If mmap() does not return a tagged address, the reasoning is that it should not accept one as an address hint (with or without MAP_FIXED). Note that these docs should only describe the top-byte-ignore ABI while leaving the memory tagging for a future patchset. In that future patchset, we may want to update the mmap() ABI to allow, only in conjunction with PROT_MTE, a tagged pointer as an address argument. In such case mmap() will return a tagged address and the pages pre-coloured (on fault) with the tag requested by the user. As I said, that's to be discussed later in the year. -- Catalin