From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 2/4] powerpc/ftrace: Refactor ftrace_{regs_}caller
Date: Wed, 09 Mar 2022 17:05:29 +0530 [thread overview]
Message-ID: <1646825481.p25t8oi12m.naveen@linux.ibm.com> (raw)
In-Reply-To: <5c0a3a26-ee52-a4f7-9bc2-b38f27a12a76@csgroup.eu>
Christophe Leroy wrote:
>
>
> Le 03/03/2022 à 17:59, Naveen N. Rao a écrit :
>> Christophe Leroy wrote:
>>
>> The ability to disable ftrace in certain code paths through
>> paca_struct->ftrace_enabled will also be relevant on ppc32 - it will be
>> nice if it can be introduced there.
>
> Ah ? I understood from commit ea678ac627e0 ("powerpc64/ftrace: Add a
> field in paca to disable ftrace in unsafe code paths") that it was for
> when it runs in real mode. PPC32 doesn't run any C code in real mode.
It likely isn't necessary in that case.
>
> Are there any other situations that real_mode where we'd like to disable
> it ? If so we could use the thread_struct as we don't have paca on PPC32.
For ppc64, we use this flag to disable certain paths in kvm, kexec,
mce/hmi and idle/hotplug. If none of those are problematic on ppc32,
then this isn't necessary.
Thanks,
- Naveen
WARNING: multiple messages have this Message-ID (diff)
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v1 2/4] powerpc/ftrace: Refactor ftrace_{regs_}caller
Date: Wed, 09 Mar 2022 17:05:29 +0530 [thread overview]
Message-ID: <1646825481.p25t8oi12m.naveen@linux.ibm.com> (raw)
In-Reply-To: <5c0a3a26-ee52-a4f7-9bc2-b38f27a12a76@csgroup.eu>
Christophe Leroy wrote:
>
>
> Le 03/03/2022 à 17:59, Naveen N. Rao a écrit :
>> Christophe Leroy wrote:
>>
>> The ability to disable ftrace in certain code paths through
>> paca_struct->ftrace_enabled will also be relevant on ppc32 - it will be
>> nice if it can be introduced there.
>
> Ah ? I understood from commit ea678ac627e0 ("powerpc64/ftrace: Add a
> field in paca to disable ftrace in unsafe code paths") that it was for
> when it runs in real mode. PPC32 doesn't run any C code in real mode.
It likely isn't necessary in that case.
>
> Are there any other situations that real_mode where we'd like to disable
> it ? If so we could use the thread_struct as we don't have paca on PPC32.
For ppc64, we use this flag to disable certain paths in kvm, kexec,
mce/hmi and idle/hotplug. If none of those are problematic on ppc32,
then this isn't necessary.
Thanks,
- Naveen
next prev parent reply other threads:[~2022-03-09 11:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 12:01 [PATCH v1 1/4] powerpc/ftrace: Don't use lmw/stmw in ftrace_regs_caller() Christophe Leroy
2022-02-17 12:01 ` Christophe Leroy
2022-02-17 12:01 ` [PATCH v1 2/4] powerpc/ftrace: Refactor ftrace_{regs_}caller Christophe Leroy
2022-02-17 12:01 ` Christophe Leroy
2022-03-03 16:59 ` Naveen N. Rao
2022-03-03 16:59 ` Naveen N. Rao
2022-03-03 17:39 ` Christophe Leroy
2022-03-03 17:39 ` Christophe Leroy
2022-03-09 11:35 ` Naveen N. Rao [this message]
2022-03-09 11:35 ` Naveen N. Rao
2022-02-17 12:01 ` [PATCH v1 3/4] powerpc/ftrace: Regroup PPC64 specific operations in ftrace_mprofile.S Christophe Leroy
2022-02-17 12:01 ` Christophe Leroy
2022-02-17 12:01 ` [PATCH v1 4/4] powerpc/ftrace: Use STK_GOT " Christophe Leroy
2022-02-17 12:01 ` Christophe Leroy
2022-03-08 12:08 ` [PATCH v1 1/4] powerpc/ftrace: Don't use lmw/stmw in ftrace_regs_caller() Michael Ellerman
2022-03-08 12:08 ` Michael Ellerman
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=1646825481.p25t8oi12m.naveen@linux.ibm.com \
--to=naveen.n.rao@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.