Received-SPF: pass (google.com: domain of linux-kernel+bounces-183446-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Subject: Re: [PATCH] livepatch: introduce klp_func called interface
From: zhang warden <zhangwarden@gmail.com>
In-Reply-To: <alpine.LSU.2.21.2405200845130.11413@pobox.suse.cz>
Date: Mon, 20 May 2024 15:10:40 +0800
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
 Jiri Kosina <jikos@kernel.org>,
 Petr Mladek <pmladek@suse.com>,
 Joe Lawrence <joe.lawrence@redhat.com>,
 live-patching@vger.kernel.org,
 linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBD2A553-6D44-4CD5-94DD-D8B2D5536F94@gmail.com>
References: <20240520005826.17281-1-zhangwarden@gmail.com>
 <alpine.LSU.2.21.2405200845130.11413@pobox.suse.cz>
To: Miroslav Benes <mbenes@suse.cz>


> On May 20, 2024, at 14:46, Miroslav Benes <mbenes@suse.cz> wrote:
>=20
> Hi,
>=20
> On Mon, 20 May 2024, Wardenjohn wrote:
>=20
>> Livepatch module usually used to modify kernel functions.
>> If the patched function have bug, it may cause serious result
>> such as kernel crash.
>>=20
>> This is a kobject attribute of klp_func. Sysfs interface named
>> "called" is introduced to livepatch which will be set as true
>> if the patched function is called.
>>=20
>> /sys/kernel/livepatch/<patch>/<object>/<function,sympos>/called
>>=20
>> This value "called" is quite necessary for kernel stability
>> assurance for livepatching module of a running system.
>> Testing process is important before a livepatch module apply to
>> a production system. With this interface, testing process can
>> easily find out which function is successfully called.
>> Any testing process can make sure they have successfully cover
>> all the patched function that changed with the help of this =
interface.
>=20
> Even easier is to use the existing tracing infrastructure in the =
kernel=20
> (ftrace for example) to track the new function. You can obtain much =
more=20
> information with that than the new attribute provides.
>=20
> Regards,
> Miroslav
Hi Miroslav

First, in most cases, testing process is should be automated, which make =
using existing tracing infrastructure inconvenient. Second, livepatch is =
already use ftrace for functional replacement, I don=E2=80=99t think it =
is a good choice of using kernel tracing tool to trace a patched =
function.

At last, this attribute can be thought of as a state of a livepatch =
function. It is a state, like the "patched" "transition" state of a =
klp_patch.  Adding this state will not break the state consistency of =
livepatch.

Regards,
Wardenjohn