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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 DC424C433DF for ; Sat, 22 Aug 2020 11:31:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9A592207CD for ; Sat, 22 Aug 2020 11:31:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A592207CD 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 283B46B00A5; Sat, 22 Aug 2020 07:31:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20DC86B00A7; Sat, 22 Aug 2020 07:31:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FB916B00A8; Sat, 22 Aug 2020 07:31:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id EA8996B00A5 for ; Sat, 22 Aug 2020 07:31:44 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B24B53631 for ; Sat, 22 Aug 2020 11:31:44 +0000 (UTC) X-FDA: 77177989728.07.kick10_27128d527041 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 906BB1803F9AD for ; Sat, 22 Aug 2020 11:31:44 +0000 (UTC) X-HE-Tag: kick10_27128d527041 X-Filterd-Recvd-Size: 2943 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Sat, 22 Aug 2020 11:31:44 +0000 (UTC) Received: from gaia (unknown [95.146.230.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CE41820738; Sat, 22 Aug 2020 11:31:40 +0000 (UTC) Date: Sat, 22 Aug 2020 12:31:38 +0100 From: Catalin Marinas To: Paul Eggert Cc: Szabolcs Nagy , linux-arch@vger.kernel.org, Richard Earnshaw , nd@arm.com, libc-alpha@sourceware.org, Will Deacon , Andrey Konovalov , Kevin Brodsky , linux-mm@kvack.org, Matthew Malcomson , Andrew Morton , Vincenzo Frascino , Peter Collingbourne , Dave Martin , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 29/29] arm64: mte: Add Memory Tagging Extension documentation Message-ID: <20200822113138.GC16635@gaia> References: <20200728145350.GR7127@arm.com> <20200728195957.GA31698@gaia> <20200803124309.GC14398@arm.com> <20200807151906.GM6750@gaia> <20200810141309.GK14398@arm.com> <20200811172038.GB1429@gaia> <20200812124520.GP14398@arm.com> <20200819095453.GA86@DESKTOP-O1885NU.localdomain> <20200820164313.GL29343@arm.com> <80a8937b-6e48-44ce-221c-84c6d27b211d@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80a8937b-6e48-44ce-221c-84c6d27b211d@cs.ucla.edu> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 906BB1803F9AD X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Thu, Aug 20, 2020 at 10:27:43AM -0700, Paul Eggert wrote: > On 8/20/20 9:43 AM, Szabolcs Nagy wrote: > > the compat issue with this is existing code > > using pointer top bits which i assume faults > > when dereferenced with the mte checks enabled. > > (although this should be very rare since > > top byte ignore on deref is aarch64 specific.) > > Does anyone know of significant aarch64-specific application code that > depends on top byte ignore? I would think it's so rare (nonexistent?) as to > not be worth worrying about. Apart from the LLVM hwasan feature, I'm not aware of code relying on the top byte ignore. There were discussions in the past to use it with some JITs but I'm not sure they ever materialised. I think the Mozilla JS engine uses (used?) additional bits on top of a pointer but they are masked out before the access. > Even in the bad old days when Emacs used pointer top bits for typechecking, > it carefully removed those bits before dereferencing. Any other > reasonably-portable application would have to do the same of course. I agree. -- Catalin