From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935390AbcCPX6w (ORCPT ); Wed, 16 Mar 2016 19:58:52 -0400 Received: from mail-pf0-f181.google.com ([209.85.192.181]:34148 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935267AbcCPX6u (ORCPT ); Wed, 16 Mar 2016 19:58:50 -0400 Subject: Re: [v3,1/8] powerpc: Create a helper for getting the kernel toc value To: Jiri Kosina , Michael Ellerman References: <3qNsms00H7z9snl@ozlabs.org> Cc: linuxppc-dev@ozlabs.org, pmladek@suse.com, jeyu@redhat.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, kamalesh@linux.vnet.ibm.com, duwe@lst.de, live-patching@vger.kernel.org, mbenes@suse.cz From: Balbir Singh Message-ID: <56E9F332.1070206@gmail.com> Date: Thu, 17 Mar 2016 10:58:42 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/03/16 12:27, Jiri Kosina wrote: > On Mon, 14 Mar 2016, Michael Ellerman wrote: > >>> Move the logic to work out the kernel toc pointer into a header. This is >>> a good cleanup, and also means we can use it elsewhere in future. >>> >>> Reviewed-by: Kamalesh Babulal >>> Reviewed-by: Torsten Duwe >>> Signed-off-by: Michael Ellerman >>> Tested-by: Kamalesh Babulal >> Series applied to powerpc next. >> >> https://git.kernel.org/powerpc/c/a5cab83cd3d2d75d3893276cb5 > Thanks Michael; this is an excellent basis for ppc live patching, but FYI > I am not merging that one to my tree just yet. > > The solution (*) for functions with non-trivial argument list is not there > yet, and it's my requirement for this to be taken care of in a way that's > not prone to easily-done human errors on the patch-producer side. > > (*) both "making it work" or "making it so broken that it's guaranteed > that noone would ever produce a patch that brings the kernel down" is > okay, but I really don't feel that just documenting the limitation is > sufficient and safe in this case; kudos to Torsten here for > idenfitfying the problem before it actually became The Problem To be honest I think my v6 works well, but I don't have complete confidence due to the lack of proper testing. livepatch samples plus some others I wrote and I one Petr wrote all work (calling patched from within patched), but we need more confidence with good tests or an alternative approach that is easier to review and be satisfied with > > Thanks, >