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.5 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 D4A59C433E0 for ; Wed, 1 Jul 2020 17:16:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9BD8620747 for ; Wed, 1 Jul 2020 17:16:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BD8620747 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 E12EE8D0047; Wed, 1 Jul 2020 13:16:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9B068D0016; Wed, 1 Jul 2020 13:16:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C633B8D0047; Wed, 1 Jul 2020 13:16:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id A97218D0016 for ; Wed, 1 Jul 2020 13:16:16 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 40BB6181AC9CC for ; Wed, 1 Jul 2020 17:16:16 +0000 (UTC) X-FDA: 76990160352.14.pan91_35115b526e82 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 16F4018229818 for ; Wed, 1 Jul 2020 17:16:16 +0000 (UTC) X-HE-Tag: pan91_35115b526e82 X-Filterd-Recvd-Size: 2723 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 1 Jul 2020 17:16:15 +0000 (UTC) Received: from gaia (unknown [95.146.230.158]) (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 DB9522078A; Wed, 1 Jul 2020 17:16:11 +0000 (UTC) Date: Wed, 1 Jul 2020 18:16:09 +0100 From: Catalin Marinas To: Luis Machado Cc: linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, Will Deacon , Dave P Martin , Vincenzo Frascino , Szabolcs Nagy , Kevin Brodsky , Andrey Konovalov , Peter Collingbourne , Andrew Morton , Alan Hayward , Omair Javaid Subject: Re: [PATCH v5 19/25] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support Message-ID: <20200701171549.GF5191@gaia> References: <20200624175244.25837-1-catalin.marinas@arm.com> <20200624175244.25837-20-catalin.marinas@arm.com> <7fd536af-f9fa-aa10-a4c3-001e80dd7d7b@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7fd536af-f9fa-aa10-a4c3-001e80dd7d7b@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 16F4018229818 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: Hi Luis, On Thu, Jun 25, 2020 at 02:10:10PM -0300, Luis Machado wrote: > I have one point below I wanted to clarify regarding > PEEKMTETAGS/POKEMTETAGS. > > But before that, I've pushed v2 of the MTE series for GDB here: > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/luisgpm/aarch64-mte-v2 > > That series adds sctlr and gcr registers to the NT_ARM_MTE (still using a > dummy value of 0x407) register set. It would be nice if the Linux Kernel and > the debuggers were in sync in terms of supporting this new register set. GDB > assumes the register set exists if HWCAP2_MTE is there. > > So, if we want to adjust the register set, we should probably consider doing > that now. That prevents the situation where debuggers would need to do > another check to confirm NT_ARM_MTE is exported. I'd rather avoid that. I'm happy to do this before merging, though we need to agree on the semantics. Do you need both read and write access? Also wondering whether the prctl() value would be a better option than the raw register bits (well, not entirely raw, masking out the irrelevant part). -- Catalin