[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190603214105.715a4072472ef4946123dc20@kernel.org>
Date: Mon, 3 Jun 2019 21:41:05 +0900
From: Masami Hiramatsu <mhiramat@...nel.org>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Anders Roxell <anders.roxell@...aro.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
"Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
"David S . Miller" <davem@...emloft.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter
On Mon, 3 Jun 2019 20:52:38 +0900
Masami Hiramatsu <mhiramat@...nel.org> wrote:
> Hi Anders,
>
> Sorry for replying later.
>
> On Tue, 28 May 2019 15:39:15 +0200
> Anders Roxell <anders.roxell@...aro.org> wrote:
>
> > On Tue, 28 May 2019 at 14:36, Steven Rostedt <rostedt@...dmis.org> wrote:
> > >
> > > On Tue, 28 May 2019 14:23:43 +0200
> > > Anders Roxell <anders.roxell@...aro.org> wrote:
> > >
> > > > On Wed, 22 May 2019 at 10:32, Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > > > >
> > > > > Add kprobe_event= boot parameter to define kprobe events
> > > > > at boot time.
> > > > > The definition syntax is similar to tracefs/kprobe_events
> > > > > interface, but use ',' and ';' instead of ' ' and '\n'
> > > > > respectively. e.g.
> > > > >
> > > > > kprobe_event=p,vfs_read,$arg1,$arg2
> > > > >
> > > > > This puts a probe on vfs_read with argument1 and 2, and
> > > > > enable the new event.
> > > > >
> > > > > Signed-off-by: Masami Hiramatsu <mhiramat@...nel.org>
> > > >
> > > > I built an arm64 kernel from todays linux-next tag next-20190528 and
> > > > ran in to this issue when I booted it up in qemu:
>
> Thank you for reporting!
>
>
> > [ 9.020354][ T1] Kprobe smoke test: started
> > [ 9.064132][ T1] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
> > [ 9.067084][ T1] Modules linked in:
> > [ 9.068772][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > 5.2.0-rc2-next-20190528-00019-g9a6008710716 #8
> > [ 9.072893][ T1] Hardware name: linux,dummy-virt (DT)
> > [ 9.075143][ T1] pstate: 80400005 (Nzcv daif +PAN -UAO)
> > [ 9.077528][ T1] pc : kprobe_target+0x0/0x30
> > [ 9.079479][ T1] lr : init_test_probes+0x134/0x540
> > [ 9.081611][ T1] sp : ffff80003f51fbe0
> > [ 9.083331][ T1] x29: ffff80003f51fbe0 x28: ffff200013c17820
> > [ 9.085906][ T1] x27: ffff200015d3ab40 x26: ffff2000122bb120
> > [ 9.088491][ T1] x25: 0000000000000000 x24: ffff200013c08ae0
> > [ 9.091068][ T1] x23: ffff200015d39000 x22: ffff200013a15ac8
> > [ 9.093667][ T1] x21: 1ffff00007ea3f86 x20: ffff200015d39420
> > [ 9.096214][ T1] x19: ffff2000122bad20 x18: 0000000000001400
> > [ 9.098831][ T1] x17: 0000000000000000 x16: ffff80003f510040
> > [ 9.101410][ T1] x15: 0000000000001480 x14: 1ffff00007ea3ea2
> > [ 9.103963][ T1] x13: 00000000f1f1f1f1 x12: ffff040002782e0d
> > [ 9.106549][ T1] x11: 1fffe40002782e0c x10: ffff040002782e0c
> > [ 9.109120][ T1] x9 : 1fffe40002782e0c x8 : dfff200000000000
> > [ 9.111676][ T1] x7 : ffff040002782e0d x6 : ffff200013c17067
> > [ 9.114234][ T1] x5 : ffff80003f510040 x4 : 0000000000000000
> > [ 9.116843][ T1] x3 : ffff200010427508 x2 : 0000000000000000
> > [ 9.119409][ T1] x1 : ffff200010426e10 x0 : 0000000000a6326b
> > [ 9.121980][ T1] Call trace:
> > [ 9.123380][ T1] kprobe_target+0x0/0x30
> > [ 9.125205][ T1] init_kprobes+0x2b8/0x300
> > [ 9.127074][ T1] do_one_initcall+0x4c0/0xa68
> > [ 9.129076][ T1] kernel_init_freeable+0x3c4/0x4e4
> > [ 9.131234][ T1] kernel_init+0x14/0x1fc
> > [ 9.133032][ T1] ret_from_fork+0x10/0x18
> > [ 9.134908][ T1] Code: a9446bf9 f9402bfb a8d87bfd d65f03c0 (d4200080)
> > [ 9.137845][ T1] ---[ end trace 49243ee03446b072 ]---
> > [ 9.140114][ T1] Kernel panic - not syncing: Fatal exception
> > [ 9.142684][ T1] ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Ah, I think you hit this in [1/2], not this change.
>
> I guess arm64's breakpoint handler is not initialized at postcore_initcall().
> I have to check the arch depend implementation on arm64.
Yes, for some reason, arm64 breakpoint handler vector is initalized in arch_initcall().
Let's move init_kprobes to subsys_initcall, which is called before fs_initcall.
Thank you,
--
Masami Hiramatsu <mhiramat@...nel.org>
Powered by blists - more mailing lists