All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: jpoimboe@redhat.com, jikos@kernel.org, joe.lawrence@redhat.com,
	peterz@infradead.org, linux-kernel@vger.kernel.org,
	live-patching@vger.kernel.org, shuah@kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 3/3] selftests/livepatch: Test of the API for specifying functions to search for on a stack
Date: Thu, 25 Nov 2021 15:39:29 +0100	[thread overview]
Message-ID: <YZ+gIa4dG2uPvSlY@alley> (raw)
In-Reply-To: <20211119090327.12811-4-mbenes@suse.cz>

On Fri 2021-11-19 10:03:27, Miroslav Benes wrote:
> Add a test for the API which allows the user to specify functions which
> are then searched for on any tasks's stack during a transition process.
> 
> --- /dev/null
> +++ b/lib/livepatch/test_klp_funcstack_mod.c
> @@ -0,0 +1,72 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2021 Miroslav Benes <mbenes@suse.cz>
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/debugfs.h>
> +#include <linux/delay.h>
> +
> +static int sleep_length = 10000;
> +module_param(sleep_length, int, 0644);
> +MODULE_PARM_DESC(sleep_length, "length of sleep in seconds (default=10)");
> +
> +static noinline void child_function(void)
> +{
> +	pr_info("%s enter\n", __func__);
> +	msleep(sleep_length);

The hardcoded sleep is not ideal. It might be too low or non-necessary high.

If I get it correctly, we are trying to achieve here the same as
busymod_work_func() in test_klp_callbacks_busy.c.

The approach with debugfs is an interesting trick. Though, I slightly
prefer using the scheduled work. The workqueue API looks less tricky
to me than sysfs/debugfs API. Also it does not block the module
in the init() callback[*]. But I might be biased.

Anyway, it might make sense to use the same trick in both situations.
It would make it easier to maintain the test modules.

[*] There is actually a race in the workqueue approach. The module
init() callback should wait until the work is really scheduled
and sleeping. It might be achieved by similar hand-shake like
with @block_transition variable. Or completion API might be
even more elegant.


> +	pr_info("%s exit\n", __func__);
> +}
> +
> +static noinline void child2_function(void)
> +{
> +	pr_info("%s\n", __func__);
> +}
> +
> +static noinline void parent_function(void)
> +{
> +	pr_info("%s enter\n", __func__);
> +	child_function();
> +	child2_function();

This would deserve some explanation what we try to simulate here
and how it is achieved. It is not easy for me even with the background
that I have freshly in my mind.

Also I think about more descriptive names ;-)

What about something like this (using workqueue work and completion):

/*
 * Simulate part of the caller code that is in another .elf section
 * and is reached via jump. It this was really the case then the stack
 * unwinder might not be able to detect that the process is sleeping
 * in the caller.
 */
static void simulate_jump_part(void)
{
	pr_info("%s enter\n", __func__);

	/* Stay in the jump part unless told to leave. */
	wait_for_completion(finish_jump);

	pr_info("%s exit\n", __func__);
}

/*
 * Simulate modified part of the caller code. It should never get
 * livepatched when the caller is sleeping in the just_part().
 */
static void simulate_modified_part(void)
{
	pr_info("%s\n", __func__);
}

static void test_not_on_stack_func_work(struct work_struct *work)
{
	pr_info("%s enter\n", __func__);

	/* Simulation ready */
	complete(work_started);

	simulate_jump_part();
	simulate_modified_part();

	pr_info("%s exit\n", __func__);
}

static int test_klp_no_on_stack_init(void)
{
	pr_info("%s\n", __func__);

	schedule_work(&work);
	wait_for_completion(&work_started);

	return 0;
}

static void test_not_on_stack_exit(void)
{
	complete(&finish_jump);
	flush_work(&work);
	pr_info("%s\n", __func__);
}

module_init(test_klp_not_on_stack_init);
module_exit(test_klp_not_on_stack_exit);

> +	pr_info("%s exit\n", __func__);
> +}
> +

Best Regards,
Petr

  reply	other threads:[~2021-11-25 14:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-19  9:03 [PATCH 0/3] livepatch: Allow user to specify functions to search for on a stack Miroslav Benes
2021-11-19  9:03 ` [PATCH 1/3] livepatch: Move the initialization of old_func to a new function Miroslav Benes
2021-11-19  9:03 ` [PATCH 2/3] livepatch: Allow user to specify functions to search for on a stack Miroslav Benes
2021-11-19 10:17   ` Peter Zijlstra
2021-11-19 18:20   ` Josh Poimboeuf
2021-11-22  7:57     ` Miroslav Benes
2021-11-22 15:53       ` Joe Lawrence
2021-11-25 10:07         ` Petr Mladek
2021-11-25 10:20           ` Miroslav Benes
2021-12-03 16:01             ` Petr Mladek
2021-11-19  9:03 ` [PATCH 3/3] selftests/livepatch: Test of the API for specifying " Miroslav Benes
2021-11-25 14:39   ` Petr Mladek [this message]
2021-11-26  9:20     ` Miroslav Benes
2021-11-26 14:06       ` Petr Mladek

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=YZ+gIa4dG2uPvSlY@alley \
    --to=pmladek@suse.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.org \
    /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.