Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757213AbcCXKQN (ORCPT ); Thu, 24 Mar 2016 06:16:13 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:34420 "EHLO e23smtp08.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754495AbcCXKP7 (ORCPT ); Thu, 24 Mar 2016 06:15:59 -0400 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: kamalesh@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;live-patching@vger.kernel.org Date: Thu, 24 Mar 2016 15:44:55 +0530 From: Kamalesh Babulal To: Torsten Duwe Cc: Michael Ellerman , Petr Mladek , jeyu@redhat.com, jkosina@suse.cz, jikos@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, linuxppc-dev@ozlabs.org, live-patching@vger.kernel.org, mbenes@suse.cz Subject: Re: [PATCH/RFC] ppc64 livepatch: frameless klp_return_helper using odd TOC Message-ID: <20160324101453.GA1445@linux.vnet.ibm.com> Reply-To: Kamalesh Babulal References: <20160323155858.GB27110@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20160323155858.GB27110@lst.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16032410-0029-0000-0000-000045187C43 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1315 Lines: 36 * Torsten Duwe [2016-03-23 16:58:58]: > > Since nobody liked the extra stack frame nor its workarounds, here is > the next attempt. Assumptions: > > 1. Heuristics are bad. The better they are, the more subtly the > way they might fail. > > 2. The TOC pointer is usually dividable by 4, if not by 8. An odd > value never occurs. > > Conclusively, this patch unambiguously creates an odd TOC value when > an ftraced function's global entry point is used. Ftrace_caller will > then immediately fix it, and alongside gather the information whether > the made call was local or global. > > In case of live patching this information is furthermore used to decide > whether a klp_return_helper needs to be inserted or not. > CAVEAT: any frameless klp_return_helper does not play well with > sibling calls! There's an emergency exit that might work, at worst > it will cause an oops, but it surely avoids a lockup. > At least the live patching modules on ppc64le will need to be compiled > using the -fno-optimize-sibling-calls compiler flag! > > Thanks go to Michael Matz and Richard Biener for reassurance about > heuristics and pointers to the compiler flag. > > Signed-off-by: Torsten Duwe Hi Torsten, Should this patch be applied over Petr Mladek's v4 ? Thanks, Kamalesh.