/19f1bc3fb55452739dd3d56cfd06c29ecdbe3e9f
Thanks, and sorry for late reply, but I don't have any objection.
>
> cheers
--
Masami Hiramatsu (Google)
On Wed, 17 Jul 2024 13:58:35 +1000
Michael Ellerman wrote:
> Masami Hiramatsu (Google) writes:
> > Hi Naveen,
> >
> > On Sun, 14 Jul 2024 14:04:23 +0530
> > Naveen N Rao wrote:
> >
> >> I have switched to using my @kernel.org id for my contributio
Hi Naveen,
On Sun, 14 Jul 2024 14:04:23 +0530
Naveen N Rao wrote:
> I have switched to using my @kernel.org id for my contributions. Update
> MAINTAINERS and mailmap to reflect the same.
>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
Would powerpc maintainer pick this
Add them as maintainers for the powerpc BPF JIT.
> >
> > I am no longer actively looking into the powerpc BPF JIT. Change my role
> > to that of a reviewer so that I can help with the odd query.
> >
> > Signed-off-by: Naveen N Rao
>
> Acked-by: Hari Bathin
1]. So please comment it and add that
[1]
https://lore.kernel.org/all/172000134410.63468.1374887213469474.stgit@devnote2/
Thank you,
>
>
> Thanks,
> Naveen
--
Masami Hiramatsu (Google)
from fprobe too (at this moment).
If you want to make it relays on kprobes, you have to make a dependency
in powerpc's kconfig, e.g.
select HAVE_RETHOOK if KPROBES
But I don't recommend it.
Thank you,
--
Masami Hiramatsu (Google)
> > +}
> > +NOKPROBE_SYMBOL(arch_rethook_prepare);
> > +
> > +static struct kprobe trampoline_p = {
> > + .addr = (kprobe_opcode_t *) &arch_rethook_trampoline,
> > + .pre_handler = trampoline_rethook_handler
> > +};
> > +
> > +/* rethook initializer */
> > +int arch_init_kprobes(void)
>
> Needs __init annotation.
>
> > +{
> > + return register_kprobe(&trampoline_p);
> > +}
> > diff --git a/arch/powerpc/kernel/stacktrace.c
> > b/arch/powerpc/kernel/stacktrace.c
> > index e6a958a5da27..a31648b45956 100644
> > --- a/arch/powerpc/kernel/stacktrace.c
> > +++ b/arch/powerpc/kernel/stacktrace.c
> > @@ -21,6 +21,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -133,14 +134,15 @@ int __no_sanitize_address
> > arch_stack_walk_reliable(stack_trace_consume_fn consum
> > * arch-dependent code, they are generic.
> > */
> > ip = ftrace_graph_ret_addr(task, &graph_idx, ip, stack);
> > -#ifdef CONFIG_KPROBES
> > +
> > /*
> > * Mark stacktraces with kretprobed functions on them
> > * as unreliable.
> > */
> > - if (ip == (unsigned long)__kretprobe_trampoline)
> > - return -EINVAL;
> > -#endif
> > + #ifdef CONFIG_RETHOOK
>
> The #ifdef usually starts at column 0, and there is no need to indent
> the below code.
>
> - Naveen
>
> > + if (ip == (unsigned long)arch_rethook_trampoline)
> > + return -EINVAL;
> > + #endif
> >
> > if (!consume_entry(cookie, ip))
> > return -EINVAL;
> > --
> > 2.44.0
> >
--
Masami Hiramatsu (Google)
ent arch_* and trampoline code */
> void arch_rethook_prepare(struct rethook_node *node, struct pt_regs *regs,
> bool mcount);
> void arch_rethook_trampoline(void);
> --
> 2.44.0
>
Thank you,
--
Masami Hiramatsu (Google)
On Wed, 15 May 2024 15:18:08 -0700
Stephen Brennan wrote:
> Masami Hiramatsu (Google) writes:
> > On Thu, 2 May 2024 01:35:16 +0800
> > Guo Ren wrote:
> >
> >> On Thu, May 2, 2024 at 12:30 AM Stephen Brennan
> >> wrote:
> >> >
> >>
ecture does
> not implement execmem_arch_setup(), execmem_alloc() will fall back to
> module_alloc().
>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
Thanks,
> Signed-off-by: Mike Rapoport (IBM)
> Acked-by: Song Liu
> ---
> arch/loongarch/kernel/module.c |
On Sun, 5 May 2024 19:06:17 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Move the logic related to the memory allocation and freeing into
> module_memory_alloc() and module_memory_free().
>
Looks good to me.
Reviewed-by: Masami Hiramatsu (Google)
b/kernel/kprobes.c
> > @@ -1068,6 +1068,7 @@ static struct ftrace_ops kprobe_ipmodify_ops
> > __read_mostly = {
> >
> > static int kprobe_ipmodify_enabled;
> > static int kprobe_ftrace_enabled;
> > +bool kprobe_ftrace_disabled;
> >
> > static int __arm_kprobe_ftrace(struct kprobe *p, struct ftrace_ops *ops,
> >int *cnt)
> > @@ -1136,6 +1137,11 @@ static int disarm_kprobe_ftrace(struct kprobe *p)
> > ipmodify ? &kprobe_ipmodify_ops : &kprobe_ftrace_ops,
> > ipmodify ? &kprobe_ipmodify_enabled :
> > &kprobe_ftrace_enabled);
> > }
> > +
> > +void kprobe_ftrace_kill()
> > +{
> > + kprobe_ftrace_disabled = true;
> > +}
> > #else /* !CONFIG_KPROBES_ON_FTRACE */
> > static inline int arm_kprobe_ftrace(struct kprobe *p)
> > {
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index da1710499698..96db99c347b3 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -7895,6 +7895,7 @@ void ftrace_kill(void)
> > ftrace_disabled = 1;
> > ftrace_enabled = 0;
> > ftrace_trace_function = ftrace_stub;
> > + kprobe_ftrace_kill();
> > }
> >
> > /**
> > --
> > 2.39.3
> >
>
>
> --
> Best Regards
> Guo Ren
--
Masami Hiramatsu (Google)
erating,
> rather than leave a ticking time bomb.
OK, the patch looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thanks!
>
> Signed-off-by: Stephen Brennan
> ---
>
> Apologies for the wide net cast here. I recognize that a change like this
> may need to be split up a
n non-modular kernels.
>
> Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
> modules, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the
> dependency of CONFIG_KPROBES on CONFIG_MODULES.
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thank y
tate != MODULE_STATE_COMING) {
> ...
> }
>
> so moving out 'enum module_state' won't be enough.
Hmm, this part should be inline functions like;
#ifdef CONFIG_MODULES
static inline bool module_is_coming(struct module *mod)
{
return mod->state == MODULE_STATE_COMING;
}
#else
#define module_is_coming(mod) (false)
#endif
Then we don't need the enum.
Thank you,
>
> > >
> > >> --
> > >> Masami Hiramatsu
> > >
>
> --
> Sincerely yours,
> Mike.
>
--
Masami Hiramatsu (Google)
module_alloc().
However, if an architecture only supports breakpoint/trap based kprobe,
it does not need to consider whether the execmem is allocated.
>
> We can always share large ROX pages as long as they are within the correct
> address space. The permissions for them are ROX and the alignment
> differences are due to KASAN and this is handled during allocation of the
> large page to refill the cache. __execmem_cache_alloc() only needs to limit
> the search for the address space of the range.
So I don't think EXECMEM_KPROBE always same as EXECMEM_MODULE_TEXT, it
should be configured for each arch. Especially, if it is only used for
searching parameter, it looks OK to me.
Thank you,
>
> And regardless, they way we deal with sharing of the cache can be sorted
> out later.
>
> > Thanks,
> > Song
>
> --
> Sincerely yours,
> Mike.
>
--
Masami Hiramatsu (Google)
l be used to identify the calling subsystem and to
> allow architectures define parameters for ranges suitable for that
> subsystem.
>
This looks good to me for the kprobe part.
Acked-by: Masami Hiramatsu (Google)
Thank you,
> Signed-off-by: Mike Rapoport (IBM)
> ---
> arc
is traced by ftrace or not.
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thanks,
> Signed-off-by: Naveen N Rao
> ---
> arch/powerpc/kernel/kprobes.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kpro
h so it is visible to all
> the definitions.
Thanks, let me pick this to linux-trace tree.
>
> Acked-by: Masami Hiramatsu (Google)
> Signed-off-by: Arnd Bergmann
> ---
> arch/arc/include/asm/kprobes.h | 3 ---
> arch/arm/include/asm/kprobes.h | 2 --
> arch/arm64/inclu
is visible to all
> the definitions.
Good catch! and it seems x86 has no implementation, so this is more resonable.
Acked-by: Masami Hiramatsu (Google)
Thank you,
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arc/include/asm/kprobes.h | 3 ---
> arch/arm/include/asm/k
if (!in_nmi())
> - trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_disable)(CALLER_ADDR0, CALLER_ADDR1);
> }
> }
> EXPORT_SYMBOL(trace_hardirqs_off);
>
>
--
Masami Hiramatsu (Google)
On Thu, 24 Nov 2022 17:14:27 +0530
"Naveen N. Rao" wrote:
> Jinyang He wrote:
> > 在 2022/11/17 21:09, Masami Hiramatsu (Google) 写道:
> >
> >> On Thu, 17 Nov 2022 09:07:37 +0800
> >> Tiezhu Yang wrote:
> >>
> >>> Hi KPROBES maint
ux-modu...@vger.kernel.org"
>
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev"
On Sun, 12 Jun 2022 15:59:29 +
Christophe Leroy wrote:
>
>
> Le 12/06/2022 à 14:18, Masami Hiramatsu (Google) a écrit :
> &
for other instructions.
Why I'm using module_alloc() for a generic function, is that
can cover the limitation most widely.
Thus, if we have CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE flag and
kprobes can check it instead of using __weak function, the
kprobes may not need to depend on module_alloc() in general.
Thank you,
>
> Thanks,
> Song
>
> >
> > This is why arm64, for instance, does not implement alloc_insn_page()
> > in terms of module_alloc() [and likely does not belong in this patch
> > for that reason]
>
>
>
> >
> > Is there any reason kprobes cannot simply use vmalloc()?
> >
--
Masami Hiramatsu (Google)
t; > > > me.
> > > > If module support maintainers think this name is not good, you may be
> > > > able to rename it as text_alloc() and make the module_alloc() as a
> > > > wrapper of it.
> > >
> > > IIUC, most users of module_alloc() use it to allocate memory for text,
> > > except
> > > that module code uses it for both text and data. Therefore, I guess
> > > calling it
> > > text_alloc() is not 100% accurate until we change the module code (to use
> > > a different API to allocate memory for data).
> >
> > After reading the feedback, I'd stay on using module_alloc() because
> > it has arch-specific quirks baked in. Easier to deal with them in one
> > place.
> >
>
> In that case, please ensure that you enable this only on architectures
> where it is needed. arm64 implements alloc_insn_page() without relying
> on module_alloc() so I would not expect to see any changes there.
Hmm, what about adding CONFIG_ARCH_HAVE_ALLOC_INSN_PAGE and check it?
If it is defined, kprobes will not define the __weak function, but
if not, it will use module_alloc()?
Thank you,
--
Masami Hiramatsu (Google)
cator.
>
> Few years ago I carved up something "half-way there" for kprobes,
> and I used the name text_alloc() [*].
>
> [*]
> https://lore.kernel.org/all/20200724050553.1724168-1-jarkko.sakki...@linux.intel.com/
>
Yeah, I remember that. Thank you for updating your
Reword and clarify better about the rwsem non-owner release issue.
Link: https://lore.kernel.org/linux-pci/20200321212144.ga6...@google.com/
Signed-off-by: Joel Fernandes (Google)
---
Documentation/locking/locktypes.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
check" indicating sparse checking.
Signed-off-by: Joel Fernandes (Google)
---
Previous discussion is here:
https://lore.kernel.org/linuxppc-dev/20190528200014.gv28...@linux.ibm.com/T/
Documentation/RCU/Design/Requirements/Requirements.html | 2 +-
arch/powerpc/include/asm/kvm_book3s_64.h
The series removes all users of the API and with this patch, the API
itself. Also fix documentation.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/Design/Requirements/Requirements.html | 6 +++---
include/linux/rcupdate.h| 9 -
2 files
The series removes all users of the API and with this patch, the API
itself.
Signed-off-by: Joel Fernandes (Google)
---
.clang-format | 1 -
include/linux/rculist.h | 20
2 files changed, 21 deletions(-)
diff --git a/.clang-format b/.clang-format
index
hlist_for_each_entry_rcu already does not do any tracing. This series
removes the notrace variant of it, so let us just use the regular API.
In a future patch, we can also remove the
hash_for_each_possible_rcu_notrace API that this patch touches.
Signed-off-by: Joel Fernandes (Google
rcu_dereference_raw_notrace API) with hlist_for_each_entry_rcu which
also does not do any tracing.
Signed-off-by: Joel Fernandes (Google)
---
kernel/trace/ftrace.c | 4 ++--
kernel/trace/ftrace_internal.h | 8
kernel/trace/trace.c | 4 ++--
3 files changed, 8 insertions(+), 8
The series removes users of the following APIs, and the APIs themselves, since
the regular non - _notrace variants don't do any tracing anyway.
* hlist_for_each_entry_rcu_notrace
* rcu_dereference_raw_notrace
Joel Fernandes (Google) (5):
powerpc: Use regular rcu_dereference_raw API
trace
rcu_dereference_raw already does not do any tracing. There is no need to
use the _notrace variant of it and this series removes that API, so let us
use the regular variant here.
Signed-off-by: Joel Fernandes (Google)
---
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
1 file changed, 1
Moving page-tables at the PMD-level on x86 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1a0be022f91d
Moving page-tables at the PMD-level on arm64 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Signed-off-by: Joel Fernandes (Google)
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index
4 and arm64.
Cc: minc...@kernel.org
Cc: pan...@google.com
Cc: hu...@google.com
Cc: lokeshgi...@google.com
Cc: dan...@google.com
Cc: mho...@kernel.org
Cc: kir...@shutemov.name
Cc: a...@linux-foundation.org
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google)
---
arch/Kconfig | 5 +++
e
+ #define fn(a, b) e
|
- #define fn(a, b) e
+ #define fn(a) e
)
Suggested-by: Kirill A. Shutemov
Cc: Kirill A. Shutemov
Cc: Michal Hocko
Cc: Julia Lawall
Signed-off-by: Joel Fernandes (Google)
---
arch/alpha/include/asm/pgalloc.h | 6 +++---
arch/arc/include/asm/pgalloc.h
v1 (Anton Ivanov)
update changelog with manual fixups for m68k and microblaze.
Joel Fernandes (Google) (4):
treewide: remove unused address argument from pte_alloc functions (v2)
mm: speed up mremap by 500x on large regions (v2)
arm64: select HAVE_MOVE_PMD for faster mremap (v
4 and arm64.
Cc: minc...@kernel.org
Cc: pan...@google.com
Cc: hu...@google.com
Cc: lokeshgi...@google.com
Cc: dan...@google.com
Cc: mho...@kernel.org
Cc: kir...@shutemov.name
Cc: a...@linux-foundation.org
Signed-off-by: Joel Fernandes (Google)
---
mm/mremap.c
e
|
- #define fn(a, b)@p e
+ #define fn(a) e
)
Suggested-by: Kirill A. Shutemov
Cc: Michal Hocko
Cc: Julia Lawall
Cc: elfr...@users.sourceforge.net
Signed-off-by: Joel Fernandes (Google)
---
arch/alpha/include/asm/pgalloc.h | 6 +++---
arch/arc/include/asm/pgalloc.h
41 matches
Mail list logo
