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 B6EA7C433F5 for ; Wed, 2 Mar 2022 10:11:29 +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=va90zJocSpIAWDQ4DXmE66Bz15XYZVBltMFk+2QSpcg=; b=SD6U4EZBHoZ2r0 zZQY+wYiH6W2ZnyioZDe9SYSPO7j62xEAjbXy9tpjMIgH61xtLiXvYT+Xd1BGqQ5ifVjAROEENTDK 2pEf1f5TiERV6Qe7ShH5Y6ulUp5szkeml+ixSKp+F3ELTAvDFcjha9jj4Cm0n5QfA3j5+lxfQSXVT mMzq5o6MSjNDMw+6nZoqSoX+9BJZJwMrPGhoycIzjAQ4WuVfe4UsUUJ4xGV/uLo/KL9Bevr3WH093 BODgpisTtXrnviUBzr4643GmOvG2iXMZ/CEoWrMSqbcSQ68RORhxASCsH7yQoqMGwjzSYLG9/zTwn jxjrFC6WyYBkISKErW0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPLvj-002Esn-JX; Wed, 02 Mar 2022 10:09:59 +0000 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPLvf-002Erw-MO for linux-arm-kernel@lists.infradead.org; Wed, 02 Mar 2022 10:09:57 +0000 Received: by mail-wr1-x42f.google.com with SMTP id ay10so1883005wrb.6 for ; Wed, 02 Mar 2022 02:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=i3lmfqgkK7OBdnfa+g16DQZSqexmJcfPngJ3iL8JFWQ=; b=bzryLYEMc/kLGuQY1ack35QrumDbfAAp12lRcHhGRZeRw3oO5F44yuF7vhUYLtpE0O kMy2DU9fhJxiBXZb82oORVE4N1hHhwyuyKYb2gReXiN7L82d0LxDZUQYFnaCX34zzNeh splWSun2E5ixCRR0zqN2xYH9MnCS5elMDFCez/Gby3yfYdCdv/8OmcBKUnuvzP0mKJAd 5xcLDSScqB1vu+Orw8j8tZWytNnFEUqVUB80IpYZPPtQj6rOuZK+WtM8OgpJ3unXtfaL WLb7VnIBPAzjxu8re6JZuOfVlEd+mbEcFyPUWFsT5Wvbr+S2xl34QGDWEowrFdvoNNh1 2XTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=i3lmfqgkK7OBdnfa+g16DQZSqexmJcfPngJ3iL8JFWQ=; b=zoZkIDa7uqK6eh5i2+zmFr7POAdMnoiA2f7bts13Pv3uNfjNRv16OCdcRpXaA4IAkG DvVe0wgsd4vOG7/uyHE+429rFjvdM1NB81t461xr+gVGLVKhzCccjyBrWS6atCRfHoEW zNfHBQ3r27Rj3vIj6Y3+1wNT3s2WRkocCJepkkZieOqrqd67sDqstWX9N8IKLiW4jH24 YjzguG74n8AsD+Q1AuClJ5iCBikV3gumAklJdR6te6wm1D3jEAZbhZk764L33GWaQ1uN b086rad/aBwoDFuyMRb+/lb5sdyigBpiXl3zhKW7jW/G+2OD7om7ei85WW7FlOfqICX4 WCAA== X-Gm-Message-State: AOAM530RevN8FHwjNK8YJXKpCHWOHr63PfOrgMyq2d/OiFTSRXJMqDT9 Po40pOKVbpAtIZw1Bu8k+ok= X-Google-Smtp-Source: ABdhPJw7PGmLyGuK3YhzMCMHZQjy8g0xWTjRS30Z/UhRoTnIwz0j4WFk+41wk8fRnLT5sMDQhhToMg== X-Received: by 2002:adf:b1da:0:b0:1f0:1205:89c1 with SMTP id r26-20020adfb1da000000b001f0120589c1mr5214930wra.27.1646215794139; Wed, 02 Mar 2022 02:09:54 -0800 (PST) Received: from Red ([2a01:cb1d:3d5:a100:264b:feff:fe03:2806]) by smtp.googlemail.com with ESMTPSA id v8-20020a1cf708000000b0034d7b5f2da0sm5165034wmh.33.2022.03.02.02.09.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 02:09:53 -0800 (PST) Date: Wed, 2 Mar 2022 11:09:49 +0100 From: Corentin Labbe To: Ard Biesheuvel Cc: Linus Walleij , Arnd Bergmann , "Russell King (Oracle)" , 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_020955_765786_51C83B53 X-CRM114-Status: GOOD ( 44.66 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Le Wed, Mar 02, 2022 at 10:45:46AM +0100, Ard Biesheuvel a =E9crit : > On Wed, 2 Mar 2022 at 09:55, Corentin Labbe w= rote: > > > > Le Wed, Mar 02, 2022 at 09:44:52AM +0100, Ard Biesheuvel a =E9crit : > > > On Wed, 2 Mar 2022 at 09:40, Corentin Labbe wrote: > > > > > > > > Le Tue, Mar 01, 2022 at 05:52:30PM +0100, Ard Biesheuvel a =E9crit : > > > > > On Tue, 1 Mar 2022 at 17:37, Ard Biesheuvel wro= te: > > > > > > > > > > > > On Tue, 1 Mar 2022 at 16:52, Russell King (Oracle) > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Mar 01, 2022 at 04:48:25PM +0100, Corentin Labbe wrot= e: > > > > > > > > Hello > > > > > > > > > > > > > > > > I booted today linux-next (20220301) and my boot is flooded= with: > > > > > > > > [ 0.000000] unwind: Index not found c0f0c440 > > > > > > > > [ 0.000000] unwind: Index not found 00000000 > > > > > > > > [ 0.000000] unwind: Index not found c0f0c440 > > > > > > > > [ 0.000000] unwind: Index not found 00000000 > > > > > > > > > > > > > > > > This happen on a sun8i-a83t-bananapi-m3 > > > > > > > > > > > > > > Have you enabled vmapped stacks? > > > > > > > > > > > > > > > > > > > This is probably related to > > > > > > > > > > > > 538b9265c063 ARM: unwind: track location of LR value in stack f= rame > > > > > > > > > > > > which removes a kernel_text_address() check on frame->pc as it = is > > > > > > essentially redundant, given that we won't find unwind data oth= erwise. > > > > > > Unfortunately, I failed to realise that the other check carries= a > > > > > > pr_warn(), which may apparently fire spuriously in some cases. > > > > > > > > > > > > The 0x0 value can easily be filtered out, but i would be intere= sting > > > > > > where the other value originates from. We might be able to solv= e this > > > > > > with a simple .nounwind directive in a asm routine somewhere. > > > > > > > > > > > > I'll prepare a patch that disregards the 0x0 value - could you = check > > > > > > in the mean time what the address 0xcf0c440 coincides with in y= our > > > > > > build? > > > > > > > > > > Something like the below should restore the previous behavior, wh= ile > > > > > taking the kernel_text_address() check out of the hot path. > > > > > > > > > > --- a/arch/arm/kernel/unwind.c > > > > > +++ b/arch/arm/kernel/unwind.c > > > > > @@ -400,7 +400,8 @@ int unwind_frame(struct stackframe *frame) > > > > > > > > > > idx =3D unwind_find_idx(frame->pc); > > > > > if (!idx) { > > > > > - pr_warn("unwind: Index not found %08lx\n", frame-= >pc); > > > > > + if (frame->pc && kernel_text_address(frame->pc)) > > > > > + pr_warn("unwind: Index not found %08lx\n"= , frame->pc); > > > > > return -URC_FAILURE; > > > > > } > > > > > > > > Hello > > > > > > > > This is a more detailed trace from my follow up after your patch: > > > > > > So the log below is from a kernel that has the above patch applied? > > > Could you please share the .config? > > > > > > > Yes this is a kernel with above patch applied (this board do not boot w= ithout it). > = > It's not entirely clear to me how (or whether) the recent changes to > unwind.c cause this issue, but one thing that stands out in the > current code is the unguarded dereference of a value pulled of the > stack as a memory address. > = > It is worth noting that the only unwind entries in vmlinux that load > SP from the stack directly (as opposed to unwinding it by moving from > the frame pointer or by addition/subtraction) are the > __irq_svc/__pabt_svc/__dabt_svc entry routines, and given that the > bogus address 60000013 looks suspiciously like a PSR value (which is > stored in the vicinity of SP on the exception stack), my suspicion is > that some unwinder annotations are out of sync with the actual code. > = > So while the below does not fix the root cause, i.e., that the > unwinder unwinds SP incorrectly causing us to dereference a bogus > pointer, it should avoid the subsequent crash. Please give it a go. > = > --- a/arch/arm/kernel/unwind.c > +++ b/arch/arm/kernel/unwind.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > = > #include > @@ -236,10 +237,11 @@ static int unwind_pop_register(struct > unwind_ctrl_block *ctrl, > if (*vsp >=3D (unsigned long *)ctrl->sp_high) > return -URC_FAILURE; > = > - /* Use READ_ONCE_NOCHECK here to avoid this memory access > - * from being tracked by KASAN. > + /* Use get_kernel_nofault() here to avoid this memory access > + * from causing a fatal fault, and from being tracked by KASAN. > */ > - ctrl->vrs[reg] =3D READ_ONCE_NOCHECK(*(*vsp)); > + if (get_kernel_nofault(ctrl->vrs[reg], *vsp)) > + return -URC_FAILURE; > if (reg =3D=3D 14) > ctrl->lr_addr =3D *vsp; > (*vsp)++; The crash disappeared (but the suspicious RCU usage is still here). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel