From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: jikos@kernel.org, Joe Lawrence <joe.lawrence@redhat.com>,
jpoimboe@redhat.com, mingo@redhat.com,
Miroslav Benes <mbenes@suse.cz>,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org
Subject: Re: [PATCH 0/3] ftrace: Introduce PERMANENT ftrace_ops flag
Date: Thu, 10 Oct 2019 10:50:35 +0200 [thread overview]
Message-ID: <20191010085035.emsdks6xecazqc6k@pathway.suse.cz> (raw)
In-Reply-To: <20191009102654.501ad7c3@gandalf.local.home>
On Wed 2019-10-09 10:26:54, Steven Rostedt wrote:
> Petr Mladek <pmladek@suse.com> wrote:
> I think Joe's approach is much easier to understand and implement. The
> "ftrace_enabled" is a global flag, and affects all things ftrace (the
> function bindings). What this patch was doing, was what you said. Make
> ftrace_enabled only affect the ftrace_ops without the "PERMANENT" flag
> set. But that is complex and requires a bit more accounting in the
> ftrace system. Something I think we should try to avoid.
From my POV, the fact that livepatches make use of ftrace handlers
is just an implementation detail. Ideally, users should not know
about it. The livepatch handlers should be handled special way
and should not be affected by the ftrace sysfs interface.
And ideally, the ftrace sysfs interface should still be available
for other ftrace users.
I would understand if this would be too complicated and we would
need to find a compromise.
> What we are now proposing, is that if "ftrace_enabled" is not set, the
> register_ftrace_function() will fail if the ftrace_ops passed to it has
> the PERMANENT flag set (which would cause live patching to fail to
> load).
From the livepatch point of view it would be more reliable if
ftrace_ops with PERMANENT flag would force "ftrace_enabled"
to be always true.
It will make the flag unusable for other ftrace users. But it
will be already be the case when it can't be disabled.
Best Regards,
Petr
next prev parent reply other threads:[~2019-10-10 8:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-07 8:17 Miroslav Benes
2019-10-07 8:17 ` [PATCH 1/3] ftrace: Make test_rec_ops_needs_regs() generic Miroslav Benes
2019-10-07 8:17 ` [PATCH 2/3] ftrace: Introduce PERMANENT ftrace_ops flag Miroslav Benes
2019-10-07 8:17 ` [PATCH 3/3] livepatch: Use FTRACE_OPS_FL_PERMANENT Miroslav Benes
2019-10-08 19:35 ` [PATCH 0/3] ftrace: Introduce PERMANENT ftrace_ops flag Joe Lawrence
2019-10-08 19:50 ` Steven Rostedt
2019-10-09 10:33 ` Miroslav Benes
2019-10-09 11:22 ` Petr Mladek
2019-10-09 14:23 ` Joe Lawrence
2019-10-09 14:26 ` Steven Rostedt
2019-10-10 8:50 ` Petr Mladek [this message]
2019-10-10 13:14 ` Steven Rostedt
2019-10-10 13:38 ` Miroslav Benes
2019-10-10 13:43 ` Steven Rostedt
2019-10-10 13:44 ` Steven Rostedt
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=20191010085035.emsdks6xecazqc6k@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®