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 E8748C433E3 for ; Sat, 22 Aug 2020 10:56:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9D1B020714 for ; Sat, 22 Aug 2020 10:56:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D1B020714 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 0E3826B00A2; Sat, 22 Aug 2020 06:56:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0953C6B00A3; Sat, 22 Aug 2020 06:56:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EED606B00A4; Sat, 22 Aug 2020 06:56:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id D6AA96B00A2 for ; Sat, 22 Aug 2020 06:56:14 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 85EFA180AD802 for ; Sat, 22 Aug 2020 10:56:14 +0000 (UTC) X-FDA: 77177900268.03.trail14_551111c27041 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 4BBD628A4E9 for ; Sat, 22 Aug 2020 10:56:14 +0000 (UTC) X-HE-Tag: trail14_551111c27041 X-Filterd-Recvd-Size: 3483 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Sat, 22 Aug 2020 10:56:13 +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 8E0ED2067C; Sat, 22 Aug 2020 10:56:10 +0000 (UTC) Date: Sat, 22 Aug 2020 11:56:08 +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 v7 22/29] arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support Message-ID: <20200822105607.GA16635@gaia> References: <20200715170844.30064-1-catalin.marinas@arm.com> <20200715170844.30064-23-catalin.marinas@arm.com> <95f0294b-93fb-bc5e-5ae5-fd3ada2dc7ce@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95f0294b-93fb-bc5e-5ae5-fd3ada2dc7ce@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4BBD628A4E9 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, Aug 13, 2020 at 11:01:06AM -0300, Luis Machado wrote: > There has been changes to GDB's/LLDB's side to incorporate a tag type into > the peek/poke requests. This is an attempt to anticipate required support > for other tag types, like CHERI's tags. Those are somewhat different from > MTE's tags. Please note that Morello (the ARM's CHERI implementation) won't go into mainline Linux for the time being. It's a development board to experiment with CHERI and the architecture may eventually turn out slightly different. Also note that the current Morello hardware doesn't support MTE. The tags are indeed different from the MTE ones, though both are just additional metadata associated with a set of bytes in memory. It happens that a tag in both cases corresponds to a 16-byte memory range. > The core file design for storing tags, which is in progress and currently in > my court, is also taking into account other types of tags. It makes sense for the core file. > Given the above, should we consider passing a type to the kernel ptrace > requests as well? > > Also, since the ptrace requests would have to handle different types of > tags, should we rename PEEKMTETAGS/POKEMTETAGS to PEEKTAGS/POKETAGS instead > and make those requests generic? I'm not sure how we could pass a type since ptrace() only takes a single argument for the request. We could use a different structure than iovec and encode a type in a field in the new structure but I'd rather keep the generic struct iovec. So basically the "MTE" part in PEEKMTETAGS is the type. Internally, the kernel implementation will probably translate the request into a common function call with a tag type but for the user-visible ptrace() interface, I don't see what benefits it would bring. If you have a better suggestion on how to encode the type, I'm open to discuss it. -- Catalin