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, HEADER_FROM_DIFFERENT_DOMAINS,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 B948FC433DB for ; Thu, 14 Jan 2021 11:55:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 72A0823A53 for ; Thu, 14 Jan 2021 11:55:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727848AbhANLzK (ORCPT ); Thu, 14 Jan 2021 06:55:10 -0500 Received: from foss.arm.com ([217.140.110.172]:48674 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726259AbhANLzJ (ORCPT ); Thu, 14 Jan 2021 06:55:09 -0500 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 F3E9EED1; Thu, 14 Jan 2021 03:54:23 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.42.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 946EA3F719; Thu, 14 Jan 2021 03:54:21 -0800 (PST) Date: Thu, 14 Jan 2021 11:54:18 +0000 From: Mark Rutland To: Josh Poimboeuf Cc: Mark Brown , linux-kernel@vger.kernel.org, Jiri Kosina , Joe Lawrence , Jonathan Corbet , Miroslav Benes , Petr Mladek , linux-doc@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH] Documentation: livepatch: document reliable stacktrace Message-ID: <20210114115418.GB2739@C02TD0UTHF1T.local> References: <20210113165743.3385-1-broonie@kernel.org> <20210113192735.rg2fxwlfrzueinci@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210113192735.rg2fxwlfrzueinci@treble> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote: > On Wed, Jan 13, 2021 at 04:57:43PM +0000, Mark Brown wrote: > > From: Mark Rutland > > +There are several ways an architecture may identify kernel code which is deemed > > +unreliable to unwind from, e.g. > > + > > +* Using metadata created by objtool, with such code annotated with > > + SYM_CODE_{START,END} or STACKFRAME_NON_STANDARD(). > > I'm not sure why SYM_CODE_{START,END} is mentioned here, but it doesn't > necessarily mean the code is unreliable, and objtool doesn't treat it as > such. Its mention can probably be removed unless there was some other > point I'm missing. > > Also, s/STACKFRAME/STACK_FRAME/ When I wrote this, I was under the impression that (for x86) code marked as SYM_CODE_{START,END} wouldn't be considered as a function by objtool. Specifically SYM_FUNC_END() marks the function with SYM_T_FUNC whereas SYM_CODE_END() marks it with SYM_T_NONE, and IIRC I thought that objtool only generated ORC for SYM_T_FUNC functions, and hence anything else would be considered not unwindable due to the absence of ORC. Just to check, is that understanding for x86 correct, or did I get that wrong? If that's right, it might be worth splitting this into two points, e.g. | * Using metadata created by objtool, with such code annotated with | STACKFRAME_NON_STANDARD(). | | | * Using ELF symbol attributes, with such code annotated with | SYM_CODE_{START,END}, and not having a function type. If that's wrong, I suspect there are latent issues here? Thanks, Mark.