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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 91B5FC433E0 for ; Sat, 30 Jan 2021 04:39:57 +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 499B060233 for ; Sat, 30 Jan 2021 04:39:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 499B060233 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VpupqPpZdD1VMhQkltDtL/e2M++R379qybGoSRXa3zY=; b=vVu7Mm4R2pMO0o4cew6s/oDZx P/c0XFA/1uI/GUeUArAMQIJ7+donJDwWOWsbsM1aW3i31L54BceuR0vVdUQu63E8kie4C1JSHrAM3 GXN3adcm0LQhmsVpnR1eTqeizTrVwaBhQO3X66y68knb+4nesWTOSAqDm+bddAGBV7Kgtek6ITL/p P2NU0gg+r9K7Ei3p52ZrRLjc/Pgh7B8ZpMkD/s5CH6QIgw3Dq8v8nL18kQ6FpqihQoX/ajkRewim8 c3idb4lKzw8ICt8hQqMDhkfBM6OceKBq8Aq0vH2KVKXq1nZy6N4Bwg22nPFf+C0nHjsY2qSWUQzdl nCDXLHNmg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5i1U-00050a-I6; Sat, 30 Jan 2021 04:38:12 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5i1P-000509-Hd for linux-arm-kernel@lists.infradead.org; Sat, 30 Jan 2021 04:38:11 +0000 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id ED3D220B7192; Fri, 29 Jan 2021 20:38:03 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com ED3D220B7192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1611981484; bh=MT+DJul6jvuugJd+G+EsC79B43AypjsHU1Wox24lPW8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=j51CLdVsOC3Ajq2encRJ/9sywjjbpASrhCVNkAm0+dlFP2mUq1oji0i5mBehvZmB9 6W9zFQ06bNguFrht1UzpsPT9EAahX0oxRiVQruuf2+sRkmEQbWRSB1vKcQFPPLMm2I 0y0aOlNzdNLXSyTJIhNOAtTXYx3mgzoFANYHRW+4= Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace To: Josh Poimboeuf , Mark Brown References: <20201012172605.10715-1-broonie@kernel.org> <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> <20210128142250.GC4537@sirena.org.uk> <20210128152649.6zin3hzim3etbv2p@treble> From: "Madhavan T. Venkataraman" Message-ID: <4ea185a4-bd0b-e065-480a-e8319f924c59@linux.microsoft.com> Date: Fri, 29 Jan 2021 22:38:03 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210128152649.6zin3hzim3etbv2p@treble> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210129_233807_777505_49C7BA51 X-CRM114-Status: GOOD ( 20.60 ) 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: Mark Rutland , Julien Thierry , Catalin Marinas , Miroslav Benes , Will Deacon , 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 1/28/21 9:26 AM, Josh Poimboeuf wrote: > > >> >>> Then, the unwinder can check the functions it encounters in the stack trace and >>> inform the caller if it found any no-FP functions. The caller of the unwinder can >>> decide what he wants to do with that information. >>> >>> - the caller can ignore it >>> >>> - the caller can print the stack trace with a warning that no-FP functions >>> were found >>> >>> - if the caller is livepatch, the caller can retry until the no-FP functions >>> disappear from the stack trace. This way, we can have live patching even >>> when some of the functions in the kernel are no-FP. >>> >>> Does this make any sense? Is this acceptable? What are the pitfalls? > > Why not just fix the reported no-FP functions? I was not sure if all warnings can be fixed. For instance, some performance critical functions may not want the extra overhead of the prolog and epilog. Also, as you mentioned elsewhere, assembly code is often spaghetti code with multiple labels and functions sharing code, etc. I am not sure that these can easily be fixed. To prevent objtool from rejecting these, we have to find some way for objtool to ignore them so it does not generate any warnings. Is this not correct? For x86, did guys manage to fix every single warning? I am not familiar with the history of this. So, I am just assuming. > >>> If we can do this, the unwinder could detect cases such as: >> >>> - If gcc thinks that a function is a leaf function but the function contains >>> inline assembly code that calls another function. >> >>> - If a call to a function bounces through some intermediate code such as a >>> trampoline. >> >>> - etc. >> >>> For specific no-FP functions, the unwinder might be able to deduce the original >>> caller. In these cases, the stack trace would still be reliable. For all the others, >>> the stack trace would be considered unreliable. >> >> I'm not entirely sure I see the distinction from the current situation >> here? >> Sorry. I should have been clear. If there are no-FP functions that cannot really be fixed to objtool's satisfaction and objtool is made to ignore them, they may still show up on the stack and hide their callers. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel