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 73414C433F5 for ; Wed, 2 Mar 2022 11:23:43 +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:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bVzcjFqr2bo5bkxud4pNsLNMzyoNt+FsXcOrbVyengs=; b=DztA4z9EdrqNBC /ZomGgEuEcZQTBcyEwiPVXJA9fyZkKZZ7VFJ+2VjfowkcRk3sHZK7mlIXHf2YD5psiv4B3xSZ0Ioe 2rfK//3liGdMEyap/NONq9UTsaQuKdgAyMMBgmHYT0vGFh2QBPf45DSlNz4MalCguAfVuW8cSQrbQ q1JuJi29aK7W1mIf2OyKo7/98shWMInqvy9wti4+KeG7R0TXkvYc828S76CUpwPPwAa4dpBOCxSVg Qj6tQ2oW9INjWa/E6MYl610+xg4IkNKKRalw8WagbbOe0afGafA/UuUP1hdtIRN/nGpXVi5m3UX2F UYhoBYf2Y++D9bsYIuwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPN3z-002Rg6-OH; Wed, 02 Mar 2022 11:22:35 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPN3w-002Rf0-PM for linux-arm-kernel@lists.infradead.org; Wed, 02 Mar 2022 11:22:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kf8zKjx1jpB6ExufZ+QyMPsC6cuJG3089w5+njs1G5A=; b=c0DkrTda2xpKvQodJagOfOc7VD zppk1RxeyrxfqxPf0iJ7eKwJA+LospYsjRd4+ztXiOUqoneCxHUTde1uzopU1eB+5rLv7lOVM0UMs 5jYG+L2Fs2NcOE3ezqsXzF8ZSVI2DxJg0ctPT24oKasn0WrIbtm9yBXNtJhsO+wf48tQv7yR25H1w A2E/e8g3cKImvO47diCQ2ggxChcYbFiEu+caxvSb4jHhPYhUgB0cijR4449MA9iJEmO2SsWjzvA65 PWdlg+T7sZ30+mfYOqrMpdi15sXunojfvBIpw2MZ5t83JJVKiI1ufAF3C4riJ9DOujMSGzgU/F9kt qUYrhaIg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:57594) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nPN3u-0002Kq-9x; Wed, 02 Mar 2022 11:22:30 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1nPN3t-00085p-8J; Wed, 02 Mar 2022 11:22:29 +0000 Date: Wed, 2 Mar 2022 11:22:29 +0000 From: "Russell King (Oracle)" To: Ard Biesheuvel Cc: Corentin Labbe , Linus Walleij , Arnd Bergmann , Linux ARM , Linux Kernel Mailing List Subject: Re: boot flooded with unwind: Index not found Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220302_032232_851056_B20966C3 X-CRM114-Status: GOOD ( 34.61 ) 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 Wed, Mar 02, 2022 at 12:19:40PM +0100, Ard Biesheuvel wrote: > On Wed, 2 Mar 2022 at 12:12, Russell King (Oracle) > wrote: > > > > On Wed, Mar 02, 2022 at 11:09:49AM +0100, Corentin Labbe wrote: > > > The crash disappeared (but the suspicious RCU usage is still here). > > > > As the trace on those is: > > > > [ 0.239629] unwind_backtrace from show_stack+0x10/0x14 > > [ 0.239654] show_stack from init_stack+0x1c54/0x2000 > > > > unwind_backtrace() and show_stack() are both C code, the compiler will > > emit the unwind information for it. show_stack() isn't called from > > assembly code, only from C code, so the next function's unwind > > information should also be generated by the compiler. > > > > However, init_stack is not a function - it's an array of unsigned long. > > There is no way this should appear in the trace, and this suggests that > > the unwind of show_stack() has gone wrong. > > > > I don't see anything obvious in Ard's changes that would cause that > > though. > > > > Did it used to work fine with previous versions of linux-next - those > > versions where we had Ard's "arm-vmap-stacks-v6" tag merged in > > (commit 2fa394824493) and did this only appear when I merged > > "arm-ftrace-for-rmk" (commit 74aaaa1e9bba) ? Did merging > > "arm-ftrace-for-rmk" cause any change in your .config? > > > > I can reproduce the RCU warnings, and I have tracked this down to the > change I made to return_address() for the graph tracer, which I > thought was justified after removing the call to > kernel_text_address(): > > --- a/arch/arm/include/asm/ftrace.h > +++ b/arch/arm/include/asm/ftrace.h > @@ -35,26 +35,8 @@ static inline unsigned long > ftrace_call_adjust(unsigned long addr) > > #ifndef __ASSEMBLY__ > > -#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) > -/* > - * return_address uses walk_stackframe to do it's work. If both > - * CONFIG_FRAME_POINTER=y and CONFIG_ARM_UNWIND=y walk_stackframe uses unwind > - * information. For this to work in the function tracer many functions would > - * have to be marked with __notrace. So for now just depend on > - * !CONFIG_ARM_UNWIND. > - */ > - > void *return_address(unsigned int); > > -#else > - > -static inline void *return_address(unsigned int level) > -{ > - return NULL; > -} > - > -#endif > - > #define ftrace_return_address(n) return_address(n) > > #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME > > However, the function graph tracer works happily with this bit > reverted, and so that is probably the best course of action here. > > I have already sent the patch that reintroduces the > kernel_text_address() check - would you prefer a v2 of that one with > this change incorporated? Or a second patch that just reverts the > above? (Given that the bogus dereference was invoked from > return_address() as well, I suspect that this change would make the > get_kernel_nofault() change I proposed in this thread redundant) I'd prefer patches on top of my devel-stable branch, thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel