Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1631439pxb; Thu, 4 Mar 2021 17:00:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJxUIMBCx+bw7K9ilXhCF0LeLhEm04Wychehv2MThnDlglcHCXnGjKzVPtMZ2GMF+DJljA2+ X-Received: by 2002:a05:6602:280f:: with SMTP id d15mr5648308ioe.127.1614906016345; Thu, 04 Mar 2021 17:00:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614906016; cv=none; d=google.com; s=arc-20160816; b=nCER4/dR3PkwkAXH6jMoeYUWHJR3pC61Yob140CpfXptZLdOWKYe9oZldNFFKgs+eF tISp65ZCttQ6o3lKR7tlWJbsmKXW5pF1MVtA1Yh4RRmJbDa3d57of+dKizFMKaCIFds9 qs/Is9ZGqTi/Rg8n+EQIqLCxCOuqi6gLbY96sbzc1XznAkkVT2syM+UvQflTy+8Qdsml KVdB56F6b6+WyDvhShclNgiVN+8EvuPlo+mTOiyXW6HGzpw/3haVRg7YL7Lhv0wTmsfR RGYNSt76Nou0cinU7ng2XnX6AwOZX9G7a7UmVe6eNlFnLB/tiDa8jHQF80VcrW38As+T jo/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=GXVrh8xVvhHcAA4BfYXh++X/tXAX/hAbk8CkgR05Vug=; b=YiA0Ves9Ys23FaKjkgrgiG8KOUg6eW9Rlb6XRl1UlDLnI4E9B0xOSlTW4a/a6hD9TB v+Ci87wbqDwJ/HVfOY1tJPkEUuqG84IjIuuU4vLlBBLrZlLkPkrzfl4GW2c7J9Oym3Eo qEukU9kiATLaDWuqE1MsDn/vYuaRLSUA54uCJlBciHhNzEbINBsxRP0fVrYURXYC/Syh eyU9t/9EO+rdXRzRvwAaSbaGcRmcZSYNVVdYXK1ZBQo0ePU7w1MfJYTQ34xBLBsxmaqP k8P05VbgK4c5bC/7tPPxKTQjT2NR8DZYLs4FfiIVddqUjyh6ZMEQjmx5nPwa/BcLreEQ qdng== 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 y5si908228iof.34.2021.03.04.17.00.03; Thu, 04 Mar 2021 17:00:16 -0800 (PST) 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 S241324AbhCDWDI (ORCPT + 99 others); Thu, 4 Mar 2021 17:03:08 -0500 Received: from gate.crashing.org ([63.228.1.57]:36144 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241291AbhCDWC6 (ORCPT ); Thu, 4 Mar 2021 17:02:58 -0500 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 124Lsnob015064; Thu, 4 Mar 2021 15:54:49 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 124Lsm4r015063; Thu, 4 Mar 2021 15:54:48 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 4 Mar 2021 15:54:48 -0600 From: Segher Boessenkool To: Mark Rutland Cc: Marco Elver , Catalin Marinas , Will Deacon , LKML , broonie@kernel.org, Paul Mackerras , kasan-dev , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends Message-ID: <20210304215448.GU29191@gate.crashing.org> References: <1802be3e-dc1a-52e0-1754-a40f0ea39658@csgroup.eu> <20210304145730.GC54534@C02TD0UTHF1T.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210304145730.GC54534@C02TD0UTHF1T.local> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Thu, Mar 04, 2021 at 02:57:30PM +0000, Mark Rutland wrote: > It looks like GCC is happy to give us the function-entry-time FP if we use > __builtin_frame_address(1), From the GCC manual: Calling this function with a nonzero argument can have unpredictable effects, including crashing the calling program. As a result, calls that are considered unsafe are diagnosed when the '-Wframe-address' option is in effect. Such calls should only be made in debugging situations. It *does* warn (the warning is in -Wall btw), on both powerpc and aarch64. Furthermore, using this builtin causes lousy code (it forces the use of a frame pointer, which we normally try very hard to optimise away, for good reason). And, that warning is not an idle warning. Non-zero arguments to __builtin_frame_address can crash the program. It won't on simpler functions, but there is no real definition of what a simpler function *is*. It is meant for debugging, not for production use (this is also why no one has bothered to make it faster). On Power it should work, but on pretty much any other arch it won't. > Unless we can get some strong guarantees from compiler folk such that we > can guarantee a specific function acts boundary for unwinding (and > doesn't itself get split, etc), the only reliable way I can think to > solve this requires an assembly trampoline. Whatever we do is liable to > need some invasive rework. You cannot get such a guarantee, other than not letting the compiler see into the routine at all, like with assembler code (not inline asm, real assembler code). The real way forward is to bite the bullet and to no longer pretend you can do a full backtrace from just the stack contents. You cannot. Segher