[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190709213657.1447f508bd6b72495ec225d9@gmail.com>
Date: Tue, 9 Jul 2019 21:36:57 +0900
From: Masami Hiramatsu <masami.hiramatsu@...il.com>
To: Anders Roxell <anders.roxell@...aro.org>,
Steven Rostedt <rostedt@...dmis.org>
Cc: James Morse <james.morse@....com>,
"Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
David Miller <davem@...emloft.net>,
Masami Hiramatsu <mhiramat@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kprobes sanity test fails on next-20190708
On Tue, 9 Jul 2019 12:19:15 +0200
Anders Roxell <anders.roxell@...aro.org> wrote:
> On Mon, 8 Jul 2019 at 17:56, James Morse <james.morse@....com> 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/20190702165008.GC34718@lakrids.cambridge.arm.com
> >
> > It doesn't look like Steve's patch has percolated into next yet:
> > https://lore.kernel.org/lkml/20190703103715.32579c25@gandalf.local.home/
> >
> > 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/20190625191545.245259106@goodmis.org/
>
> 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
Powered by blists - more mailing lists