Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4747260pxv; Tue, 6 Jul 2021 08:13:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxHbESMcYez4/4gsDrGJDDx6GG4Kku6Bupj9bVKHuj9u0ydML8rz2lgzZY/vnAQo4LhbTf X-Received: by 2002:a02:cb90:: with SMTP id u16mr6294119jap.142.1625584428522; Tue, 06 Jul 2021 08:13:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625584428; cv=none; d=google.com; s=arc-20160816; b=Lm/EvdPZWKE6e8aKKENxlu0L6UFJM2lLDXst1QmVXA4IEgiYr1EeoDLiqzNdBE6eTS 1yNvAdwEKW21SJXLn86CcX911hdhau+DVb7/SBijjkGf25UrWk/g5Wa889fz+kDwZGZ5 YPM8kQMDyI0WihXVXOycqfXEyfPU12ZvjKhPMC2yF4eUJuxij3M4+JDrz5zYkRpdttFG TWtkOoNNuqAl8+PB0AW7936fegINLhG3ZtfZStqqPuQ810ULDubmohcP1DLET5ghIm9P si3tCtnkcDD9KIazV91q7GfDsDC7XOLi+Juoxdngixm2A/CGtD+qoVJjRGsLwdzNOTfR /GbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=uol4WoBbz95ms+g60lDXG98r+TDBMG8pi2MSMXUWyEQ=; b=KWOqMXzX9a9XS/ufRRmUznDxGqa3pGFnpnvi4JAt5I4RZcU5jyOuSj24KqkFqtyhMf TF+a3hapBm8OyFBRifmEfCyvgWGJNzNYrp2AWnhnefLaqtFiwztBOTe0d7+RojtPUKJe s9L1YuibTcQ29pTxk2rUPPRHk/YZyLmh+Ku4amE3bQDFmffNMXt6yiHctdbseoH1vVhJ dmg99h57svEHWfBKd6MIj0icl6TtQtTpe2W3W8jp1CTxOmVgahj+LYP4AG6nu6l1r5DR JEO0e+i7Xk2a/7bo3KnF8yis1rEvGq1tFAnEd+NOPWiK2tpJjTTix2RPSYZqBfK3X20/ +kRw== 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 c8si16701842iow.68.2021.07.06.08.13.37; Tue, 06 Jul 2021 08:13:48 -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 S232356AbhGFPOa (ORCPT + 99 others); Tue, 6 Jul 2021 11:14:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:47632 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232549AbhGFPOX (ORCPT ); Tue, 6 Jul 2021 11:14:23 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2ED2C619AE; Tue, 6 Jul 2021 15:11:43 +0000 (UTC) Date: Tue, 6 Jul 2021 11:11:36 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Masami Hiramatsu , Josh Poimboeuf , Ingo Molnar , X86 ML , Daniel Xu , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, kuba@kernel.org, mingo@redhat.com, ast@kernel.org, Thomas Gleixner , Borislav Petkov , kernel-team@fb.com, yhs@fb.com, linux-ia64@vger.kernel.org, Abhishek Sagar , Andrii Nakryiko Subject: Re: [PATCH -tip v8 11/13] x86/unwind: Recover kretprobe trampoline entry Message-ID: <20210706111136.7c5e9843@oasis.local.home> In-Reply-To: References: <162399992186.506599.8457763707951687195.stgit@devnote2> <162400002631.506599.2413605639666466945.stgit@devnote2> <20210706004257.9e282b98f447251a380f658f@kernel.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Jul 2021 09:55:03 +0200 Peter Zijlstra wrote: > > But I'm not so sure how ftrace treat it. It seems that the return_to_handler() > > doesn't care such case. (anyway, return_to_handler() does not return but jump > > to the original call-site, in that case, the information will be lost.) > > I find it bothersome (OCD, sorry :-) that both return trampolines behave > differently. Doubly so because I know people (Steve in particular) have > been talking about unifying them. They were developed separately, and designed differently with different goals in mind. Yes, I want to unify them, but trying to get the different goals together, compounded by the fact that almost every arch also implemented them differently (in which case, we need to find a way to do it one arch at a time), makes the process extremely frustrating. > > Steve, can you clarify the ftrace side here? Afaict return_to_handler() > is similarly affected. I'm not exactly sure what the issue is. As Masami stated, kretprobe uses a ret to return to the calling function, but ftrace uses a jmp. kretprobe return tracing is more complex than the function graph return tracing is (which is one of the issues I need to overcome to unify them), and when the function graph return trampoline was created, it did things as simple as possible (and before ORC existed). Is this something to worry about now, or should we look to fix his in the unifying process? -- Steve