[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4e3WC4UYtszfFBe@codewreck.org>
Date: Thu, 1 Dec 2022 05:04:40 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Naresh Kamboju <naresh.kamboju@...aro.org>
Cc: Marco Elver <elver@...gle.com>, rcu <rcu@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
kunit-dev@...glegroups.com, lkft-triage@...ts.linaro.org,
kasan-dev <kasan-dev@...glegroups.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Netdev <netdev@...r.kernel.org>,
Anders Roxell <anders.roxell@...aro.org>
Subject: Re: arm64: allmodconfig: BUG: KCSAN: data-race in p9_client_cb /
p9_client_rpc
Naresh Kamboju wrote on Wed, Nov 30, 2022 at 09:34:45PM +0530:
> > > [ 424.418214] write to 0xffff00000a753000 of 4 bytes by interrupt on cpu 0:
> > > [ 424.422437] p9_client_cb+0x84/0x100
> >
> > Then we can look at git blame of the lines and see if it's new code.
>
> True.
> Hope that tree and tag could help you get git details.
Even with the git tag, if we don't build for the same arch with the same
compiler version/options and the same .config we aren't likely to have
identical binaries, so we cannot make sense of these offsets without
much work.
As much as I'd like to investigate a data race in 9p (and geez that code
has been such a headache from syzbot already so I don't doubt there are
more), having line numbers is really not optional if we want to scale at
all.
If you still have the vmlinux binary from that build (or if you can
rebuild with the same options), running this text through addr2line
should not take you too long.
(You might need to build with at least CONFIG_DEBUG_INFO_REDUCED (or not
reduced), but that is on by default for aarch64)
--
Dominique
Powered by blists - more mailing lists