From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754484AbbETQwA (ORCPT ); Wed, 20 May 2015 12:52:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55958 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753444AbbETQv7 (ORCPT ); Wed, 20 May 2015 12:51:59 -0400 Date: Wed, 20 May 2015 18:51:17 +0200 From: Oleg Nesterov To: Srikar Dronamraju Cc: Ananth N Mavinakayanahalli , Anton Arapov , David Long , Denys Vlasenko , "Frank Ch. Eigler" , Ingo Molnar , Jan Willeke , Jim Keniston , Mark Wielaard , Pratyush Anand , linux-kernel@vger.kernel.org, Benjamin Herrenschmidt Subject: Re: [PATCH 07/10] uprobes/x86: Introduce arch_uretprobe_is_alive() Message-ID: <20150520165117.GA4284@redhat.com> References: <20150504124835.GA22462@redhat.com> <20150504124914.GA22512@redhat.com> <20150507110852.GF30396@linux.vnet.ibm.com> <20150507171119.GC18652@redhat.com> <20150508113058.GA5757@linux.vnet.ibm.com> <20150510122147.GA2493@redhat.com> <20150513081123.GB5757@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150513081123.GB5757@linux.vnet.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Srikar, sorry for delay, vacation. On 05/13, Srikar Dronamraju wrote: > > > No. I don't think arch_uretprobe_is_alive() above can work for powerpc, > > at least the same way. > > > > The problem is, when the function is called, the ret-addr is not pushed > > on stack. If it was, then arch_uretprobe_hijack_return_addr() on powerpc > > is just wrong. But I guess it is correct ;) > > > > x86 is "simple". We know that the probed function should do "ret" and the > > ret-addr lives on stack. This means that "regs->sp <= sp" is correct, it > > can't be false-negative. Simply because if regs->sp > sp then *sp can be > > never used by "ret". And everything above regs->sp can be overwritten by > > a signal handler. powerpc/etc differs, they use the link register. > > > > In ppc, the return address for the current function may not be in stack > but in link register, but the return address for the previous functions > end up in the stack. Yes, yes, I understand. That is why I hope that this series can help other arches too ;) But note that at least this means that the "on_call" arg should be ignored, although this is not the problem too. > Lets assume main() had called foo(). Now when foo() > calls bar (by using the b/bl instruction), we would save the current > link register (that has address corresponding to main function) to the > link register save area of the stack and update the stack pointer and > the link register to an address to where we need to jump back in foo(). Yes. Now suppose that you ret-probe both main() and foo(). What happens when foo() returns? I guess it should cleanup the stack and remove the main's ret-addr from stack, doesn't this mean that arch_uretprobe_is_alive(auret_for_main) becomes false if we just use user_stack_pointer(regs) <= sp for every arch? This will break handle_trampoline(). > > So. Lets do this per-arch. Try to do, actually. I am not even sure these > > new hooks can actually help powerpc/etc. If not, we will have to switch > > to "plan B". > > Okay, lets do it per-arch now and yes it can always be cleaned up later. Yes, this just looks safer. At least this way we can't introduce the new problems on !x86. Oleg.