From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S971348AbdDTVi0 (ORCPT ); Thu, 20 Apr 2017 17:38:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50098 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S971274AbdDTViY (ORCPT ); Thu, 20 Apr 2017 17:38:24 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 722EF20264 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 722EF20264 Date: Thu, 20 Apr 2017 16:38:22 -0500 From: Josh Poimboeuf To: "Steven Rostedt (VMware)" Cc: LKML , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Masami Hiramatsu , kernel test robot Subject: Re: [PATCH] x86/ftrace: Fix ebp in ftrace_regs_caller that screws up unwinder Message-ID: <20170420213822.cgdsa26y3yfno3yj@treble> References: <20170420172236.7af7f6e5@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170420172236.7af7f6e5@gandalf.local.home> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 20 Apr 2017 21:38:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 20, 2017 at 05:22:36PM -0400, Steven Rostedt (VMware) wrote: > From: Steven Rostedt (VMware) > > Fengguang Wu's zero day bot triggered a stack unwinder dump. This can > be easily triggered when CONFIG_FRAME_POINTERS is enabled and -mfentry > is in use on x86_32. > > ># cd /sys/kernel/debug/tracing > ># echo 'p:schedule schedule' > kprobe_events > ># echo stacktrace > events/kprobes/schedule/trigger > > This is because the code that implemented fentry in the > ftrace_regs_caller tried to use the least amount of #ifdefs, and > modified ebp when CC_USE_FENTRY was defined to point to the parent ip > as it does when CC_USE_FENTRY is not defined. But when > CONFIG_FRAME_POINTERS is set, it corrupts the ebp register for this > frame while doing the tracing. > > NOTE, it does not corrupt ebp in any other way. It is just a bad > frame pointer when calling into the tracing infrastructure. The original > ebp is restored before returning from the fentry call. But if a stack > trace is performed inside the tracing, the unwinder will notice the bad > ebp. > > Instead of toying with ebp with CC_USING_FENTRY, just slap the parent > ip into the second parameter (%edx), and have an #else that does it the > original way. > > The unwinder will unfortunately miss the function being traced, as the > stack frame is not set up yet for it, as it is for x86_64. But fixing > that is a bit more complex and did not work before anyway. > > This has been tested with and without FRAME_POINTERS being set while > using -mfentry, as well as using an older compiler that uses mcount. > > Reported-by: kernel test robot > Analyzed-by: Josh Poimboeuf > Link: https://lists.01.org/pipermail/lkp/2017-April/006165.html > Fixes: 644e0e8dc76b ("x86/ftrace: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set") > Signed-off-by: Steven Rostedt (VMware) It's actually CONFIG_FRAME_POINTER (no 'S'). Otherwise, Reviewed-by: Josh Poimboeuf -- Josh