Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp686768pxk; Wed, 2 Sep 2020 12:04:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7yKtXGNviB/xgRA5/Z1/932j0cU8TBGoLFVeETLPBb9s9WUJAMa6a6lRJf56VOY6bF6WW X-Received: by 2002:a17:906:e8f:: with SMTP id p15mr1568296ejf.290.1599073478443; Wed, 02 Sep 2020 12:04:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599073478; cv=none; d=google.com; s=arc-20160816; b=jx21NGb5BSqpCy6Mgvx4RZ5qVDWBSwly71I2uVJA7DTDX6/rlYy8GVldEfLtdSj3tM dcUUACZQaZYV21rfGGVdaKKt6dpr9z+nbaTC2odGaA0cH7qweMAw0RRzvi5fyFQkrik9 hGlAqd+FjFuZ0YiwJu1fZds+YbZGQrFT5FWEMHpA9lBbUQNj7E6gT7MHJvQ5TEMWMv/b SDUXPfTMYx78T4zoNAJBSsUtQvhGmdI6AmtA+5Lx1vGW/Sf90GnaFjrtBBONFjNfzo3b dYnPlCcxK+o5YHmOYXl4MfsCG7j4ZGJOQ8zqn/NQnsqaQd+kiAYNPG41molOatDYD65x 5OaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xD1qsmV0wQrOaFHJksxNTxbM0jGQ06z4qg4KyXHGfbA=; b=jxLP00UzKTdtlvjoks4szRqqrJU/dSqPs3aLzcqo+8Zq7I9e/ZlLdD1FAPZy9eOPPK um7f5ERBJcbPZ112vD3OtFTJDsygFCwnrS+IpbQXiiqvANtWxfUeHDpMhcFemdXIQ/fV /wWaw9i/U6XtmoNaLGDxztweq/ThLpT3k1YRkTBkYpj5VOv77Vd3X8z5SDqISuhMXweo IBCKE3cFMlrQ9WIMpeaAHPWUeZowHdtkkrqYpLntyth0jV3/cQJRrlHTDI708nJd8ABY jznCmGyPVIVxaOUo7Hk1gB6RGP1KjQiG+qhW4jwoYLUHZOd+CfMu4mmpHjIkUj3ZAkQD i1+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z1si277312eju.231.2020.09.02.12.04.13; Wed, 02 Sep 2020 12:04:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726293AbgIBTDU (ORCPT + 99 others); Wed, 2 Sep 2020 15:03:20 -0400 Received: from foss.arm.com ([217.140.110.172]:44940 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbgIBTDS (ORCPT ); Wed, 2 Sep 2020 15:03:18 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 57F1F1045; Wed, 2 Sep 2020 12:03:13 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.4.242]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ACB313F71F; Wed, 2 Sep 2020 12:03:09 -0700 (PDT) Date: Wed, 2 Sep 2020 20:03:06 +0100 From: Mark Rutland To: Mark Brown Cc: Catalin Marinas , Will Deacon , Vasily Gorbik , Heiko Carstens , Borislav Petkov , Thomas Gleixner , "H. Peter Anvin" , Christian Borntraeger , Ingo Molnar , Jiri Slaby , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Miroslav Benes Subject: Re: [PATCH v2 0/3] arm64: Convert to ARCH_STACKWALK Message-ID: <20200902190306.GB5875@C02TD0UTHF1T.local> References: <20200819124913.37261-1-broonie@kernel.org> <20200901160626.GE95447@C02TD0UTHF1T.local> <20200902173803.GE6162@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200902173803.GE6162@sirena.org.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 02, 2020 at 06:38:03PM +0100, Mark Brown wrote: > On Tue, Sep 01, 2020 at 05:06:26PM +0100, Mark Rutland wrote: > > > Just to check, has the skipping logic been tested to work equivalently > > to what we had before? By inspection I think it should, but since it > > relies on function call boundaries it always strikes me as fragile. > > > If you could confirm that (e.g. with LKDTM perhaps?) that'd be great. > > Assuming that looks right, for the series: > > I've tested this with LKDTM and otherwise and didn't spot any issues > (and just did a bit of retesting) but it is a pretty manual process so > it's possible I missed something. It looks like the case Mirolav pointed out (self-bactrace with NULL regs) isn't triggered by LKDTM (since it always causes a backtrace from an exception with non-NULL regs), but we do rely on that elsewhere in the kernel. It might be worth adding an LKDTM test to trigger that. I'll wait for a respin that handles that -- please drop the ack for now. Thanks, Mark.