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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 6503EC433DF for ; Fri, 3 Jul 2020 13:20:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 2E72A20760 for ; Fri, 3 Jul 2020 13:20:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XvnOVt2f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E72A20760 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+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=merlin.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=oGu1XxxiPGV3X4NVX7XPIjy75BuUseuKche5PjV/50k=; b=XvnOVt2fQLH0DL70fV6YEYFAK 8DwSFyM72e02xf5gMZSd0ipoJ0VmX9ExUr+HU0kG7pD4jmZaAuEhui/eTC8PC8j4gdkrb87Q0BEAq Ezp1WLzICSX0FWuA/y4LBewm+FtQeAoFkpqwIsRh7Exw2ad5sPBsW1jT4+R32LZgQxMSBjjb2enBw +6UprM8hMMaL/gR0rdvRRVVMbYKSFGYPs0VhTGb+WMFQOGbHQOcZp+4ABWoVOMqbCb+1S+sLEMIGe U4svHyE6eIoM6R2A3KyWpLkuzNI/qnSu2DPkrR5GCqaXBQMJGRnTR5CES5qAZM0RZhmjD9ivsbY0s XYzIgLcPg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrLah-0001Rq-TE; Fri, 03 Jul 2020 13:18:55 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrLag-0001R7-2d for linux-arm-kernel@lists.infradead.org; Fri, 03 Jul 2020 13:18:54 +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 0951B31B; Fri, 3 Jul 2020 06:18:50 -0700 (PDT) Received: from gaia (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 263D13F73C; Fri, 3 Jul 2020 06:18:48 -0700 (PDT) Date: Fri, 3 Jul 2020 14:18:37 +0100 From: Catalin Marinas To: Luis Machado Subject: Re: [PATCH v5 19/25] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support Message-ID: <20200703123117.GC14950@gaia> References: <20200624175244.25837-1-catalin.marinas@arm.com> <20200624175244.25837-20-catalin.marinas@arm.com> <7fd536af-f9fa-aa10-a4c3-001e80dd7d7b@linaro.org> <20200701171549.GF5191@gaia> <8fa5c891-0f4a-c925-679e-94c41a546490@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8fa5c891-0f4a-c925-679e-94c41a546490@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200703_091854_171826_9ED8FAF4 X-CRM114-Status: GOOD ( 24.97 ) 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, Omair Javaid , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , Peter Collingbourne , linux-mm@kvack.org, Alan Hayward , Andrew Morton , Vincenzo Frascino , Will Deacon , Dave P Martin , 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+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 01, 2020 at 02:32:43PM -0300, Luis Machado wrote: > On 7/1/20 2:16 PM, Catalin Marinas wrote: > > 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 > > If I recall the previous discussion correctly, Kevin thought access to both > of these would be interesting to the user. It sounded like having read-only > access was enough. If so,... > > > prctl() value would be a better option than the raw register bits (well, > > not entirely raw, masking out the irrelevant part). > > ... then exposing the most useful bits to the user would be better, and up > to you to define. > > I can tweak the GDB patches to turn the sctlr and gcr values into flag > fields. Then GDB can just show those in a more meaningful way. I just need > to know what the bits would look like. We may have some software only behaviour added to these bits at some point (e.g. deliver signal on return from syscall for faults on the uaccess routines). They would not be represented in the SCTLR/GCR registers. > I'd rather not make these values writable if we don't think there is a good > use case for it. Better avoid giving developers more knobs than they need? There's the CRIU use-case for restoring this but I don't think we do it for other prctl() controls. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel