Live Patching
 help / color / mirror / Atom feed
From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Petr Mladek <pmladek@suse.com>, <linux-kernel@vger.kernel.org>,
	<live-patching@vger.kernel.org>
Subject: Re: [PATCH] livepatch: Move error print out of lock protection in klp_enable_patch()
Date: Thu, 1 Sep 2022 21:45:30 +0800	[thread overview]
Message-ID: <19e0d24c-366a-a269-8c4d-bf32831e2079@huawei.com> (raw)
In-Reply-To: <65fe1978-60da-5bd4-9559-fddec13f03bf@redhat.com>



On 2022/9/1 21:24, Joe Lawrence wrote:
> On 8/31/22 10:27 PM, Zhen Lei wrote:
>> The patch->mod is not a protected object of mutex_lock(&klp_mutex). Since
>> it's in the error handling branch, it might not be helpful to reduce lock
>> conflicts, but it can reduce some code size.
>>
>> Before:
>>    text    data     bss     dec     hex filename
>>   10330     464       8   10802    2a32 kernel/livepatch/core.o
>>
>> After:
>>    text    data     bss     dec     hex filename
>>   10307     464       8   10779    2a1b kernel/livepatch/core.o
>>
> 
> Is a size change expected, or is it just compiler fall out from
> shuffling the code around a little bit?

I thought it was because mutex_lock()/mutex_unlock() was close enough to
reduce a "&klp_mutex" operation. Now, I was wrong.

> 
> I see some arches do a little better, some a little worse with gcc-9.3.0
> cross compilers:

Sorry. This is what I should have done. I built it on x86_64 with gcc-8.4.0

> 
> Before
> ------
>    text    data     bss     dec     hex filename
>    8490     600       8    9098    238a arm64/kernel/livepatch/core.o
>    9424     680       8   10112    2780 s390/kernel/livepatch/core.o
>    9802     228       4   10034    2732 ppc32/kernel/livepatch/core.o
>   13746     456       8   14210    3782 ppc64le/kernel/livepatch/core.o
>   10443     464       8   10915    2aa3 x86_64/kernel/livepatch/core.o
> 
> 
> After
> -----
>    text    data     bss     dec     hex filename
>    8514     600       8    9122    23a2 arm64/kernel/livepatch/core.o
>    9424     680       8   10112    2780 s390/kernel/livepatch/core.o
>    9818     228       4   10050    2742 ppc32/kernel/livepatch/core.o
>   13762     456       8   14226    3792 ppc64le/kernel/livepatch/core.o
>   10446     464       8   10918    2aa6 x86_64/kernel/livepatch/core.o
> 
> In which case, I'd just omit the size savings from the commit msg.

OK. Should I send v2 to update commit message?

> 
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>>  kernel/livepatch/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index 42f7e716d56bf72..cb7abc821a50584 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
>> @@ -1041,9 +1041,9 @@ int klp_enable_patch(struct klp_patch *patch)
>>  	mutex_lock(&klp_mutex);
>>  
>>  	if (!klp_is_patch_compatible(patch)) {
>> +		mutex_unlock(&klp_mutex);
>>  		pr_err("Livepatch patch (%s) is not compatible with the already installed livepatches.\n",
>>  			patch->mod->name);
>> -		mutex_unlock(&klp_mutex);
>>  		return -EINVAL;
>>  	}
>>  
>>
> 
> That said, I don't see anything obviously wrong about the change (we
> don't need to sync our error msgs, right?) so:

Yes

> 
> Acked-by: Joe Lawrence <joe.lawrence@redhat.com>

Thanks

> 

-- 
Regards,
  Zhen Lei

  reply	other threads:[~2022-09-01 13:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01  2:27 [PATCH] livepatch: Move error print out of lock protection in klp_enable_patch() Zhen Lei
2022-09-01 13:24 ` Joe Lawrence
2022-09-01 13:45   ` Leizhen (ThunderTown) [this message]
2022-09-01 14:18 ` Petr Mladek
2022-09-02  1:28   ` Leizhen (ThunderTown)
2022-09-02 13:36     ` Petr Mladek
2022-09-05  1:20       ` Leizhen (ThunderTown)

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=19e0d24c-366a-a269-8c4d-bf32831e2079@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox