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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 3E0A7C48BC2 for ; Fri, 25 Jun 2021 15:51:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 22AF561960 for ; Fri, 25 Jun 2021 15:51:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230032AbhFYPyO (ORCPT ); Fri, 25 Jun 2021 11:54:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:45138 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229774AbhFYPyN (ORCPT ); Fri, 25 Jun 2021 11:54:13 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E28C56195D; Fri, 25 Jun 2021 15:51:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624636312; bh=Q6AwIy7XeT7mjSj18u1iyC3ch7ZFJBonoUlzckIGJz0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pPYAhl3YvsV9Mx6354i5NxPxvzH84VwzuxVv6pFzswdd4gal4OHM9RH6y8ra0PUMb dyx7Jy+fparTreYxynyFKh+dXu3NkK71FXlJ7cxU22kb7SiVJjinngh1OVXY+a1Dhu Xtjmm1KEUUdLSHpivR3oxXlhK+EkVXsRIY/CBlVuxQ1a6O8290ZsLyKUqnrypn3XrY R+QIHzZvs3BSAS+2u712PXr6jdHCfnYnZTXhO8SxKl5cdRa6XvS6UOA0AlW+3x23Q0 eLgen7qddzwPa3nSVhaOA0nYl5pKZfZ4eew9dLHWCcRtV0q5SlLQ3H266GX8YC+yz3 jcL7OCDZ0FfdQ== Date: Fri, 25 Jun 2021 16:51:27 +0100 From: Mark Brown To: "Madhavan T. Venkataraman" Cc: Mark Rutland , jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.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 v5 1/2] arm64: Introduce stack trace reliability checks in the unwinder Message-ID: <20210625155127.GC4492@sirena.org.uk> References: <20210526214917.20099-1-madvenka@linux.microsoft.com> <20210526214917.20099-2-madvenka@linux.microsoft.com> <20210624144021.GA17937@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Izn7cH1Com+I3R9J" Content-Disposition: inline In-Reply-To: X-Cookie: HELLO, everybody, I'm a HUMAN!! User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 25, 2021 at 10:39:57AM -0500, Madhavan T. Venkataraman wrote: > On 6/24/21 9:40 AM, Mark Rutland wrote: > > At a high-level, I'm on-board with keeping track of this per unwind > > step, but if we do that then I want to be abel to use this during > > regular unwinds (e.g. so that we can have a backtrace idicate when a > > step is not reliable, like x86 does with '?'), and to do that we need to > > be a little more accurate. > The only consumer of frame->reliable is livepatch. So, in retrospect, my > original per-frame reliability flag was an overkill. I was just trying to > provide extra per-frame debug information which is not really a requirement > for livepatch. It's not a requirement for livepatch but if it's there a per frame reliability flag would have other uses - for example Mark has mentioned the way x86 prints a ? next to unreliable entries in oops output for example, that'd be handy for people debugging issues and would have the added bonus of ensuring that there's more constant and widespread exercising of the reliability stuff than if it's just used for livepatch which is a bit niche. > So, let us separate the two. I will rename frame->reliable to frame->livepatch_safe. > This will apply to the whole stacktrace and not to every frame. I'd rather keep it as reliable, even with only the livepatch usage I think it's clearer. > Finally, it might be a good idea to perform reliability checks even in > start_backtrace() so we don't assume that the starting frame is reliable even > if the caller passes livepatch_safe=true. What do you think? That makes sense to me. --Izn7cH1Com+I3R9J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDV+34ACgkQJNaLcl1U h9Ch+wf7BDR5lejSlhWSQ/gqNm01WBJhVAeZE6s4y9+c0vbutI3yLY2OcMHxA4n7 AqJifvW72eAeiGM4ZvtlFWdOTOjLc6vSMId9hn69OU5hI//Jdlrg2uC8pntVuIP3 qMPKXD54YRlIKNPvyDYaxOr9LbrCRzjA7Ixoobo5i35gnqp/506vX1Lc5dP3/XBR b3jfNzy+XgnDAhNqaCwOCrzEhP4JbbmQsSF5/MiwAFkFmyMFR7hyjO9ElkFY2hOW n3Tmzc5gXdR8mm7nFO9d3OrvmW5/xHGcnr8Y24d5aX3/QLMtl1koMw++rlgtBFKn fiqKgwytD3K3JoHK4WsStDCWOsS3ug== =dFiB -----END PGP SIGNATURE----- --Izn7cH1Com+I3R9J-- 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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 28876C2B9F4 for ; Fri, 25 Jun 2021 15:53:15 +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 DE9E461952 for ; Fri, 25 Jun 2021 15:53:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE9E461952 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=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=C4hMsFhmUN+0DV2rVwehjbLRDzuqXiKwfx+Uub+w8q0=; b=YRnP4frDIsmDT9mbFWwy5O49N5 lpUu/Kt8TXPJRwd7IBTwYpAtwwPAVHsMIRToWbOs07TIkLPEy6wS0dT4vP8T3iXPkUlTYqwus2vuI pe5qQcZi931f+3xsPkotdGEwpBcuQL3Ig08OQcAhFNskHSDaKwE2fj2uwYjL0qf8G1gMnaHlRBkuX nJXshT0g97juzKGlMFoWFZX/2cVVTQblHcO735u06pahK2h63APjlKL83QDpA1DdFKVYnhFxkXg94 0seMbqKOwURRy30JTvAMUXgtw73qePNXKRks2iZM1KfrUBKVD3dOxCc9u0ywYBuuKhVI9s7tVAqvD fy4H7hag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwo7Y-002DDd-O9; Fri, 25 Jun 2021 15:51:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwo7U-002DCY-Pp for linux-arm-kernel@lists.infradead.org; Fri, 25 Jun 2021 15:51:54 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E28C56195D; Fri, 25 Jun 2021 15:51:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624636312; bh=Q6AwIy7XeT7mjSj18u1iyC3ch7ZFJBonoUlzckIGJz0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pPYAhl3YvsV9Mx6354i5NxPxvzH84VwzuxVv6pFzswdd4gal4OHM9RH6y8ra0PUMb dyx7Jy+fparTreYxynyFKh+dXu3NkK71FXlJ7cxU22kb7SiVJjinngh1OVXY+a1Dhu Xtjmm1KEUUdLSHpivR3oxXlhK+EkVXsRIY/CBlVuxQ1a6O8290ZsLyKUqnrypn3XrY R+QIHzZvs3BSAS+2u712PXr6jdHCfnYnZTXhO8SxKl5cdRa6XvS6UOA0AlW+3x23Q0 eLgen7qddzwPa3nSVhaOA0nYl5pKZfZ4eew9dLHWCcRtV0q5SlLQ3H266GX8YC+yz3 jcL7OCDZ0FfdQ== Date: Fri, 25 Jun 2021 16:51:27 +0100 From: Mark Brown To: "Madhavan T. Venkataraman" Cc: Mark Rutland , jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.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 v5 1/2] arm64: Introduce stack trace reliability checks in the unwinder Message-ID: <20210625155127.GC4492@sirena.org.uk> References: <20210526214917.20099-1-madvenka@linux.microsoft.com> <20210526214917.20099-2-madvenka@linux.microsoft.com> <20210624144021.GA17937@C02TD0UTHF1T.local> MIME-Version: 1.0 In-Reply-To: X-Cookie: HELLO, everybody, I'm a HUMAN!! 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-20210625_085152_911076_405C21DB X-CRM114-Status: GOOD ( 23.51 ) 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="===============4554315603715688360==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4554315603715688360== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Izn7cH1Com+I3R9J" Content-Disposition: inline --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 25, 2021 at 10:39:57AM -0500, Madhavan T. Venkataraman wrote: > On 6/24/21 9:40 AM, Mark Rutland wrote: > > At a high-level, I'm on-board with keeping track of this per unwind > > step, but if we do that then I want to be abel to use this during > > regular unwinds (e.g. so that we can have a backtrace idicate when a > > step is not reliable, like x86 does with '?'), and to do that we need to > > be a little more accurate. > The only consumer of frame->reliable is livepatch. So, in retrospect, my > original per-frame reliability flag was an overkill. I was just trying to > provide extra per-frame debug information which is not really a requirement > for livepatch. It's not a requirement for livepatch but if it's there a per frame reliability flag would have other uses - for example Mark has mentioned the way x86 prints a ? next to unreliable entries in oops output for example, that'd be handy for people debugging issues and would have the added bonus of ensuring that there's more constant and widespread exercising of the reliability stuff than if it's just used for livepatch which is a bit niche. > So, let us separate the two. I will rename frame->reliable to frame->livepatch_safe. > This will apply to the whole stacktrace and not to every frame. I'd rather keep it as reliable, even with only the livepatch usage I think it's clearer. > Finally, it might be a good idea to perform reliability checks even in > start_backtrace() so we don't assume that the starting frame is reliable even > if the caller passes livepatch_safe=true. What do you think? That makes sense to me. --Izn7cH1Com+I3R9J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmDV+34ACgkQJNaLcl1U h9Ch+wf7BDR5lejSlhWSQ/gqNm01WBJhVAeZE6s4y9+c0vbutI3yLY2OcMHxA4n7 AqJifvW72eAeiGM4ZvtlFWdOTOjLc6vSMId9hn69OU5hI//Jdlrg2uC8pntVuIP3 qMPKXD54YRlIKNPvyDYaxOr9LbrCRzjA7Ixoobo5i35gnqp/506vX1Lc5dP3/XBR b3jfNzy+XgnDAhNqaCwOCrzEhP4JbbmQsSF5/MiwAFkFmyMFR7hyjO9ElkFY2hOW n3Tmzc5gXdR8mm7nFO9d3OrvmW5/xHGcnr8Y24d5aX3/QLMtl1koMw++rlgtBFKn fiqKgwytD3K3JoHK4WsStDCWOsS3ug== =dFiB -----END PGP SIGNATURE----- --Izn7cH1Com+I3R9J-- --===============4554315603715688360== 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 --===============4554315603715688360==--