All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Bin <huawei.libin@huawei.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Seth Jennings <sjenning@redhat.com>,
	Vojtech Pavlik <vojtech@suse.cz>, Jiri Slaby <jslaby@suse.cz>,
	Miroslav Benes <mbenes@suse.cz>, <live-patching@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <lizefan@huawei.com>,
	<guohanjun@huawei.com>, <zhangdianfang@huawei.com>,
	<xiexiuqi@huawei.com>
Subject: Re: [PATCH 2/2] livepatch: disable/enable_patch manners for interdependent patches
Date: Thu, 22 Jan 2015 08:42:29 +0800	[thread overview]
Message-ID: <54C04775.1070908@huawei.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1501211506420.10817@pobox.suse.cz>

On 2015/1/21 22:08, Jiri Kosina wrote:
> On Wed, 21 Jan 2015, Li Bin wrote:
> 
>> for disable_patch:
>> The patch is unallowed to be disabled if one patch after has
>> dependencies with it and has been enabled.
>>
>> for enable_patch:
>> The patch is unallowed to be enabled if one patch before has
>> dependencies with it and has been disabled.
>>
>> Signed-off-by: Li Bin <huawei.libin@huawei.com>
>> ---
>>  kernel/livepatch/core.c |   60 +++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 60 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index 7861ed2..a12a31c 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
>> @@ -114,6 +114,21 @@ static bool klp_is_patch_registered(struct klp_patch *patch)
>>  	return false;
>>  }
>>  
>> +static bool klp_func_in_patch(struct klp_func *kfunc, struct klp_patch *patch)
>> +{
>> +	struct klp_object *obj;
>> +	struct klp_func *func;
>> +
>> +	for (obj = patch->objs; obj->funcs; obj++) {
>> +		for (func = obj->funcs; func->old_name; func++) {
>> +			if (kfunc->old_addr == func->old_addr) {
>> +				return true;
>> +			}
>> +		}
>> +	}
>> +	return false;
>> +}
>> +
>>  static bool klp_initialized(void)
>>  {
>>  	return klp_root_kobj;
>> @@ -466,8 +481,31 @@ unregister:
>>  static int __klp_disable_patch(struct klp_patch *patch)
>>  {
>>  	struct klp_object *obj;
>> +	struct klp_patch *temp;
>> +	struct klp_func *func;
>>  	int ret;
>>  
>> +	/*
>> +	 * the patch is unallowed to be disabled if one patch
>> +	 * after has dependencies with it and has been enabled.
>> +	 */
>> +	for (temp = list_next_entry(patch, list);
>> +			&temp->list != &klp_patches;
>> +			temp = list_next_entry(temp, list)) {
>> +		if (temp->state != KLP_ENABLED)
>> +			continue;
>> +
>> +		for (obj = patch->objs; obj->funcs; obj++) {
>> +			for (func = obj->funcs; func->old_name; func++) {
>> +				if (klp_func_in_patch(func, temp)) {
>> +					pr_err("this patch depends on '%s', please disable it firstly\n",
>> +						   temp->mod->name);
>> +					return -EBUSY;
>> +				}
>> +			}
>> +		}
>> +	}
>> +
>>  	pr_notice("disabling patch '%s'\n", patch->mod->name);
>>  
>>  	for (obj = patch->objs; obj->funcs; obj++) {
>> @@ -519,11 +557,33 @@ EXPORT_SYMBOL_GPL(klp_disable_patch);
>>  static int __klp_enable_patch(struct klp_patch *patch)
>>  {
>>  	struct klp_object *obj;
>> +	struct klp_patch *temp;
>> +	struct klp_func *func;
>>  	int ret;
>>  
>>  	if (WARN_ON(patch->state != KLP_DISABLED))
>>  		return -EINVAL;
>>  
>> +	/*
>> +	 * the patch is unallowed to be enabled if one patch
>> +	 * before has dependencies with it and has been disabled.
>> +	 */
>> +	for (temp = list_first_entry(&klp_patches, struct klp_patch, list);
>> +			temp != patch; temp = list_next_entry(temp, list)) {
>> +		if (temp->state != KLP_DISABLED)
>> +			continue;
>> +
>> +		for (obj = patch->objs; obj->funcs; obj++) {
>> +			for (func = obj->funcs; func->old_name; func++) {
>> +				if (klp_func_in_patch(func, temp)) {
>> +					pr_err("this patch depends on '%s', please enable it firstly\n",
>> +						   temp->mod->name);
>> +					return -EBUSY;
> 
> By this you limit the definition of the patch inter-dependency to just 
> symbols. But that's not the only way how patches can depend on it other -- 
> the dependency can be semantical.

Yes, I agree with you. But I think the other dependencies such as semantical
dependency should be judged by the user, like reverting a patch from git repository.
Right?

Thanks,
	Li Bin

> 



  reply	other threads:[~2015-01-22  0:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21  9:07 [PATCH 0/2] disable/enable_patch manners for interdependent patches Li Bin
2015-01-21  9:07 ` [PATCH 1/2] livepatch: Revert "livepatch: enforce patch stacking semantics" Li Bin
2015-01-21 14:06   ` Jiri Kosina
2015-01-21 14:36     ` Seth Jennings
2015-01-22  0:44       ` Li Bin
2015-01-22  1:01   ` Li Bin
2015-01-22  9:15     ` Miroslav Benes
2015-01-22  9:42       ` Li Bin
2015-01-21  9:07 ` [PATCH 2/2] livepatch: disable/enable_patch manners for interdependent patches Li Bin
2015-01-21 14:08   ` Jiri Kosina
2015-01-22  0:42     ` Li Bin [this message]
2015-01-22  3:51       ` Josh Poimboeuf
2015-01-22  8:39         ` Li Bin
2015-01-22  9:54           ` Li Bin
2015-01-22 13:05             ` Josh Poimboeuf
2015-01-23  1:08               ` Li Bin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54C04775.1070908@huawei.com \
    --to=huawei.libin@huawei.com \
    --cc=guohanjun@huawei.com \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mbenes@suse.cz \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.cz \
    --cc=xiexiuqi@huawei.com \
    --cc=zhangdianfang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.