Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751868AbbFRCBM (ORCPT ); Wed, 17 Jun 2015 22:01:12 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:14305 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751308AbbFRCBD (ORCPT ); Wed, 17 Jun 2015 22:01:03 -0400 Message-ID: <55822600.1020504@huawei.com> Date: Thu, 18 Jun 2015 09:59:28 +0800 From: Li Bin User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Miroslav Benes CC: Josh Poimboeuf , Seth Jennings , Jiri Kosina , Vojtech Pavlik , , , Subject: Re: [PATCH] livepatch: add sysfs interface /sys/kernel/livepatch/state References: <1434522671-31951-1-git-send-email-huawei.libin@huawei.com> <55813BAF.5030904@huawei.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.181] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5582265D.00C1,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e5965d69b37145d9ee489b5e952951ae Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2387 Lines: 72 On 2015/6/17 21:20, Miroslav Benes wrote: > On Wed, 17 Jun 2015, Li Bin wrote: > >> On 2015/6/17 16:13, Miroslav Benes wrote: >>> On Wed, 17 Jun 2015, Li Bin wrote: >> >>> The list of applied patches can be obtained just by 'ls >>> /sys/kernel/livepatch' and their state is in enabled attribute in each >>> respective patch (no, you cannot obtain the order in the stack). >> >> But why we cannot obtain it? I think We indeed need the stack order when we >> will disable one patch, at least, we can find out whether it is on the top of >> the stack if failed to disable one patch. > > I meant with the current means. It is correct that we do not export > information about stacking order anywhere. > > What we do in kGraft is that there is something like refcount for each > patch. When the patch is being applied the refcount of all the previous > patches is increased. Only the patch with the refcount equal to 0 can be > removed. This information is exported and gives one a clue about the > order. > It sounds good, but the information is limited that cannot show the stack order, right? (The refcount of all the disabled patch is equal to 0, if being enable one disabled patch, the stack order is also needed.) refcount Patch ------------------- 3 patch1(enabled) 2 patch2(enabled) 1 patch3(enabled) 0 patch4(enabled) 0 patch5(disabled) 0 patch6(disabled) Unless the refcount is allowed to be less than 0, then when the patch is being disabled the refcount of all the patches is decreased, when the patch is being enabled the refcount of all patches is increased. Only the patch with the refcount equal to 0 can be disabled and only equal to -1 can be enabled, and only less or equal to 0 can be removed (that the livepatch does not support right now). refcount Patch ------------------- 3 patch1(enabled) 2 patch2(enabled) 1 patch3(enabled) 0 patch4(enabled) -1 patch5(disabled) -2 patch6(disabled) Thanks, Li Bin > So if there is a need to have something like this there would certainly > be a way (or ways to be precise) how to do it. The question is if we need > it right now. > > Regards, > Miroslav > > . > -- 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/