e for these parameters, since these args
> are not part of dwarf with offset "42131fa". Hence value will be
> null. This incorrect args results in segfault when value field is
> accessed.
>
> Save the dwarf dieoffset of the actual DW_TAG_subprogram as part of
> "str
randomly chosen number
> to some other randomly chosen number will not fix the problem (but you
> can postpone having to deal with it, sure!)
Yeah, sorry about the test case. Actually `+8` is also not a good number
for x86 too since we are not sure whether the address is an instruction
boundary or not. In that case it may report another error and failed.
Thank you,
>
>
> Segher
--
Masami Hiramatsu (Google)
On Mon, 4 Nov 2024 15:02:12 +0530
Hari Bathini wrote:
>
>
> On 03/11/24 10:27 am, Masami Hiramatsu (Google) wrote:
> > On Sat, 2 Nov 2024 00:49:25 +0530
> > Hari Bathini wrote:
> >
> >> For ppc64le, depending on the kernel configuration used, offset 16
# NO_BTFARG
> check_error 'p kfree ^$arg10' # NO_BTFARG (exceed the
> number of parameters)
> check_error 'r kfree ^$retval' # NO_RETVAL
> --
> 2.47.0
>
--
Masami Hiramatsu (Google)
is looks good to me.
Acked-by: Masami Hiramatsu (Google)
For x86 and generic part.
Thank you,
> Acked-by: Catalin Marinas
> Signed-off-by: Steven Rostedt (Google)
> ---
> Changes since v1:
> https://lore.kernel.org/20241007204743.41314...@gandalf.local.home
>
> - Moved
ll also make it easier to add new accessor functions to
> ftrace_regs as it will mean having to touch less architectures.
>
> Suggested-by: Masami Hiramatsu (Google)
> Signed-off-by: Steven Rostedt (Google)
> ---
> arch/arm64/include/asm/ftrace.h | 1 +
> arch/loongarch/
s no #endif for CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS.
I wonder how it passed the build. (#ifdef block does not affect over
the file boundary?
Thank you,
--
Masami Hiramatsu (Google)
/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
48 matches
Mail list logo
