From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Ni Subject: Re: Unable to handle kernel NULL pointer dereference in super_written Date: Wed, 30 Mar 2016 03:44:53 -0400 (EDT) Message-ID: <2075551491.35783408.1459323893191.JavaMail.zimbra@redhat.com> References: <678678296.35099303.1459240762496.JavaMail.zimbra@redhat.com> <538658018.35237734.1459254120634.JavaMail.zimbra@redhat.com> <20160329213731.GA2287@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20160329213731.GA2287@kernel.org> Sender: linux-raid-owner@vger.kernel.org To: Shaohua Li Cc: linux-raid , Jes Sorensen , Neil Brown List-Id: linux-raid.ids ----- Original Message ----- > From: "Shaohua Li" > To: "Xiao Ni" > Cc: "linux-raid" , "Jes Sorensen" , "Neil Brown" > Sent: Wednesday, March 30, 2016 5:37:31 AM > Subject: Re: Unable to handle kernel NULL pointer dereference in supe= r_written >=20 > On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote: > > Hi all > >=20 > > I encountered one NULL pointer dereference problem. > >=20 > > The environment=EF=BC=9A > > latest linux-stable and mdadm codes > > aarch64 platform > > the md device is created with loop devices > >=20 > > It's a test case to check date integrity. I added the test script a= s the > > attachment. >=20 > Could you please try this patch: Thanks for the patch, I'm running test and will give the result. It nee= d to run=20 more than 300 iterations to reproduce this. >=20 >=20 > From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 200= 1 > Message-Id: > > From: Shaohua Li > Date: Tue, 29 Mar 2016 14:00:19 -0700 > Subject: [PATCH] MD: add rdev reference for super write >=20 > md_super_write() and corresponding md_super_wait() generally are call= ed > with reconfig_mutex locked, which prevents disk disappears. There is = one > case this rule is broken. write_sb_page of bitmap.c doesn't hold the > mutex. next_active_rdev does increase rdev reference, but it decrease= s > the reference too early (eg, before IO finish). disk can disappear at > the window. We unconditionally increase rdev reference in > md_super_write() to avoid the race. In the path hot_remove_disk, the write_sb_page is protected by reconfig= _mutex. It shouldn't submit bio to the leg which is already set FAULTY. Could y= ou give an example to show how the buy happen?=20 Best Regards Xiao >=20 > Reported-by: Xiao Ni > Cc: Neil Brown > Signed-off-by: Shaohua Li > --- > drivers/md/md.c | 3 +++ > 1 file changed, 3 insertions(+) >=20 > diff --git a/drivers/md/md.c b/drivers/md/md.c > index c068f17..bcfde333 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -718,6 +718,7 @@ static void super_written(struct bio *bio) > =20 > if (atomic_dec_and_test(&mddev->pending_writes)) > wake_up(&mddev->sb_wait); > + rdev_dec_pending(rdev, mddev); > bio_put(bio); > } > =20 > @@ -732,6 +733,8 @@ void md_super_write(struct mddev *mddev, struct m= d_rdev > *rdev, > */ > struct bio *bio =3D bio_alloc_mddev(GFP_NOIO, 1, mddev); > =20 > + atomic_inc(&rdev->nr_pending); > + > bio->bi_bdev =3D rdev->meta_bdev ? rdev->meta_bdev : rdev->bdev; > bio->bi_iter.bi_sector =3D sector; > bio_add_page(bio, page, size, 0); > -- > 2.8.0.rc2 >=20 > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid"= in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >=20 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html