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=-19.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 D0711C433ED for ; Tue, 4 May 2021 23:13:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B09B66100C for ; Tue, 4 May 2021 23:13:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231160AbhEDXOh (ORCPT ); Tue, 4 May 2021 19:14:37 -0400 Received: from linux.microsoft.com ([13.77.154.182]:60436 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229960AbhEDXOg (ORCPT ); Tue, 4 May 2021 19:14:36 -0400 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id 596C820B7178; Tue, 4 May 2021 16:13:40 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 596C820B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1620170021; bh=iPiRNYpjRwzimrh0K0tYcnGX1TG+68HNv8cU+qTFNlE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MHuTR0PCggMxKIWmmSaj3Dkz01I4Csml3R14Taa2MwE5x0SRFnY4FdtVQb7ULnW2d m+1Q7clUEvTyxL4XXv1SEZ8Qf2Ok2fgI8qBqjfxB4qeKGLDgL2gZAS+xz8O5bVjv+i /IknZDpVFHJpXgCGE0Z/5oFwcmKkm74n9etbKHJY= Subject: Re: [RFC PATCH v3 1/4] arm64: Introduce stack trace reliability checks in the unwinder To: Josh Poimboeuf Cc: broonie@kernel.org, mark.rutland@arm.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <65cf4dfbc439b010b50a0c46ec500432acde86d6> <20210503173615.21576-1-madvenka@linux.microsoft.com> <20210503173615.21576-2-madvenka@linux.microsoft.com> <20210504215248.oi3zay3memgqri33@treble> From: "Madhavan T. Venkataraman" Message-ID: Date: Tue, 4 May 2021 18:13:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210504215248.oi3zay3memgqri33@treble> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/4/21 4:52 PM, Josh Poimboeuf wrote: > On Mon, May 03, 2021 at 12:36:12PM -0500, madvenka@linux.microsoft.com wrote: >> @@ -44,6 +44,8 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame) >> unsigned long fp = frame->fp; >> struct stack_info info; >> >> + frame->reliable = true; >> + > > Why set 'reliable' to true on every invocation of unwind_frame()? > Shouldn't it be remembered across frames? > This is mainly for debug purposes in case a caller wants to print the whole stack and also print which functions are unreliable. For livepatch, it does not make any difference. It will quit as soon as it encounters an unreliable frame. > Also, it looks like there are several error scenarios where it returns > -EINVAL but doesn't set 'reliable' to false. > I wanted to make a distinction between an error situation (like stack corruption where unwinding has to stop) and an unreliable situation (where unwinding can still proceed). E.g., when a stack trace is taken for informational purposes or debug purposes, the unwinding will try to proceed until either the stack trace ends or an error happens. Madhavan 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=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 5D018C433ED for ; Tue, 4 May 2021 23:16:00 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 1F0DD61182 for ; Tue, 4 May 2021 23:16:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F0DD61182 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=04OgTm+02aijh0vhYkYXXP7wFPlcPSrZqLYW5PKeO18=; b=bgQL4i72jA86FomeBAEWv9N4E A1iZIri8lSyzWpkvFFd2Cbhy5srIEJCUo3n2s1l56EkFVeenkQ2lz2yWanbDp5xTC3BgL5R183Q2N XOmyPWKxDTq9aMKy5tR6FMPtCTQfgDZdi210gISCY7ymmOJDmCpZPlM5bWxFFcVIyzwMsb1/Helq8 ZYorAQskTF1YmTg4Lc+eOJ222oIizFMI3Tr2OhYu0ZvgEfJBit+EnWi98KEL18AEwJntRCL+ES89W /ZaqBzMB2cAG8pHsgB0W+0KXhfrP1e6FDybZHoRlvMRbldnswLeK1yxUgemFZD5PfaKFv140pMhco jLplcezrg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1le4F3-00HLFw-8x; Tue, 04 May 2021 23:14:13 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1le4Ec-00HLCm-4D for linux-arm-kernel@desiato.infradead.org; Tue, 04 May 2021 23:13:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=iPiRNYpjRwzimrh0K0tYcnGX1TG+68HNv8cU+qTFNlE=; b=htAKxpl6kEu1LD8bUxQS06EAhV EPdwfVgaDXzivwOeG3G1CLeZk40kAQTquBR7vxCttZUTiYzQPn8pzNlykU6lh/IbDMQOjO3aIoCLw 1nDxCRp13o+hvOg/6Y3Xhew9N6tc5e3CAMq2MG0j10yvC/Wm7F282S2ZJGwCJtrDZLHRuLB82e3ZF RtiyGCkjWaJ6Lc0ChIxl/Q/oQmi9Iw11Ig/bmdV36CDd9HUn2DPRdOFzcyND03cOTmgNd8KBelguP T5f/q5iqnQvy85RVv2SOZqfPBpT4VvQBdHKe4NGvSkIiVd3/8I2KnlBnXkd63QbihzzjFjpaqDDP1 Il0bb8ZQ==; Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1le4EZ-004KJT-NM for linux-arm-kernel@lists.infradead.org; Tue, 04 May 2021 23:13:44 +0000 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id 596C820B7178; Tue, 4 May 2021 16:13:40 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 596C820B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1620170021; bh=iPiRNYpjRwzimrh0K0tYcnGX1TG+68HNv8cU+qTFNlE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MHuTR0PCggMxKIWmmSaj3Dkz01I4Csml3R14Taa2MwE5x0SRFnY4FdtVQb7ULnW2d m+1Q7clUEvTyxL4XXv1SEZ8Qf2Ok2fgI8qBqjfxB4qeKGLDgL2gZAS+xz8O5bVjv+i /IknZDpVFHJpXgCGE0Z/5oFwcmKkm74n9etbKHJY= Subject: Re: [RFC PATCH v3 1/4] arm64: Introduce stack trace reliability checks in the unwinder To: Josh Poimboeuf Cc: broonie@kernel.org, mark.rutland@arm.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, pasha.tatashin@soleen.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <65cf4dfbc439b010b50a0c46ec500432acde86d6> <20210503173615.21576-1-madvenka@linux.microsoft.com> <20210503173615.21576-2-madvenka@linux.microsoft.com> <20210504215248.oi3zay3memgqri33@treble> From: "Madhavan T. Venkataraman" Message-ID: Date: Tue, 4 May 2021 18:13:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210504215248.oi3zay3memgqri33@treble> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210504_161343_815876_10F0DE13 X-CRM114-Status: GOOD ( 14.18 ) 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: 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 5/4/21 4:52 PM, Josh Poimboeuf wrote: > On Mon, May 03, 2021 at 12:36:12PM -0500, madvenka@linux.microsoft.com wrote: >> @@ -44,6 +44,8 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame) >> unsigned long fp = frame->fp; >> struct stack_info info; >> >> + frame->reliable = true; >> + > > Why set 'reliable' to true on every invocation of unwind_frame()? > Shouldn't it be remembered across frames? > This is mainly for debug purposes in case a caller wants to print the whole stack and also print which functions are unreliable. For livepatch, it does not make any difference. It will quit as soon as it encounters an unreliable frame. > Also, it looks like there are several error scenarios where it returns > -EINVAL but doesn't set 'reliable' to false. > I wanted to make a distinction between an error situation (like stack corruption where unwinding has to stop) and an unreliable situation (where unwinding can still proceed). E.g., when a stack trace is taken for informational purposes or debug purposes, the unwinding will try to proceed until either the stack trace ends or an error happens. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel