From: Miroslav Benes <mbenes@suse.cz>
To: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Petr Mladek <pmladek@suse.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Alice Ferrazzi <alicef@alicef.me>,
jeyu@kernel.org, jikos@kernel.org, live-patching@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alice Ferrazzi <alice.ferrazzi@miraclelinux.com>
Subject: Re: [PATCH v2] livepatch: core: Return EOPNOTSUPP instead of ENOSYS
Date: Fri, 8 Feb 2019 10:24:21 +0100 (CET) [thread overview]
Message-ID: <alpine.LSU.2.21.1902081013100.24868@pobox.suse.cz> (raw)
In-Reply-To: <20190208062005.GA21436@JAVRIS.in.ibm.com>
Hi Kamalesh,
On Fri, 8 Feb 2019, Kamalesh Babulal wrote:
> On Wed, Feb 06, 2019 at 11:28:32AM +0100, Petr Mladek wrote:
> > On Tue 2019-02-05 09:59:33, Josh Poimboeuf wrote:
> > > On Tue, Feb 05, 2019 at 03:33:28AM +0900, Alice Ferrazzi wrote:
> > > > From: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com>
> > > >
> > > > As a result of an unsupported operation is better to use EOPNOTSUPP
> > > > as error code.
> > > > ENOSYS is only used for 'invalid syscall nr' and nothing else.
> > > >
> > > > Signed-off-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com>
> > >
> > > Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
> >
> > I have applied the patch into for-5.1/atomic-replace branch.
>
> Sorry to jump into the discussion so late. Thinking a little more about
> the check itself, previously with immediate flag an architecture can do
> livepatching with limitations and without the reliable stack trace
> implemented yet.
>
> After removal of the immediate flag by
> commit d0807da78e11 ("livepatch: Remove immediate feature"), every
> architecture enabling livepatching is required to have implemented
> reliable stack trace. Is it a better idea to make
> HAVE_RELIABLE_STACKTRACE a config dependency, which will disable
> livepatching support for architectures without reliable stack trace
> function during kernel build?
if I am not mistaken, s390x is currently the only one which is supported
(the redirection works) but has no reliable stacktraces (so far, it is my
plan to take a look soon).
Theoretically, it could still work. We have the fake signal and we can
force the remaining tasks (kthreads). It is not something to be used in
production but it could make sense for a limited testing.
> The idea is to remove klp_have_reliable_stack() by moving
> CONFIG_HAVE_RELIABLE_STACKTRACE as a config dependency to Kconfig file
> and adding the other CONFIG_STACKTRACE as a config dependency is not
> required, as it's selected via CONFIG_DYNAMIC_FTRACE_WITH_REGS
> dependency chain. With the patch on architecture without
> HAVE_RELIABLE_STACKTRACE, the user should see:
>
> # insmod ./livepatch-sample.ko
> insmod: ERROR: could not insert module ./livepatch-sample.ko: Invalid module format
>
> # dmesg
> ...
> [ 286.453463] livepatch_sample: module is marked as livepatch module, but livepatch support is disabled
>
> I have done limited testing on PowerPC and to test the unsupported case,
> the config dependency HAVE_RELIABLE_STACKTRACE was misspelled in Kconfig
> file. If the idea sounds ok I will send a formal patch.
>
> -------8<----------------------------
>
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index 53551f470722..7848c7bbffbb 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -214,12 +214,6 @@ static inline bool klp_patch_pending(struct task_struct *task)
> return test_tsk_thread_flag(task, TIF_PATCH_PENDING);
> }
>
> -static inline bool klp_have_reliable_stack(void)
> -{
> - return IS_ENABLED(CONFIG_STACKTRACE) &&
> - IS_ENABLED(CONFIG_HAVE_RELIABLE_STACKTRACE);
> -}
> -
> typedef int (*klp_shadow_ctor_t)(void *obj,
> void *shadow_data,
> void *ctor_data);
> diff --git a/kernel/livepatch/Kconfig b/kernel/livepatch/Kconfig
> index ec4565122e65..16b3692ddf9f 100644
> --- a/kernel/livepatch/Kconfig
> +++ b/kernel/livepatch/Kconfig
> @@ -9,6 +9,7 @@ config LIVEPATCH
> depends on MODULES
> depends on SYSFS
> depends on KALLSYMS_ALL
> + depends on HAVE_RELIABLE_STACKTRACE
> depends on HAVE_LIVEPATCH
> depends on !TRIM_UNUSED_KSYMS
> help
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index fe1993399823..9a80f7574d75 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -1002,12 +1002,6 @@ int klp_enable_patch(struct klp_patch *patch)
> if (!klp_initialized())
> return -ENODEV;
>
> - if (!klp_have_reliable_stack()) {
> - pr_err("This architecture doesn't have support for the livepatch consistency model.\n");
> - return -ENOSYS;
> - }
> -
> -
> mutex_lock(&klp_mutex);
>
> ret = klp_init_patch_early(patch);
On the other hand, I like this change. So we have two options, I think.
We can apply this and wait if someone complains (because of s390x
testing), or we can wait for the full support of s390x and then enforce
it.
Thanks,
Miroslav
next prev parent reply other threads:[~2019-02-08 9:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 18:33 Alice Ferrazzi
2019-02-05 12:26 ` Petr Mladek
2019-02-05 13:05 ` Miroslav Benes
2019-02-05 15:59 ` Josh Poimboeuf
2019-02-06 10:28 ` Petr Mladek
2019-02-08 6:20 ` Kamalesh Babulal
2019-02-08 9:24 ` Miroslav Benes [this message]
2019-02-08 13:22 ` Kamalesh Babulal
2019-02-08 15:35 ` Miroslav Benes
2019-02-08 9:34 ` Petr Mladek
2019-02-08 14:13 ` Kamalesh Babulal
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=alpine.LSU.2.21.1902081013100.24868@pobox.suse.cz \
--to=mbenes@suse.cz \
--cc=alice.ferrazzi@miraclelinux.com \
--cc=alicef@alicef.me \
--cc=jeyu@kernel.org \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=pmladek@suse.com \
/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
all inboxes | Powered by JetHome®