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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 9A1CFC432BE for ; Thu, 26 Aug 2021 16:00:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 67FA161038 for ; Thu, 26 Aug 2021 16:00:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 67FA161038 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=dn0ThOCWuAvknKwbCWnr3lf5Pi9MG1diAswbQw8Gpp8=; b=Ia2c3bzaNvLg+ebF6jhXnC+PBP czi70ql1cr/wCforCFquoDf5kiYoWhPV+B7bTLcj3h26w3pVIznZQbjGAf5yy2xBhOX4gtw7jBVTA orgRAUB8eQlUqxeXOYhubcTXM39acyzU/W/O/j0NcwWpKOqYtLzBFoMTiHoXXlmIyyNSlYThSHkyZ qnG7bkkWNDTrMJXV2M6JZi6OzrWBnhT16TwzDNohJdTCHOMM7iU284Cf3xVZQGZLEdT0smihwWVff FDwMwjJyFr2DbU1ICvA245VEg8/oA1H5rZu2vA8nFXobJyfQNZ5Ny5XJIv1eUNRa3noFxkZdzNRhI gjjkoYdQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJHlh-00AWT9-3A; Thu, 26 Aug 2021 15:58:17 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJHle-00AWSm-BD for linux-arm-kernel@bombadil.infradead.org; Thu, 26 Aug 2021 15:58:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9nLQYbnGN+yi8mzweg9S/BoVh7fXlR4Py2/ta8hD65Q=; b=tx+bIuZz2L7/E2mnDkDbI1m9ok DTmNEXjlCFgU763DetkoeRPBvC1MZd8xxzRPOTbvGIdaseWI9zy0PUmaF/Re9+kJGQezlqTwncGNn 4sG+K1DHAmugSO6kggph3NXUgt8Gw4l1xVcC58o2xD+0Mf0N+Qhx08RCrHMwcTuQ7Y5WV/llnqylW DYnIFyPIg5p5PnkGEHffhA23amHQGVOm8NZqQEZvylF4Mrhodi1tpOP08ZgUHcf7U4XNMCt2EIyqP GC2NoirHbuzBbOepf2ztJZeNLHEn3zD0yRCjeQztYXgY4JgN2uQH/ukzLudsHsdRpqDoeD81DBJ/Q 2VJp/CNw==; Received: from heliosphere.sirena.org.uk ([172.104.155.198]) by casper.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJHkp-00DRVr-GL for linux-arm-kernel@lists.infradead.org; Thu, 26 Aug 2021 15:57:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9nLQYbnGN+yi8mzweg9S/BoVh7fXlR4Py2/ta8hD65Q=; b=B5YrvnCAVI2lJ6r7GQ1Ka2YhFl WfyqQP3qnVy3QK0DixM0bEOMTzJ6f0lxs2i2jTX0tOE5tg9O1zPjq90AUEMcVnWj8WFo2RvUuwKTv 1yOUsoWh7EAA53sJ15f5yX7wbyQW8S65Yao6uL7hNFyKJCSut0ojScMPWyv5246t91Zk=; Received: from 94.196.67.80.threembb.co.uk ([94.196.67.80] helo=fitzroy.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mJHkY-00FUba-Qf; Thu, 26 Aug 2021 15:57:07 +0000 Received: by fitzroy.sirena.org.uk (Postfix, from userid 1000) id 16BDCD01BF1; Thu, 26 Aug 2021 16:57:04 +0100 (BST) Date: Thu, 26 Aug 2021 16:57:04 +0100 From: Mark Brown To: madvenka@linux.microsoft.com Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, jthierry@redhat.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v8 3/4] arm64: Introduce stack trace reliability checks in the unwinder Message-ID: References: <20210812190603.25326-1-madvenka@linux.microsoft.com> <20210812190603.25326-4-madvenka@linux.microsoft.com> MIME-Version: 1.0 In-Reply-To: <20210812190603.25326-4-madvenka@linux.microsoft.com> X-Cookie: I can relate to that. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210826_165742_840987_061759C6 X-CRM114-Status: GOOD ( 12.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2178151340760992811==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2178151340760992811== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DTeBTo7twGoyd0rG" Content-Disposition: inline --DTeBTo7twGoyd0rG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 12, 2021 at 02:06:02PM -0500, madvenka@linux.microsoft.com wrote: > + if (frame->need_reliable && !unwind_is_reliable(frame)) { > + /* Cannot unwind to the next frame reliably. */ > + frame->failed = true; > + return false; > + } This means we only collect reliability information in the case where we're specifically doing a reliable stacktrace. For example when printing stack traces on the console it might be useful to print a ? or something if the frame is unreliable as a hint to the reader that the information might be misleading. Could we therefore change the flag here to a reliability one and our need_reliable check so that we always run unwind_is_reliable()? I'm not sure if we need to abandon the trace on first error when doing a reliable trace but I can see it's a bit safer so perhaps better to do so. If we don't abandon then we don't require the need_reliable check at all. --DTeBTo7twGoyd0rG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmEnuc8ACgkQJNaLcl1U h9BFrAf+N3yJJQuwCLxv36qPYIv8rK67Wg7vq6QHBv9olYSZOaay2RqDa9LKPVps cIOnOsjsnjWwchw6R0ynXbK3UvrxZP3Mhl3hN/O0ajYq1ffUxoVzsfiAfLvgDjj1 eK8FP8165XKy6IN7u+OFyomrl7nSKOO4zWRJw5Ce71CcTHnegpxVPb5V4OaMwK28 pOaupCfunPrZyXaHZjpnbZinxAQqtCY/IZU4ztW+0tk78TkK07nbFYUAgmQC9drb gc4bkfHPdW+L8IUx5fIavhjSiVQHVdes0+u1EAajOmvEYvV8WTklgE0NekkbGPrm E2aQIY1iWIMZ3PFZnPkx1VYALA/qsg== =JSFk -----END PGP SIGNATURE----- --DTeBTo7twGoyd0rG-- --===============2178151340760992811== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============2178151340760992811==-- 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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 2596BC432BE for ; Thu, 26 Aug 2021 16:24:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 065A561076 for ; Thu, 26 Aug 2021 16:24:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243068AbhHZQZi (ORCPT ); Thu, 26 Aug 2021 12:25:38 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:45766 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233834AbhHZQZb (ORCPT ); Thu, 26 Aug 2021 12:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9nLQYbnGN+yi8mzweg9S/BoVh7fXlR4Py2/ta8hD65Q=; b=B5YrvnCAVI2lJ6r7GQ1Ka2YhFl WfyqQP3qnVy3QK0DixM0bEOMTzJ6f0lxs2i2jTX0tOE5tg9O1zPjq90AUEMcVnWj8WFo2RvUuwKTv 1yOUsoWh7EAA53sJ15f5yX7wbyQW8S65Yao6uL7hNFyKJCSut0ojScMPWyv5246t91Zk=; Received: from 94.196.67.80.threembb.co.uk ([94.196.67.80] helo=fitzroy.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mJHkY-00FUba-Qf; Thu, 26 Aug 2021 15:57:07 +0000 Received: by fitzroy.sirena.org.uk (Postfix, from userid 1000) id 16BDCD01BF1; Thu, 26 Aug 2021 16:57:04 +0100 (BST) Date: Thu, 26 Aug 2021 16:57:04 +0100 From: Mark Brown To: madvenka@linux.microsoft.com Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, jthierry@redhat.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v8 3/4] arm64: Introduce stack trace reliability checks in the unwinder Message-ID: References: <20210812190603.25326-1-madvenka@linux.microsoft.com> <20210812190603.25326-4-madvenka@linux.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DTeBTo7twGoyd0rG" Content-Disposition: inline In-Reply-To: <20210812190603.25326-4-madvenka@linux.microsoft.com> X-Cookie: I can relate to that. Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --DTeBTo7twGoyd0rG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 12, 2021 at 02:06:02PM -0500, madvenka@linux.microsoft.com wrote: > + if (frame->need_reliable && !unwind_is_reliable(frame)) { > + /* Cannot unwind to the next frame reliably. */ > + frame->failed = true; > + return false; > + } This means we only collect reliability information in the case where we're specifically doing a reliable stacktrace. For example when printing stack traces on the console it might be useful to print a ? or something if the frame is unreliable as a hint to the reader that the information might be misleading. Could we therefore change the flag here to a reliability one and our need_reliable check so that we always run unwind_is_reliable()? I'm not sure if we need to abandon the trace on first error when doing a reliable trace but I can see it's a bit safer so perhaps better to do so. If we don't abandon then we don't require the need_reliable check at all. --DTeBTo7twGoyd0rG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmEnuc8ACgkQJNaLcl1U h9BFrAf+N3yJJQuwCLxv36qPYIv8rK67Wg7vq6QHBv9olYSZOaay2RqDa9LKPVps cIOnOsjsnjWwchw6R0ynXbK3UvrxZP3Mhl3hN/O0ajYq1ffUxoVzsfiAfLvgDjj1 eK8FP8165XKy6IN7u+OFyomrl7nSKOO4zWRJw5Ce71CcTHnegpxVPb5V4OaMwK28 pOaupCfunPrZyXaHZjpnbZinxAQqtCY/IZU4ztW+0tk78TkK07nbFYUAgmQC9drb gc4bkfHPdW+L8IUx5fIavhjSiVQHVdes0+u1EAajOmvEYvV8WTklgE0NekkbGPrm E2aQIY1iWIMZ3PFZnPkx1VYALA/qsg== =JSFk -----END PGP SIGNATURE----- --DTeBTo7twGoyd0rG--