On Mon, Aug 16, 2021 at 1:23 PM Song Liu <song@xxxxxxxxxx> wrote:
>
> On Fri, Aug 13, 2021 at 6:34 PM Xiao Ni <xni@xxxxxxxxxx> wrote:
> >
> > Hi Song
> >
> > It can improve the performance. It needs to add rcu lock when calling
> > rcu_dereference.
> > Now it has a bug. It doesn't use rcu lock to protect. In the second
> > loop, it doesn't need
> > to use rcu_dereference when getting rdev. So to resolve this bug, we can remove
> > rcu_dereference directly.
>
> In the second loop, we only use rdev and rrdev when bio and repl_bio
> exists. So we shouldn't trigger the "bug" in any cases, right?
Hi Song
Sorry for not describing this problem clearly. It triggers a warning like this:
[ 695.110751] =============================
[ 695.131439] WARNING: suspicious RCU usage
[ 695.151389] 4.18.0-319.el8.x86_64+debug #1 Not tainted
[ 695.174413] -----------------------------
[ 695.192603] drivers/md/raid10.c:1776 suspicious
rcu_dereference_check() usage!
[ 695.225107]
other info that might help us debug this:
[ 695.260940]
rcu_scheduler_active = 2, debug_locks = 1
[ 695.290157] no locks held by mkfs.xfs/10186.
>
> Please:
> 1) If you do think this is a bug, add a fix tag, so we can back port to stable.
> (while I still think it is not a real bug).
> 2) move struct md_rdev *rdev = rcu_dereference(conf->mirrors[disk].rdev); to
> under "if (r10_bio->devs[disk].bio)"; and the rrdev ... to "if
> (repl_bio)". And add
> a comment there so it is more clear in the code.
ok, I'll fix these two places.
Regards
Xiao
