Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp792474rwe; Thu, 1 Sep 2022 07:43:06 -0700 (PDT) X-Google-Smtp-Source: AA6agR6phe5tZqfdg6eVLvzuW7e9XCZ8xE5/ym3oUARqkliSSCHd/14QOtFbs+Is7DHC9Z+VloNx X-Received: by 2002:a17:902:d4c4:b0:173:1206:cee7 with SMTP id o4-20020a170902d4c400b001731206cee7mr30476752plg.142.1662043385771; Thu, 01 Sep 2022 07:43:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662043385; cv=none; d=google.com; s=arc-20160816; b=n5w+Ua54eE0PuN3oG4DA8doI9BJkogxsgzHXcU1jNwipZuh0+h1NlShalfPkKbBFWu B5G3NRF3cZ3OAUCgWtUiHhsuWfC8F10IiK4IlQoWxPofNk3WO66tB3NM5+YTV37mDyX5 UFS8QJjl0CaNVA6zz8IG0QrxLgiejdPJCOEBhpfcxI6R/D2GJJCAWlu6L41rOCCnTpoX Af4o6lORfe515UtpPD+Jv9YVR1kkPVcq2CsOB5qQfTee9q0g4Qy/tzDjbQmU3mbvRZxu OTn7v3OVGhG23WqXvbzhk5GON3Ol67NadqHvm0JXMyfrkdKov6z0A2w2ce+KGsAylOdA 4F1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=8LWgg6owsnlx0e20bDfAb/b6qis3DAUj9Q3YQHgTX6E=; b=WMK7Bu6WgH2pEcG+i1ltyB09i0mxCII3+xVZGbsAR6Vg3xKQZE/4Wgvtue8VKG7nRQ NmQEZsJa4e0K3kKx1P995c27pJoYG/R2aLVhhucIhxsAlGzcNW8VecKgjrwQBALdXxLE 3FwzVygJzsLDe5YRu9YpBdV3dumcx7iQP7SR+I+knTcjEa1Cu9u07/PZo64Y/s25mMPB 3QOsVr3Of3vKonxzuNO4cPOxtazqBRuPd32dL7DX5bjFS60owSpZi2P18lpp58rAo4bE YuHzJ32yiR6yXISSDjnEMOZJAabsznH4gvlJkgO9fYAybJfRSpkdKTu2aVjhdU0n+GH0 u6KA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=Xcxr5QcM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w3-20020a634903000000b0042b3587dfa8si7855031pga.628.2022.09.01.07.42.45; Thu, 01 Sep 2022 07:43:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=Xcxr5QcM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231351AbiIAOSc (ORCPT + 99 others); Thu, 1 Sep 2022 10:18:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230370AbiIAOS3 (ORCPT ); Thu, 1 Sep 2022 10:18:29 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B7D83A4A8; Thu, 1 Sep 2022 07:18:26 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id EC3812296C; Thu, 1 Sep 2022 14:18:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1662041904; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8LWgg6owsnlx0e20bDfAb/b6qis3DAUj9Q3YQHgTX6E=; b=Xcxr5QcM1xoSU1ictcXSIbk3WTLKQHPd8zVEBQ4K11OXezUwhIHgZTSEAP3K6kfbdRKzxi 8a/KKKcAKOV+SV8+qAAE3PbkctgHdUTDE4LtTcCBt42i5Ns/qUJJ8yeJzwtDCorehY4TNQ 7xHHPrEtrluRHFmydzIH/7P/Jl42eDY= Received: from suse.cz (unknown [10.100.208.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id BB3F92C141; Thu, 1 Sep 2022 14:18:24 +0000 (UTC) Date: Thu, 1 Sep 2022 16:18:23 +0200 From: Petr Mladek To: Zhen Lei Cc: Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Joe Lawrence , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] livepatch: Move error print out of lock protection in klp_enable_patch() Message-ID: References: <20220901022706.813-1-thunder.leizhen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220901022706.813-1-thunder.leizhen@huawei.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2022-09-01 10:27:06, 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 Please, is this part of some longterm effort to reduce the size of the kernel? Or is this just some random observation? > Signed-off-by: Zhen Lei > --- > 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); I do not see how this change could reliably reduce the code size. As Joe wrote, it looks like a random effect that is specific to a particular compiler version, compilation options, and architecture. I am against these kind of random microptimizations. It is just a call for problems. If you move printk() outside of a lock, you need to make sure that the information is not racy. It might be safe in this particular case. But it is a bad practice. It adds an extra work. It is error-prone with questionable gain. I am sorry but I NACK this patch. There must be better ways to reduce the kernel binary size. Best Regards, Petr