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,URIBL_BLOCKED, 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 7ACC5C433B4 for ; Mon, 19 Apr 2021 18:17:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 446D561354 for ; Mon, 19 Apr 2021 18:17:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240178AbhDSSRa (ORCPT ); Mon, 19 Apr 2021 14:17:30 -0400 Received: from linux.microsoft.com ([13.77.154.182]:41012 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233907AbhDSSR2 (ORCPT ); Mon, 19 Apr 2021 14:17:28 -0400 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id DB03320B8000; Mon, 19 Apr 2021 11:16:57 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com DB03320B8000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1618856218; bh=cRJmWH03/XKOttU3OaDRbl+mvZMfWqX2u8y+9sokYqs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ptdT+5pNQXQ5X8C8cgYoQOv4klVxRcD3Vo9K86GurDgWobBYYu5HCKvkR5h4g6ECi MoJiH1y5lWTQBYt+RuYLvfM2P5ZT2AzsEwrpBexZENPxXNUQUHsB8Ndv0IWDQRiM1D JBTLKWH8dlsTq6NAD8WBjSWbnxp/pfzO6rf4Ifp0= Subject: Re: [RFC PATCH v2 0/1] arm64: Implement stack trace termination record To: mark.rutland@arm.com, broonie@kernel.org, jpoimboe@redhat.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741> <20210402032404.47239-1-madvenka@linux.microsoft.com> Cc: pasha.tatashin@soleen.com From: "Madhavan T. Venkataraman" Message-ID: <96b4deb8-c841-b0fd-f1f9-ad0b737ec8a7@linux.microsoft.com> Date: Mon, 19 Apr 2021 13:16:57 -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: <20210402032404.47239-1-madvenka@linux.microsoft.com> 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 CCing Pavel Tatashin on request. Pasha, This is v2. v1 is here: https://lore.kernel.org/linux-arm-kernel/20210324184607.120948-1-madvenka@linux.microsoft.com/ Thanks! Madhavan On 4/1/21 10:24 PM, madvenka@linux.microsoft.com wrote: > From: "Madhavan T. Venkataraman" > > Reliable stacktracing requires that we identify when a stacktrace is > terminated early. We can do this by ensuring all tasks have a final > frame record at a known location on their task stack, and checking > that this is the final frame record in the chain. > > All tasks have a pt_regs structure right after the task stack in the stack > page. The pt_regs structure contains a stackframe field. Make this stackframe > field the final frame in the task stack so all stack traces end at a fixed > stack offset. > > For kernel tasks, this is simple to understand. For user tasks, there is > some extra detail. User tasks get created via fork() et al. Once they return > from fork, they enter the kernel only on an EL0 exception. In arm64, > system calls are also EL0 exceptions. > > The EL0 exception handler uses the task pt_regs mentioned above to save > register state and call different exception functions. All stack traces > from EL0 exception code must end at the pt_regs. So, make pt_regs->stackframe > the final frame in the EL0 exception stack. > > To summarize, task_pt_regs(task)->stackframe will always be the final frame > in a stack trace. > > Sample stack traces > =================== > > The final frame for the idle tasks is different from v1. The rest of the > stack traces are the same. > > Primary CPU's idle task (changed from v1) > ======================= > > [ 0.022365] arch_stack_walk+0x0/0xd0 > [ 0.022376] callfd_stack+0x30/0x60 > [ 0.022387] rest_init+0xd8/0xf8 > [ 0.022397] arch_call_rest_init+0x18/0x24 > [ 0.022411] start_kernel+0x5b8/0x5f4 > [ 0.022424] __primary_switched+0xa8/0xac > > Secondary CPU's idle task (changed from v1) > ========================= > > [ 0.022484] arch_stack_walk+0x0/0xd0 > [ 0.022494] callfd_stack+0x30/0x60 > [ 0.022502] secondary_start_kernel+0x188/0x1e0 > [ 0.022513] __secondary_switched+0x80/0x84 > > --- > Changelog: > > v1 > - Set up task_pt_regs(current)->stackframe as the final frame > when a new task is initialized in copy_thread(). > > - Create pt_regs for the idle tasks and set up pt_regs->stackframe > as the final frame for the idle tasks. > > - Set up task_pt_regs(current)->stackframe as the final frame in > the EL0 exception handler so the EL0 exception stack trace ends > there. > > - Terminate the stack trace successfully in unwind_frame() when > the FP reaches task_pt_regs(current)->stackframe. > > - The stack traces (above) in the kernel will terminate at the > correct place. Debuggers may show an extra record 0x0 at the end > for pt_regs->stackframe. That said, I did not see that extra frame > when I did stack traces using gdb. > v2 > - Changed some wordings as suggested by Mark Rutland. > > - Removed the synthetic return PC for idle tasks. Changed the > branches to start_kernel() and secondary_start_kernel() to > calls so that they will have a proper return PC. > > Madhavan T. Venkataraman (1): > arm64: Implement stack trace termination record > > arch/arm64/kernel/entry.S | 8 +++++--- > arch/arm64/kernel/head.S | 29 +++++++++++++++++++++++------ > arch/arm64/kernel/process.c | 5 +++++ > arch/arm64/kernel/stacktrace.c | 10 +++++----- > 4 files changed, 38 insertions(+), 14 deletions(-) > > > base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b > 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.3 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,URIBL_BLOCKED, USER_AGENT_SANE_1 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 4E62EC433B4 for ; Mon, 19 Apr 2021 18:19:41 +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 BBF74611EE for ; Mon, 19 Apr 2021 18:19:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBF74611EE 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:Cc: 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=lHmNMRUHuMsaeAHunnN+k8UFSIKiJY+2a33U/L5T2H0=; b=U2W5UKtrKqtxmw7UJSBceZjnp fJeNgB4X7qyQey4KpNail8z4Te09IiKuPxCpupSaMWKBjmsDqVxXFwsC1FFgv74RfcjTqNI31qv+l MDh/6nRhTs6Lf27WDefyD1QJERCuP44oJccTv9kbhHTsVh3925Pl24qXjxoIln2+JN057SciDwwua WXLkcP0cPDz198Xrrxgqwl1A8aRWWYqOofyInjf76zHPDWaWd5F+BEBkmo3c0pkt51IT2aOmM1HZs sIjRdJkt4CgFTevK/ADSIqUqGefMcO5e2wG6NxONLYyFnRhx7lYss/sexMxwlI7S0LcQ2ib0K4gDW g33CmioJw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYYSN-00APbG-JN; Mon, 19 Apr 2021 18:17:11 +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 1lYYSK-00APb0-TS for linux-arm-kernel@desiato.infradead.org; Mon, 19 Apr 2021 18:17:09 +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:Cc:References:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=cRJmWH03/XKOttU3OaDRbl+mvZMfWqX2u8y+9sokYqs=; b=gTSjGarOwOEuYjcDrNGuTqCnU6 hfSSX7u0DqucD04YfnuynIfw5GBTvXTl0WNgJDAOk3rW4TID1CvT9ruL5uwvLG4B9hepvP6gyWxdE ewvHu8Tq9iMfc7pjnmtAg+UYX9Prrcu3HJzN0zybp8RqSaxO9VsEQZFFwmfOdyeVQugngO2XPin+J t8L0bm4dGrMi3Jq3rpPdn6px7PDvy6zp+4tGTmZ/rfsLV0DaUQvw5MEdAFfqYRDN8F+16BUAe8S0n zG4hS0wD1X0ataN8Xr1k75TxrmwTm3ELCnGRRCbD4laiR5jxy/zgihADjqSrgWVjXgukSIt0x2d6j lh7k30kg==; Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYYSF-00BaG0-7U for linux-arm-kernel@lists.infradead.org; Mon, 19 Apr 2021 18:17:07 +0000 Received: from [192.168.254.32] (unknown [47.187.223.33]) by linux.microsoft.com (Postfix) with ESMTPSA id DB03320B8000; Mon, 19 Apr 2021 11:16:57 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com DB03320B8000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1618856218; bh=cRJmWH03/XKOttU3OaDRbl+mvZMfWqX2u8y+9sokYqs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ptdT+5pNQXQ5X8C8cgYoQOv4klVxRcD3Vo9K86GurDgWobBYYu5HCKvkR5h4g6ECi MoJiH1y5lWTQBYt+RuYLvfM2P5ZT2AzsEwrpBexZENPxXNUQUHsB8Ndv0IWDQRiM1D JBTLKWH8dlsTq6NAD8WBjSWbnxp/pfzO6rf4Ifp0= Subject: Re: [RFC PATCH v2 0/1] arm64: Implement stack trace termination record To: mark.rutland@arm.com, broonie@kernel.org, jpoimboe@redhat.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741> <20210402032404.47239-1-madvenka@linux.microsoft.com> Cc: pasha.tatashin@soleen.com From: "Madhavan T. Venkataraman" Message-ID: <96b4deb8-c841-b0fd-f1f9-ad0b737ec8a7@linux.microsoft.com> Date: Mon, 19 Apr 2021 13:16:57 -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: <20210402032404.47239-1-madvenka@linux.microsoft.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_111703_353500_2ED5863F X-CRM114-Status: GOOD ( 22.79 ) 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 CCing Pavel Tatashin on request. Pasha, This is v2. v1 is here: https://lore.kernel.org/linux-arm-kernel/20210324184607.120948-1-madvenka@linux.microsoft.com/ Thanks! Madhavan On 4/1/21 10:24 PM, madvenka@linux.microsoft.com wrote: > From: "Madhavan T. Venkataraman" > > Reliable stacktracing requires that we identify when a stacktrace is > terminated early. We can do this by ensuring all tasks have a final > frame record at a known location on their task stack, and checking > that this is the final frame record in the chain. > > All tasks have a pt_regs structure right after the task stack in the stack > page. The pt_regs structure contains a stackframe field. Make this stackframe > field the final frame in the task stack so all stack traces end at a fixed > stack offset. > > For kernel tasks, this is simple to understand. For user tasks, there is > some extra detail. User tasks get created via fork() et al. Once they return > from fork, they enter the kernel only on an EL0 exception. In arm64, > system calls are also EL0 exceptions. > > The EL0 exception handler uses the task pt_regs mentioned above to save > register state and call different exception functions. All stack traces > from EL0 exception code must end at the pt_regs. So, make pt_regs->stackframe > the final frame in the EL0 exception stack. > > To summarize, task_pt_regs(task)->stackframe will always be the final frame > in a stack trace. > > Sample stack traces > =================== > > The final frame for the idle tasks is different from v1. The rest of the > stack traces are the same. > > Primary CPU's idle task (changed from v1) > ======================= > > [ 0.022365] arch_stack_walk+0x0/0xd0 > [ 0.022376] callfd_stack+0x30/0x60 > [ 0.022387] rest_init+0xd8/0xf8 > [ 0.022397] arch_call_rest_init+0x18/0x24 > [ 0.022411] start_kernel+0x5b8/0x5f4 > [ 0.022424] __primary_switched+0xa8/0xac > > Secondary CPU's idle task (changed from v1) > ========================= > > [ 0.022484] arch_stack_walk+0x0/0xd0 > [ 0.022494] callfd_stack+0x30/0x60 > [ 0.022502] secondary_start_kernel+0x188/0x1e0 > [ 0.022513] __secondary_switched+0x80/0x84 > > --- > Changelog: > > v1 > - Set up task_pt_regs(current)->stackframe as the final frame > when a new task is initialized in copy_thread(). > > - Create pt_regs for the idle tasks and set up pt_regs->stackframe > as the final frame for the idle tasks. > > - Set up task_pt_regs(current)->stackframe as the final frame in > the EL0 exception handler so the EL0 exception stack trace ends > there. > > - Terminate the stack trace successfully in unwind_frame() when > the FP reaches task_pt_regs(current)->stackframe. > > - The stack traces (above) in the kernel will terminate at the > correct place. Debuggers may show an extra record 0x0 at the end > for pt_regs->stackframe. That said, I did not see that extra frame > when I did stack traces using gdb. > v2 > - Changed some wordings as suggested by Mark Rutland. > > - Removed the synthetic return PC for idle tasks. Changed the > branches to start_kernel() and secondary_start_kernel() to > calls so that they will have a proper return PC. > > Madhavan T. Venkataraman (1): > arm64: Implement stack trace termination record > > arch/arm64/kernel/entry.S | 8 +++++--- > arch/arm64/kernel/head.S | 29 +++++++++++++++++++++++------ > arch/arm64/kernel/process.c | 5 +++++ > arch/arm64/kernel/stacktrace.c | 10 +++++----- > 4 files changed, 38 insertions(+), 14 deletions(-) > > > base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel