From: Marcos Paulo de Souza <mpdesouza@suse.de>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Marcos Paulo de Souza <mpdesouza@suse.com>,
live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org,
shuah@kernel.org, jpoimboe@redhat.com, mbenes@suse.cz,
pmladek@suse.com
Subject: Re: [PATCH v2 2/2] selftests: livepatch: Test livepatching a heavily called syscall
Date: Thu, 24 Nov 2022 10:05:45 -0300 [thread overview]
Message-ID: <20221124130545.2f7cpc5xkzqiybsw@daedalus> (raw)
In-Reply-To: <Ys2Li9ilYtpmJhN3@redhat.com>
On Tue, Jul 12, 2022 at 10:56:11AM -0400, Joe Lawrence wrote:
> On Thu, Jun 30, 2022 at 11:12:26AM -0300, Marcos Paulo de Souza wrote:
...
> nit: no need to init global to 0
>
> > +static int sig_int;
> > +
> > +void hup_handler(int signum)
> > +{
> > + stop = 1;
> > +}
> > +
> > +void int_handler(int signum)
> > +{
> > + stop = 1;
> > + sig_int = 1;
> > +}
> > +
> > +int main(int argc, char *argv[])
> > +{
> > + pid_t orig_pid, pid;
> > + long count = 0;
> > +
> > + signal(SIGHUP, &hup_handler);
> > + signal(SIGINT, &int_handler);
> > +
> > + orig_pid = syscall(SYS_getpid);
> > +
> > + while (!stop) {
> > + pid = syscall(SYS_getpid);
> > + if (pid != orig_pid)
> > + return 1;
>
> This test doesn't care about the user program return code, but I wonder
> if the status should be flipped -- this is the desired code path, not
> the one at the end of main(), right?
>
...
> > + */
> > + mutex_lock(&kpid_mutex);
> > + list_for_each_entry_safe(kpid, temp, &klp_pid_list, list) {
> > + if (current->pid == kpid->pid) {
> > + list_del(&kpid->list);
> > + kfree(kpid);
> > + npids--;
> > + break;
>
> I think it would be safer to return task_tgid_vnr() here, but ...
>
> > + }
> > + }
> > + mutex_unlock(&kpid_mutex);
> > +
> > + return task_tgid_vnr(current);
>
> task_pid_vnr() here. That way we're only changing behavior for the
> processes in the list and not all programs across the system.
I believe that these two suggestions can be linked per your answer. First of
all, I didn't write the original test program, but I agree that we can make it
better.
My intent by upstreaming the test was to ensure that test programs
would keep working even when livepatching getpid while having processes calling
getpid nonstop. For the purpose of the test, the test module livepatches getpid,
but keeping the same behavior as before. The only change is to keep track of the
test programs that need to transition to livepatched state.
Per your comment on the test program it seems that we expected to receive a
different value from getpid, but it's not the case here. I believe the chec on
test program is confusing and doesn't bring any benefit, so maybe it's better to
remove it and keep the test even simpler:
--- a/tools/testing/selftests/livepatch/test_programs/test_klp-call_getpid.c
+++ b/tools/testing/selftests/livepatch/test_programs/test_klp-call_getpid.c
@@ -26,18 +26,13 @@ void int_handler(int signum)
int main(int argc, char *argv[])
{
- pid_t orig_pid, pid;
long count = 0;
signal(SIGHUP, &hup_handler);
signal(SIGINT, &int_handler);
- orig_pid = syscall(SYS_getpid);
-
while (!stop) {
- pid = syscall(SYS_getpid);
- if (pid != orig_pid)
- return 1;
+ (void)syscall(SYS_getpid);
count++;
}
As as only care about the processes transitioning to the livepatched state, we
really don't care about the getpid return value (as it should be the same from patches
and unpatched state).
I believe this resolves both issues. What do you think?
next prev parent reply other threads:[~2022-11-24 13:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 14:12 [PATCH v2 0/2] livepatch: Move tests from lib/livepatch to selftests/livepatch Marcos Paulo de Souza
2022-06-30 14:12 ` [PATCH v2 1/2] " Marcos Paulo de Souza
2022-06-30 14:12 ` [PATCH v2 2/2] selftests: livepatch: Test livepatching a heavily called syscall Marcos Paulo de Souza
2022-07-12 14:56 ` Joe Lawrence
2022-07-29 13:19 ` Petr Mladek
2022-11-23 13:35 ` Marcos Paulo de Souza
2022-11-24 3:39 ` Marcos Paulo de Souza
2022-11-24 13:05 ` Marcos Paulo de Souza [this message]
2022-11-30 22:19 ` Joe Lawrence
2022-06-30 14:36 ` [PATCH v2 0/2] livepatch: Move tests from lib/livepatch to selftests/livepatch Shuah Khan
2022-07-01 7:48 ` Miroslav Benes
2022-07-01 22:13 ` Shuah Khan
2022-07-15 14:45 ` Petr Mladek
2022-11-30 22:22 ` Joe Lawrence
2022-12-01 23:58 ` Shuah Khan
2022-12-02 7:33 ` Miroslav Benes
2022-12-02 20:17 ` Shuah Khan
2022-12-02 9:25 ` Petr Mladek
2022-12-02 20:03 ` Shuah Khan
2022-12-02 21:05 ` Joe Lawrence
2022-12-05 17:30 ` Marcos Paulo de Souza
2022-12-05 17:40 ` Marcos Paulo de Souza
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=20221124130545.2f7cpc5xkzqiybsw@daedalus \
--to=mpdesouza@suse.de \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mpdesouza@suse.com \
--cc=pmladek@suse.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox