Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751610AbbDNE5I (ORCPT ); Tue, 14 Apr 2015 00:57:08 -0400 Received: from blu004-omc4s10.hotmail.com ([65.55.111.149]:59949 "EHLO BLU004-OMC4S10.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035AbbDNE5D (ORCPT ); Tue, 14 Apr 2015 00:57:03 -0400 X-TMN: [BnBuiNuj9X2DKRHlvE2yqTuvg2AA2+Q4] X-Originating-Email: [minfei.huang@hotmail.com] Message-ID: Date: Tue, 14 Apr 2015 12:56:57 +0800 From: Minfei Huang To: Josh Poimboeuf CC: Petr Mladek , sjenning@redhat.com, jkosina@suse.cz, vojtech@suse.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] livepatch: Add a new function to verify the address and name match for extra module References: <20150413083725.GA16088@pathway.suse.cz> <20150413094121.GD16088@pathway.suse.cz> <20150413102240.GE16088@pathway.suse.cz> <20150413225849.GC4412@treble.hsd1.ky.comcast.net> <20150414040538.GF4412@treble.hsd1.ky.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150414040538.GF4412@treble.hsd1.ky.comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-OriginalArrivalTime: 14 Apr 2015 04:57:01.0127 (UTC) FILETIME=[717DED70:01D0766F] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3833 Lines: 92 On 04/13/15 at 11:05P, Josh Poimboeuf wrote: > On Tue, Apr 14, 2015 at 08:48:11AM +0800, Minfei Huang wrote: > > On 04/14/15 at 08:17P, Minfei Huang wrote: > > > On 04/13/15 at 05:58P, Josh Poimboeuf wrote: > > > > On Mon, Apr 13, 2015 at 06:37:10PM +0800, Minfei Huang wrote: > > > > > For my patches, I think it is used by the persion which will compose the > > > > > patch individually, not for the manufactor. > > > > > > > > > > Yes, Verifying extra function address is more useless in general, due to > > > > > the changable address on different system. > > > > > > > > > > IMO, we shall do our best to make livepatch more robust. > > > > > > > > IIUC, to use this, you'd have to load the module first, manually look up > > > > the module function's address, and _then_ build the patch for the > > > > running system. And the resulting patch wouldn't work on other systems. > > > > > > > > Do you have concrete plans to use it this way? > > > > > > > > Just trying to understand if this is needed for a real world usage > > > > scenario. > > > > > > For some companies(like cloud computing company), they will compose > > > their own module to improve the performance. > > > > > > Once there is some bug for the own module, they cannt restart to reload > > > the fixed-module. So it seems that livepatch is the best way to fix this > > > issue. > > > > > > Before livepatch being integrated in kernel, we usually use ksplice to > > > patch the patch. > > > > > > What the above scenario I met is in my previous work. > > > > > > For now, livepatch cannt patch the patch for extra module, once the > > > function name is larger than 127. > > > > > > > Also, Maybe there is some day, we can use script to detect the function > > name and address in userspace, then generate the patch to patch the > > defective kernel or extra module. > > I'd rather wait until we have a real world use case before adding > support for that. Otherwise we end up bloating the code and have to > support a nebulous feature which nobody uses. > Hi, Josh. The above scenario is not fake to be suit for the patches. And it is normal that end user composes patch to patch the kernel for extra module. It is significative that livepatch support to patch extra module. Livepatch is more important for the system which cannt reboot without schedule. > > So the people who want to use livepatch never concern how to compose the > > patch to patch the kernel or extra module by using livepatch. All they > > will do is to provide a common patch which is different with the > > original code. > > We already have a kpatch tool named kpatch-build which does this. It is > not yet upstreamed into Linux. The key difference is that it creates > the patch at compile time rather than runtime. The resulting patch > works for _all_ systems running the given version of kernel, rather than > only the current system. > Yes, Linda mentioned the kpatch on one of the meeting. But we cannot only consider what we know, because the end user's environment is complicated. For my previous work, the extra module which uses to improve the performance is running on CentOS6.3, CentOS6.5. For per fixing, we will compose the patch on different kernel version(maybe the different zstream kernel version). Meanwhile, for the patches, I just want to add a new function that end user can have chance to use function name and function address to match the function for extra module, not only the function name. Also maybe the specified patch is only for the currect system. Thanks Minfei > -- > Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/