public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Alice Ferrazzi <alicef@alicef.me>,
	jeyu@kernel.org, jikos@kernel.org, mbenes@suse.cz,
	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 19:43:09 +0530	[thread overview]
Message-ID: <20190208141309.GA2215@JAVRIS.in.ibm.com> (raw)
In-Reply-To: <20190208093445.zvxkgaummsait5z6@pathway.suse.cz>

On Fri, Feb 08, 2019 at 10:34:45AM +0100, Petr Mladek wrote:
> On Fri 2019-02-08 11:50:05, 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.

[...]

> > 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?
> > 
> > The idea is to remove klp_have_reliable_stack() by moving
> > CONFIG_HAVE_RELIABLE_STACKTRACE as a config dependency to Kconfig
> > file
> 
> Looks like a nice cleanup.

Thanks

> 
> > 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:
> 
> Hmm, I see the following in kernel/trace/Kconfig:
> 
> config TRACING
> [...]
> 	select STACKTRACE if STACKTRACE_SUPPORT
> 
> It seems that the depency is not guaranted. Or do I miss anything?

I should have tried drawing the config dependency of CONFIG_STACKTRACE
in the mail.  It would saved me from nagivating wrong indirections in
tricky Kconfigs. You are right, CONFIG_STACKTRACE is not selected via
CONFIG_DYNAMIC_FTRACE_WITH_REGS config dependency chain.

> 
> Anyway, it is pretty indirect. I would prefer to add dependency
> on STACKTRACE explicitly into config LIVEPATCH.

Agree, explicitly listing CONFIG_STACKTRACE as one of the dependencies
under config LIVEPATCH will guarantee the dependency is met.  On the
curious note, digging through the git logs, CONFIG_STACKTRACE_SUPPORT
is enabled by default on x86/PowerPC for quite long now.

Thanks,
Kamalesh


      reply	other threads:[~2019-02-08 14:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 18:33 [PATCH v2] livepatch: core: Return EOPNOTSUPP instead of ENOSYS 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
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 [this message]

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=20190208141309.GA2215@JAVRIS.in.ibm.com \
    --to=kamalesh@linux.vnet.ibm.com \
    --cc=alice.ferrazzi@miraclelinux.com \
    --cc=alicef@alicef.me \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --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