This feature can provide livepatch patch order information.
With the order of sysfs interface of one klp_patch, we can
use patch order to find out which function of the patch is
now activate.

After the discussion, we decided that patch-level sysfs
interface is the only accaptable way to introduce this
information.

This feature is like:
cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1
means this livepatch_1 module is the 1st klp patch applied.

cat /sys/kernel/livepatch/livepatch_module/stack_order -> N
means this lviepatch_module is the Nth klp patch applied
to the system.

Suggested-by: Petr Mladek <pmladek@suse.com>
Suggested-by: Miroslav Benes <mbenes@suse.cz>
Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Wardenjohn <zhangwarden@gmail.com>

diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index ecbc9b6aba3a..914b7cabf8fe 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -346,6 +346,7 @@ int klp_apply_section_relocs(struct module *pmod, Elf_Shdr *sechdrs,
  * /sys/kernel/livepatch/<patch>/enabled
  * /sys/kernel/livepatch/<patch>/transition
  * /sys/kernel/livepatch/<patch>/force
+ * /sys/kernel/livepatch/<patch>/stack_order
  * /sys/kernel/livepatch/<patch>/<object>
  * /sys/kernel/livepatch/<patch>/<object>/patched
  * /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
@@ -443,13 +444,37 @@ static ssize_t force_store(struct kobject *kobj, struct kobj_attribute *attr,
 	return count;
 }
 
+static ssize_t stack_order_show(struct kobject *kobj,
+				struct kobj_attribute *attr, char *buf)
+{
+	struct klp_patch *patch, *this_patch;
+	int stack_order = 0;
+
+	this_patch = container_of(kobj, struct klp_patch, kobj);
+
+	/* make sure the calculate of patch order correct */
+	mutex_lock(&klp_mutex);
+
+	klp_for_each_patch(patch) {
+		stack_order++;
+		if (patch == this_patch)
+			break;
+	}
+
+	mutex_unlock(&klp_mutex);
+	return sysfs_emit(buf, "%d\n", stack_order);
+}
+
+
 static struct kobj_attribute enabled_kobj_attr = __ATTR_RW(enabled);
 static struct kobj_attribute transition_kobj_attr = __ATTR_RO(transition);
 static struct kobj_attribute force_kobj_attr = __ATTR_WO(force);
+static struct kobj_attribute stack_order_kobj_attr = __ATTR_RO(stack_order);
 static struct attribute *klp_patch_attrs[] = {
 	&enabled_kobj_attr.attr,
 	&transition_kobj_attr.attr,
 	&force_kobj_attr.attr,
+	&stack_order_kobj_attr.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(klp_patch);
-- 
2.18.2

Hi,

I would change the subject to something like

"livepatch: Add "stack_order" sysfs attribute"

to keep it somehow consistent with what we have there so far.

On Wed, 25 Sep 2024, Wardenjohn wrote:

> This feature can provide livepatch patch order information.
> With the order of sysfs interface of one klp_patch, we can
> use patch order to find out which function of the patch is
> now activate.
> 
> After the discussion, we decided that patch-level sysfs
> interface is the only accaptable way to introduce this
> information.
> 
> This feature is like:
> cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1
> means this livepatch_1 module is the 1st klp patch applied.
> 
> cat /sys/kernel/livepatch/livepatch_module/stack_order -> N
> means this lviepatch_module is the Nth klp patch applied
> to the system.

Perhaps something like

"
Add "stack_order" sysfs attribute which holds the order in which a live 
patch module was loaded into the system. A user can then determine an 
active live patched version of a function.

 cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1

 means that livepatch_1 is the first live patch applied

 cat /sys/kernel/livepatch/livepatch_module/stack_order -> N

 means that livepatch_module is the Nth live patch applied
"
?

> Suggested-by: Petr Mladek <pmladek@suse.com>
> Suggested-by: Miroslav Benes <mbenes@suse.cz>
> Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Wardenjohn <zhangwarden@gmail.com>
 
How do you prepare your patches?

"---" delimiter is missing here.

> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index ecbc9b6aba3a..914b7cabf8fe 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -346,6 +346,7 @@ int klp_apply_section_relocs(struct module *pmod, Elf_Shdr *sechdrs,
>   * /sys/kernel/livepatch/<patch>/enabled
>   * /sys/kernel/livepatch/<patch>/transition
>   * /sys/kernel/livepatch/<patch>/force
> + * /sys/kernel/livepatch/<patch>/stack_order
>   * /sys/kernel/livepatch/<patch>/<object>
>   * /sys/kernel/livepatch/<patch>/<object>/patched
>   * /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
> @@ -443,13 +444,37 @@ static ssize_t force_store(struct kobject *kobj, struct kobj_attribute *attr,
>  	return count;
>  }
>  
> +static ssize_t stack_order_show(struct kobject *kobj,
> +				struct kobj_attribute *attr, char *buf)
> +{
> +	struct klp_patch *patch, *this_patch;
> +	int stack_order = 0;
> +
> +	this_patch = container_of(kobj, struct klp_patch, kobj);
> +
> +	/* make sure the calculate of patch order correct */

The comment is not necessary.

> +	mutex_lock(&klp_mutex);
> +
> +	klp_for_each_patch(patch) {
> +		stack_order++;
> +		if (patch == this_patch)
> +			break;
> +	}
> +
> +	mutex_unlock(&klp_mutex);

Please add an empty line before return here.

>+       return sysfs_emit(buf, "%d\n", stack_order);
>+}

Miroslav

Hi, Miroslav!
> On Sep 27, 2024, at 22:11, Miroslav Benes <mbenes@suse.cz> wrote:
> 
> 
> How do you prepare your patches?
> 
> "---" delimiter is missing here.

I seem to found out what cause this problem.

I seemed to use 'git format-patch' with '-p' option which
will make my patch have no diff state.

Sorry for this. A newer version was sent again.
Please review the V3 patch.

Thank you!
Wardenjohn.

Hi, Miroslav!
> 
> Perhaps something like
> 
> "
> Add "stack_order" sysfs attribute which holds the order in which a live 
> patch module was loaded into the system. A user can then determine an 
> active live patched version of a function.
> 
> cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1
> 
> means that livepatch_1 is the first live patch applied
> 
> cat /sys/kernel/livepatch/livepatch_module/stack_order -> N
> 
> means that livepatch_module is the Nth live patch applied
> "
> ?
> 
>> Suggested-by: Petr Mladek <pmladek@suse.com>
>> Suggested-by: Miroslav Benes <mbenes@suse.cz>
>> Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
>> Signed-off-by: Wardenjohn <zhangwarden@gmail.com>
> 
> How do you prepare your patches?
> 
> "---" delimiter is missing here.

I will commit my changes with 'git commit -m' option.
Then, I use 'git format-patch' to generate my patches.
After my patches is ready, I would use 'git send-email' to 
send my directory containing my patches and cover letter.

Is there any step I missed?

> 
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index ecbc9b6aba3a..914b7cabf8fe 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
>> @@ -346,6 +346,7 @@ int klp_apply_section_relocs(struct module *pmod, Elf_Shdr *sechdrs,
>>  * /sys/kernel/livepatch/<patch>/enabled
>>  * /sys/kernel/livepatch/<patch>/transition
>>  * /sys/kernel/livepatch/<patch>/force
>> + * /sys/kernel/livepatch/<patch>/stack_order
>>  * /sys/kernel/livepatch/<patch>/<object>
>>  * /sys/kernel/livepatch/<patch>/<object>/patched
>>  * /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
>> @@ -443,13 +444,37 @@ static ssize_t force_store(struct kobject *kobj, struct kobj_attribute *attr,
>> return count;
>> }
>> 
>> +static ssize_t stack_order_show(struct kobject *kobj,
>> + struct kobj_attribute *attr, char *buf)
>> +{
>> + struct klp_patch *patch, *this_patch;
>> + int stack_order = 0;
>> +
>> + this_patch = container_of(kobj, struct klp_patch, kobj);
>> +
>> + /* make sure the calculate of patch order correct */
> 
> The comment is not necessary.
> 
>> + mutex_lock(&klp_mutex);
>> +
>> + klp_for_each_patch(patch) {
>> + stack_order++;
>> + if (patch == this_patch)
>> + break;
>> + }
>> +
>> + mutex_unlock(&klp_mutex);
> 
> Please add an empty line before return here.
> 
>> +       return sysfs_emit(buf, "%d\n", stack_order);
>> +}
> 
> Miroslav

And the rest of the suggestions will be fix in the next version.

Regards.
Wardenjohn.