Hi,
argh... resending, with plaintext... Sorry =/
I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
CONFIG_KPROBES_SANITY_TEST=y
I get the following Call trace, any ideas?
I've tried tags back to next-20190525 and they also failes... I haven't
found a commit that works yet.
[ 0.098694] Kprobe smoke test: started
[ 0.102001] audit: type=2000 audit(0.088:1): state=initialized
audit_enabled=0 res=1
[ 0.104753] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
[ 0.106845] Modules linked in:
[ 0.107897] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.2.0-next-20190708 #1
[ 0.110403] Hardware name: linux,dummy-virt (DT)
[ 0.112104] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 0.113852] pc : kprobe_target+0x0/0x18
[ 0.115268] lr : init_test_probes+0x1ac/0x3a0
[ 0.116890] sp : ffff00001000bd40
[ 0.118122] x29: ffff00001000bd40 x28: 0000000000000000
[ 0.120049] x27: 0000000000000000 x26: ffff000011190518
[ 0.122029] x25: ffff00001117e7d8 x24: ffff000011261078
[ 0.123977] x23: 0000000000000000 x22: ffff00001169bb70
[ 0.125930] x21: ffff00001186c000 x20: ffff0000116796c8
[ 0.127886] x19: ffff00001186cf10 x18: 0000000000000010
[ 0.129836] x17: 0000000000000000 x16: ffff80007b078000
[ 0.131829] x15: ffffffffffffffff x14: ffff0000116796c8
[ 0.133759] x13: 0000000000000000 x12: 0000000000000000
[ 0.135736] x11: 0000000000000000 x10: 0000000000000990
[ 0.137693] x9 : ffff00001000ba10 x8 : ffff80007b0789f0
[ 0.139659] x7 : ffff80007dbe1dc0 x6 : ffff80007dbe1d40
[ 0.141615] x5 : 0000000000000237 x4 : 00000000000021f2
[ 0.143599] x3 : ffff00001169bfb8 x2 : 0000000000000000
[ 0.145582] x1 : ffff000010184e40 x0 : 0000000040a0d76d
[ 0.147556] Call trace:
[ 0.148459] kprobe_target+0x0/0x18
[ 0.149754] init_kprobes+0x120/0x134
[ 0.151103] do_one_initcall+0x74/0x1b0
[ 0.152511] kernel_init_freeable+0x194/0x22c
[ 0.154133] kernel_init+0x10/0x100
[ 0.155411] ret_from_fork+0x10/0x1c
[ 0.156717] Code: a8c97bfd d65f03c0 d4210000 97fd5cdd (d4200080)
[ 0.158949] ---[ end trace 823556350f0e2d55 ]---
[ 0.160681] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 0.163247] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0000000b ]---
Cheers,
Anders
Hi,
On 08/07/2019 15:11, Anders Roxell wrote:
> argh... resending, with plaintext... Sorry =/
>
> I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
> CONFIG_KPROBES_SANITY_TEST=y
>
> I get the following Call trace, any ideas?
> I've tried tags back to next-20190525 and they also failes... I haven't
> found a commit that works yet.
>
> [ 0.098694] Kprobe smoke test: started
> [ 0.102001] audit: type=2000 audit(0.088:1): state=initialized
> audit_enabled=0 res=1
> [ 0.104753] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
This sounds like the issue Mark reported:
https://lore.kernel.org/r/[email protected]
It doesn't look like Steve's patch has percolated into next yet:
https://lore.kernel.org/lkml/[email protected]/
Could you give that a try to see if this is a new issue?
Thanks,
James
On Mon, 8 Jul 2019 at 17:56, James Morse <[email protected]> wrote:
>
> Hi,
>
> On 08/07/2019 15:11, Anders Roxell wrote:
> > argh... resending, with plaintext... Sorry =/
> >
> > I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
> > CONFIG_KPROBES_SANITY_TEST=y
> >
> > I get the following Call trace, any ideas?
> > I've tried tags back to next-20190525 and they also failes... I haven't
> > found a commit that works yet.
> >
> > [ 0.098694] Kprobe smoke test: started
> > [ 0.102001] audit: type=2000 audit(0.088:1): state=initialized
> > audit_enabled=0 res=1
> > [ 0.104753] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
>
> This sounds like the issue Mark reported:
> https://lore.kernel.org/r/[email protected]
>
> It doesn't look like Steve's patch has percolated into next yet:
> https://lore.kernel.org/lkml/[email protected]/
>
> Could you give that a try to see if this is a new issue?
The patch didn't apply cleanly.
However, when I resolved the issue it works.
I'm a bit embarrassed since I now remembered that I reported it a while back.
https://lore.kernel.org/lkml/[email protected]/
Both patches resolved the issue.
I've tested both.
Cheers,
Anders
On Tue, 9 Jul 2019 12:19:15 +0200
Anders Roxell <[email protected]> wrote:
> On Mon, 8 Jul 2019 at 17:56, James Morse <[email protected]> wrote:
> >
> > Hi,
> >
> > On 08/07/2019 15:11, Anders Roxell wrote:
> > > argh... resending, with plaintext... Sorry =/
> > >
> > > I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
> > > CONFIG_KPROBES_SANITY_TEST=y
> > >
> > > I get the following Call trace, any ideas?
> > > I've tried tags back to next-20190525 and they also failes... I haven't
> > > found a commit that works yet.
> > >
> > > [ 0.098694] Kprobe smoke test: started
> > > [ 0.102001] audit: type=2000 audit(0.088:1): state=initialized
> > > audit_enabled=0 res=1
> > > [ 0.104753] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
> >
> > This sounds like the issue Mark reported:
> > https://lore.kernel.org/r/[email protected]
> >
> > It doesn't look like Steve's patch has percolated into next yet:
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > Could you give that a try to see if this is a new issue?
>
> The patch didn't apply cleanly.
> However, when I resolved the issue it works.
> I'm a bit embarrassed since I now remembered that I reported it a while back.
> https://lore.kernel.org/lkml/[email protected]/
>
> Both patches resolved the issue.
> I've tested both.
In that case, the later one (move postcore to subsys) seems good to me.
Delaying the test is just avoiding the issue that the selftest found,
since right after init_kprobes() are called, the kprobe is ready for use.
This means that the selftest must be run as the first user of the kprobes
and it must be run right after initialize kprobes.
Thank you,
>
> Cheers,
> Anders
--
Masami Hiramatsu
On Tue, 9 Jul 2019 21:36:57 +0900
Masami Hiramatsu <[email protected]> wrote:
> On Tue, 9 Jul 2019 12:19:15 +0200
> Anders Roxell <[email protected]> wrote:
>
> > On Mon, 8 Jul 2019 at 17:56, James Morse <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > On 08/07/2019 15:11, Anders Roxell wrote:
> > > > argh... resending, with plaintext... Sorry =/
> > > >
> > > > I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
> > > > CONFIG_KPROBES_SANITY_TEST=y
> > > >
> > > > I get the following Call trace, any ideas?
> > > > I've tried tags back to next-20190525 and they also failes... I haven't
> > > > found a commit that works yet.
> > > >
> > > > [ 0.098694] Kprobe smoke test: started
> > > > [ 0.102001] audit: type=2000 audit(0.088:1): state=initialized
> > > > audit_enabled=0 res=1
> > > > [ 0.104753] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
> > >
> > > This sounds like the issue Mark reported:
> > > https://lore.kernel.org/r/[email protected]
> > >
> > > It doesn't look like Steve's patch has percolated into next yet:
> > > https://lore.kernel.org/lkml/[email protected]/
I forgot to push it after sending it. :-(
> > >
> > > Could you give that a try to see if this is a new issue?
> >
> > The patch didn't apply cleanly.
> > However, when I resolved the issue it works.
> > I'm a bit embarrassed since I now remembered that I reported it a while back.
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > Both patches resolved the issue.
> > I've tested both.
>
> In that case, the later one (move postcore to subsys) seems good to me.
>
> Delaying the test is just avoiding the issue that the selftest found,
> since right after init_kprobes() are called, the kprobe is ready for use.
> This means that the selftest must be run as the first user of the kprobes
> and it must be run right after initialize kprobes.
I agree. I pushed to my repo in the for-next branch. Care to test that?
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
-- Steve
On Tue, Jul 09, 2019 at 11:25:48AM -0400, Steven Rostedt wrote:
> On Tue, 9 Jul 2019 21:36:57 +0900
> Masami Hiramatsu <[email protected]> wrote:
>
> > On Tue, 9 Jul 2019 12:19:15 +0200
> > Anders Roxell <[email protected]> wrote:
> >
> > > On Mon, 8 Jul 2019 at 17:56, James Morse <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 08/07/2019 15:11, Anders Roxell wrote:
> > > > > argh... resending, with plaintext... Sorry =/
> > > > >
> > > > > I tried to build a next-201908 defconfig + CONFIG_KPROBES=y and
> > > > > CONFIG_KPROBES_SANITY_TEST=y
> > > > >
> > > > > I get the following Call trace, any ideas?
> > > > > I've tried tags back to next-20190525 and they also failes... I haven't
> > > > > found a commit that works yet.
> > > > >
> > > > > [ 0.098694] Kprobe smoke test: started
> > > > > [ 0.102001] audit: type=2000 audit(0.088:1): state=initialized
> > > > > audit_enabled=0 res=1
> > > > > [ 0.104753] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
> > > >
> > > > This sounds like the issue Mark reported:
> > > > https://lore.kernel.org/r/[email protected]
> > > >
> > > > It doesn't look like Steve's patch has percolated into next yet:
> > > > https://lore.kernel.org/lkml/[email protected]/
>
> I forgot to push it after sending it. :-(
>
> > > >
> > > > Could you give that a try to see if this is a new issue?
> > >
> > > The patch didn't apply cleanly.
> > > However, when I resolved the issue it works.
> > > I'm a bit embarrassed since I now remembered that I reported it a while back.
> > > https://lore.kernel.org/lkml/[email protected]/
> > >
> > > Both patches resolved the issue.
> > > I've tested both.
> >
> > In that case, the later one (move postcore to subsys) seems good to me.
> >
> > Delaying the test is just avoiding the issue that the selftest found,
> > since right after init_kprobes() are called, the kprobe is ready for use.
> > This means that the selftest must be run as the first user of the kprobes
> > and it must be run right after initialize kprobes.
>
> I agree. I pushed to my repo in the for-next branch. Care to test that?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
I've just given that a spin with KPROBES and KPROBES_SANITY_TEST
selected, and it boots cleanly for me. FWIW:
Tested-by: Mark Rutland <[email protected]>
Thanks,
Mark.
On Tue, 9 Jul 2019 16:37:55 +0100
Mark Rutland <[email protected]> wrote:
> > I agree. I pushed to my repo in the for-next branch. Care to test that?
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
>
> I've just given that a spin with KPROBES and KPROBES_SANITY_TEST
> selected, and it boots cleanly for me. FWIW:
>
> Tested-by: Mark Rutland <[email protected]>
Thanks, then I'm guessing no more changes need to be made.
I usually don't rebase my for-next branch for tags, but since I just
pushed it, I guess I can add this one ;-)
-- Steve
On Tue, 9 Jul 2019 11:40:45 -0400
Steven Rostedt <[email protected]> wrote:
> On Tue, 9 Jul 2019 16:37:55 +0100
> Mark Rutland <[email protected]> wrote:
>
> > > I agree. I pushed to my repo in the for-next branch. Care to test that?
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> >
> > I've just given that a spin with KPROBES and KPROBES_SANITY_TEST
> > selected, and it boots cleanly for me. FWIW:
> >
> > Tested-by: Mark Rutland <[email protected]>
>
> Thanks, then I'm guessing no more changes need to be made.
>
> I usually don't rebase my for-next branch for tags, but since I just
> pushed it, I guess I can add this one ;-)
Thanks Steve!
--
Masami Hiramatsu <[email protected]>