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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 84EBDC433F5 for ; Fri, 26 Nov 2021 17:25:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=j7xugR8+G3/0DarqjP3reUfBz/UwdqXTOaOyv+ErSno=; b=01e4j5rqLpBTafrSi6dIHLGqrs +OOT0723jzImTVzxddBgaSQuxHLOvfcI41EPnfVcxaudPNiW2sgnqdt97MYmuulHweTuD8FttZLxG 1o4hZcNzYulQBlm13kVNmXeKtQoAhDJ7OluevLe8F78OsfqOlCMDBURQ+0bMbcg2F/5bFMcby9Q9W g/Xf2dlmmkyyagetdBFnQYXaca7z4qlREXI7UNxdyaZRITEjoqh9FIhSXhnAQKF0dL3R5J/A4AxQ8 sO1x0+WSfN1cEwCmvTE3VyULP1PCNQukgeqZxiMJ7oJdU130ukaOE5W0a9w4cWxIETsJliXjWzV43 rj//QbJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mqex5-00BIkv-9j; Fri, 26 Nov 2021 17:23:59 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mqewz-00BIj5-90 for linux-arm-kernel@lists.infradead.org; Fri, 26 Nov 2021 17:23:57 +0000 Received: from [192.168.254.32] (unknown [47.187.212.181]) by linux.microsoft.com (Postfix) with ESMTPSA id 38CFF20DDB25; Fri, 26 Nov 2021 09:23:48 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 38CFF20DDB25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1637947428; bh=Bx3d3zMNN9opMfI8ccUCld6l8vmlXB9FpQqjEIZCNGQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YMzn+Y2fMDQGBTbGr8MpBVnYtUAEgudxg+aBvzJajQ74b9fCe/vLrFHE6C7W0QeKe h8xsykLKf2MS5s4hjuFDBD6WO5Rcai1StFRl0Hxhu1PwTATGmER4146uFqKBSpz3y7 FtRji+hNiiyO0WRvCLWv03U5oDbLjl1xiFUFPP+Q= Subject: Re: [PATCH v11 4/5] arm64: Introduce stack trace reliability checks in the unwinder To: Mark Brown Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <8b861784d85a21a9bf08598938c11aff1b1249b9> <20211123193723.12112-1-madvenka@linux.microsoft.com> <20211123193723.12112-5-madvenka@linux.microsoft.com> <704d73f6-30e2-08e0-3a5c-d3639d8b2da1@linux.microsoft.com> From: "Madhavan T. Venkataraman" Message-ID: <1529ea6e-f4dd-b821-a2aa-0d6ff46cd691@linux.microsoft.com> Date: Fri, 26 Nov 2021 11:23:47 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211126_092353_525013_BF3F6E3F X-CRM114-Status: GOOD ( 34.14 ) 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 11/26/21 7:29 AM, Mark Brown wrote: > On Thu, Nov 25, 2021 at 10:59:27AM -0600, Madhavan T. Venkataraman wrote: >> On 11/25/21 8:56 AM, Mark Brown wrote: >>> On Tue, Nov 23, 2021 at 01:37:22PM -0600, madvenka@linux.microsoft.com wrote: > >>> Probably also worth noting that this doesn't select >>> HAVE_RELIABLE_STACKTRACE which is what any actual users are going to use >>> to identify if the architecture has the feature. I would have been >>> tempted to add arch_stack_walk() as a separate patch but equally having >>> the user code there (even if it itself can't yet be used...) helps with >>> reviewing the actual unwinder so I don't mind. > >> I did not select HAVE_RELIABLE_STACKTRACE just in case we think that some >> more reliability checks need to be added. But if reviewers agree >> that this patch series contains all the reliability checks we need, I >> will add a patch to select HAVE_RELIABLE_STACKTRACE to the series. > > I agree that more checks probably need to be added, might be worth > throwing that patch into the end of the series though to provide a place > to discuss what exactly we need. My main thought here was that it's > worth explicitly highlighting in this change that the Kconfig bit isn't > glued up here so reviewers notice that's what's happening. > OK. I will add the patch to the next version. >>>> +static void unwind_check_reliability(struct task_struct *task, >>>> + struct stackframe *frame) >>>> +{ >>>> + if (frame->fp == (unsigned long)task_pt_regs(task)->stackframe) { >>>> + /* Final frame; no more unwind, no need to check reliability */ >>>> + return; >>>> + } > >>> If the unwinder carries on for some reason (the code for that is >>> elsewhere and may be updated separately...) then this will start >>> checking again. I'm not sure if this is a *problem* as such but the >>> thing about this being the final frame coupled with not actually >>> explicitly stopping the unwind here makes me think this should at least >>> be clearer, the comment begs the question about what happens if >>> something decides it is not in fact the final frame. > >> I can address this by adding an explicit comment to that effect. >> For example, define a separate function to check for the final frame: > >> /* >> * Check if this is the final frame. Unwind must stop at the final >> * frame. >> */ >> static inline bool unwind_is_final_frame(struct task_struct *task, >> struct stackframe *frame) >> { >> return frame->fp == (unsigned long)task_pt_regs(task)->stackframe; >> } > >> Then, use this function in unwind_check_reliability() and unwind_continue(). > >> Is this acceptable? > > Yes, I think that should address the issue - I'd have to see it in > context to be sure but it does make it clear that the same check is > being done which was the main thing. > OK. I will make the above changes in the next version. Thanks. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel