Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934349AbbGVOkI (ORCPT ); Wed, 22 Jul 2015 10:40:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43204 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753561AbbGVOkH (ORCPT ); Wed, 22 Jul 2015 10:40:07 -0400 Date: Wed, 22 Jul 2015 09:40:04 -0500 From: Josh Poimboeuf To: Minfei Huang Cc: sjenning@redhat.com, jkosina@suse.cz, vojtech@suse.cz, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Minfei Huang Subject: Re: [PATCH] livepatch: Fix the issue to make livepatch enable/disable patch correctly Message-ID: <20150722144004.GC23235@treble.redhat.com> References: <1436950506-5252-1-git-send-email-mhuang@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1436950506-5252-1-git-send-email-mhuang@redhat.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1493 Lines: 36 On Wed, Jul 15, 2015 at 04:55:06PM +0800, Minfei Huang wrote: > From: Minfei Huang > > Livepatch will obey the stacking rule to enable/disable the patch. It > only allows to enable the patch, when it is the fist disabled patch, > disable the patch, when it is the last enabled patch. > > In the livepatch code, it uses list to gather the all of the patches. > And we do not know whether the previous/next patch is patched to the > same modules or vmlinux in that way. > > According to above rule, livepatch will make incorrect decision to > enable/disable the patch. Following is an example to show how livepatch > does. > > - install the livepatch example module which is in samples/livepatch. > - install the third part kernel module > - install the livepatch module which is patched to the third part module > - disable the livepatch example module > > We can find that we can not disable livepatch example module, although > it is the last enabled patch. > > To fix this issue, we will find the corresponding patch which is patched > to the same modules or vmlinux, when we enable/disable the patch. Is it really safe to assume that there are no dependencies between patches which patch different objects? -- 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/