Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 15 Feb 2022 21:56:59 +0530
From:   "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Subject: Re: [PATCH v2 09/13] powerpc/ftrace: Implement
 CONFIG_DYNAMIC_FTRACE_WITH_ARGS
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Christophe Leroy <christophe.leroy@csgroup.eu>,
        Jiri Kosina <jikos@kernel.org>,
        Joe Lawrence <joe.lawrence@redhat.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "live-patching@vger.kernel.org" <live-patching@vger.kernel.org>,
        Miroslav Benes <mbenes@suse.cz>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Petr Mladek <pmladek@suse.com>
References: <cover.1640017960.git.christophe.leroy@csgroup.eu>
        <5831f711a778fcd6eb51eb5898f1faae4378b35b.1640017960.git.christophe.leroy@csgroup.eu>
        <1644852011.qg7ud9elo2.naveen@linux.ibm.com>
        <1b28f52a-f8b7-6b5c-e726-feac4123517d@csgroup.eu>
        <875ypgo0f3.fsf@mpe.ellerman.id.au>
        <1644930705.g64na2kgvd.naveen@linux.ibm.com>
        <20220215093849.556d5444@gandalf.local.home>
In-Reply-To: <20220215093849.556d5444@gandalf.local.home>
MIME-Version: 1.0
User-Agent: astroid/4d6b06ad (https://github.com/astroidmail/astroid)
Message-Id: <1644942378.byz0qymic3.naveen@linux.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Steven Rostedt wrote:
> On Tue, 15 Feb 2022 19:06:48 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>=20
>> As I understand it, the reason ftrace_get_regs() was introduced was to=20
>> be able to only return the pt_regs, if _all_ registers were saved into=20
>> it, which we don't do when coming in through ftrace_caller(). See the=20
>> x86 implementation (commit 02a474ca266a47 ("ftrace/x86: Allow for=20
>> arguments to be passed in to ftrace_regs by default"), which returns=20
>> pt_regs conditionally.
>=20
> I can give you the history of ftrace_caller and ftrace_regs_caller.
>=20
> ftrace_caller saved just enough as was denoted for gcc mcount trampolines=
.
> The new fentry which happens at the start of the function, whereas mcount
> happens after the stack frame is set up, may change the rules on some
> architectures.
>=20
> As for ftrace_regs_caller, that was created for kprobes. As the majority =
of
> kprobes were added at the start of the function, it made sense to hook in=
to
> ftrace as the ftrace trampoline call is much faster than taking a
> breakpoint interrupt. But to keep compatibility with breakpoint
> interrupts, we needed to fill in all the registers, and make it act just
> like a breakpoint interrupt.
>=20
> I've been wanting to record function parameters, and because the ftrace
> trampoline must at a minimum save the function parameters before calling
> the ftrace callbacks, all the information for those parameters were being
> saved but were never exposed to the ftrace callbacks. I created the the
> DYNAMIC_FTRACE_WITH_ARGS to expose them. I first just used pt_regs with
> just the parameters filled in, but that was criticized as it could be
> confusing where the non filled in pt_regs might be used and thinking they
> are legitimate. So I created ftrace_regs that would give you just the
> function arguments (if DYNAMIC_FTRACE_WITH_ARGS is defined), or it will
> give you a full pt_regs, if the caller came from the ftrace_regs_caller. =
If
> not, it will give you a NULL pointer.
>=20
> The first user to use the args was live kernel patching, as they only nee=
d
> that and the return pointer.

Thanks, that helps.

- Naveen