On Mon, Jul 22, 2019 at 11:00:10AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jul 2019 13:42:02 +0100
> Catalin Marinas wrote:
>
> > > I agree with Masami, that the selftest actually caught a bug here. I
> > > think the arch code may need to change as the purpose of Masami's
> > > changes was to
On Mon, 22 Jul 2019 13:42:02 +0100
Catalin Marinas wrote:
> > I agree with Masami, that the selftest actually caught a bug here. I
> > think the arch code may need to change as the purpose of Masami's
> > changes was to enable kprobes earlier in boot. The selftest failing
> > means that an early
Hi Steve,
On Tue, Jul 09, 2019 at 11:15:20AM -0400, Steven Rostedt wrote:
> On Wed, 3 Jul 2019 15:08:32 +0100
> Catalin Marinas wrote:
> > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > index 5471efbeb937..0ca6f53c8505 100644
> > > --- a/kernel/kprobes.c
> > > +++ b/kernel/kprobes.c
>
On Tue, Jul 09, 2019 at 09:30:49PM +0900, Masami Hiramatsu wrote:
> On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt
> wrote:
> > On Tue, 2 Jul 2019 17:50:09 +0100 Mark Rutland
> > wrote:
> > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > > > Signed-off-by: Masami
On Tue, 9 Jul 2019 21:51:24 +0900
Masami Hiramatsu wrote:
> > Masami,
> >
> > If you give me an Acked-by, I'll add it to my tree.
>
> Sorry for late reply, but I want to keep the test running right after
> initialization as the first user of kprobes at that timing, since
> other user can
On Wed, 3 Jul 2019 15:08:32 +0100
Catalin Marinas wrote:
> > -- Steve
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 5471efbeb937..0ca6f53c8505 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -2235,6 +2235,8 @@ static struct notifier_block
On Wed, 3 Jul 2019 10:25:04 -0400
Steven Rostedt wrote:
> On Wed, 3 Jul 2019 10:24:02 -0400
> Steven Rostedt wrote:
>
> > On Wed, 3 Jul 2019 15:08:32 +0100
> > Catalin Marinas wrote:
> >
> >
> > > > +static int __init run_init_test_probes(void)
> > > > +{
> > > > + if
Hi Steve,
On Wed, 3 Jul 2019 10:02:05 -0400
Steven Rostedt wrote:
> On Tue, 2 Jul 2019 17:50:09 +0100
> Mark Rutland wrote:
>
> > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > > From: Masami Hiramatsu
> > >
> > > Initialize kprobes at postcore_initcall level instead of
This would be the official patch:
From: "Steven Rostedt (VMware)"
Subject: [PATCH] kprobes: Run init_test_probes() later in boot up
It was reported that the moving of the kprobe initialization earlier in the
boot process caused arm64 to crash. This was due to arm64 depending on the
BRK handler
On Wed, 3 Jul 2019 10:24:02 -0400
Steven Rostedt wrote:
> On Wed, 3 Jul 2019 15:08:32 +0100
> Catalin Marinas wrote:
>
>
> > > +static int __init run_init_test_probes(void)
> > > +{
> > > + if (run_kprobe_tests)
> > > + init_test_probes();
> >
> > A return 0 here.
>
> Will
On Wed, 3 Jul 2019 15:08:32 +0100
Catalin Marinas wrote:
> > +static int __init run_init_test_probes(void)
> > +{
> > + if (run_kprobe_tests)
> > + init_test_probes();
>
> A return 0 here.
Will update (would have triggered a failure on my test suite anyway ;-)
>
> > +}
> >
On Wed, Jul 03, 2019 at 10:02:05AM -0400, Steven Rostedt wrote:
> > On arm64 kprobes depends on the BRK handler we register in
> > debug_traps_init(), which is an arch_initcall.
> >
> > As of this change, init_krprobes() calls init_test_probes() before
> > that's registered, so we end up hitting
On Tue, 2 Jul 2019 17:50:09 +0100
Mark Rutland wrote:
> On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > From: Masami Hiramatsu
> >
> > Initialize kprobes at postcore_initcall level instead of module_init
> > since kprobes is not a module, and it depends on only subsystems
>
On Tue, Jul 02, 2019 at 05:50:09PM +0100, Mark Rutland wrote:
> On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > From: Masami Hiramatsu
> >
> > Initialize kprobes at postcore_initcall level instead of module_init
> > since kprobes is not a module, and it depends on only
On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> From: Masami Hiramatsu
>
> Initialize kprobes at postcore_initcall level instead of module_init
> since kprobes is not a module, and it depends on only subsystems
> initialized in core_initcall.
> This will allow ftrace kprobe
From: Masami Hiramatsu
Initialize kprobes at postcore_initcall level instead of module_init
since kprobes is not a module, and it depends on only subsystems
initialized in core_initcall.
This will allow ftrace kprobe event to add new events when it is
initializing because ftrace kprobe event is
16 matches
Mail list logo
