From nobody Thu Sep 24 20:37:47 2026 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DA103B7B72; Mon, 21 Sep 2026 07:23:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789975426; cv=none; b=ssWdTWRiL4n8uw2jQUQq+fT2j5MhTpuOnfr6AqVUVWqM/ssgb7oFE9lJTNpD6DdD1kWtQoUYG9r7vJLkVZU38r96t/6J19BBifjAFER1f8LOmUzNCXm9Wso0gnH/YJUzc99pBDQ9BUk5f2ZSw33G/LRdCMWM6jLDpXbsYgmX6fg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789975426; c=relaxed/simple; bh=m/FcvP9JTRB7MSj1gfb0AyIu76xSDhcIvTkTDEh7nag=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qPlE7/x4PLlyAuAEPsJf9lPYNgC8PtaS4X2Cg6tMRenY8FzSX+QV37Pjbg/NndwsVlArTr8PZ6d3SdQcm6HROX0BG6iBqJGINuOUBeKIH4yDuHukf9pkQ8qVbZT0r6CU4OEHCMbR+hTlV4DjnbKedMks1WBiK5ASb96AcD3DePs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=cVDgg1pP; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="cVDgg1pP" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=GMeiLnjxKDXYCAdv/zIJZmZQqDB7+UsCszXD9zntC8k=; b=cVDgg1pPAyj1xw+zz99To8tIJMf6JiIPt3HBsmGbEw8y6CClXKFN+a0eRfcU7KZrGfTF7kKtj fqGBonkqUcA/AQ6tGPwqd3sG7X7tP5fOzH1tfLCNZx6IETFAPIkWJA+F7dJDDwQva9GLAuMGqy6 49BZcK056rT8a1LDk0au1oQ= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4hpDtM22n5zRhQs; Mon, 21 Sep 2026 15:11:39 +0800 (CST) Received: from whupemo200011.china.huawei.com (unknown [7.152.185.179]) by mail.maildlp.com (Postfix) with ESMTPS id E7B824057F; Mon, 21 Sep 2026 15:23:39 +0800 (CST) Received: from huawei.com (10.50.85.155) by whupemo200011.china.huawei.com (7.152.185.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 15:23:38 +0800 From: Zhihao Cheng To: , , CC: , , , , Subject: [PATCH 1/3] md/raid5: Hide the origin mddev->thread before takeover Date: Mon, 21 Sep 2026 15:15:34 +0800 Message-ID: <20260921071537.2902362-2-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260921071537.2902362-1-chengzhihao1@huawei.com> References: <20260921071537.2902362-1-chengzhihao1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To whupemo200011.china.huawei.com (7.152.185.179) Content-Type: text/plain; charset="utf-8" The raid5 takeover invokes setup_conf and allocates strip heads, but it wakes up the wrong thread, which lefts strip heads in the list 'conf->released_stripes' and not being processed. If raid5_run fails, the strip heads won't be released, which triggers the following slab warnings (CONFIG_SLUB_DEBUG): BUG raid5-md0 (Not tainted): Objects remaining on __kmem_cache_shutdown() Object 0x0000000062fad548 @offset=3D3968 Object 0x000000007f74683c @offset=3D4960 WARNING: mm/slub.c:1268 at __slab_err+0x31/0x40, CPU#0: bash/865 RIP: 0010:__slab_err+0x31 Call Trace: __kmem_cache_shutdown.cold+0x15b kmem_cache_destroy+0x71 free_conf+0xf8 raid5_run.cold+0x463 level_store+0x64e md_attr_store+0xd7 The detailed triggering process is as follows: mdadm --create /dev/md0 --level=3D1 --raid-devices=3D2 /dev/sda /dev/sdb --force --assume-clean # create raid1, mddev->thread is raid1d echo 5 > /sys/block/md0/md/level level_store raid5_takeover_raid1 setup_conf grow_stripes grow_one_stripe sh =3D alloc_stripe raid5_release_stripe md_wakeup_thread(conf->mddev->thread) // wakeup raid1d raid5_run ENOMEM =3D raid5_create_ctx_pool free_conf shrink_stripes drop_one_stripe // no strips found from the conf->inactive_list kmem_cache_destroy(conf->slab_cache) __kmem_cache_shutdown free_partial list_slab_objects // some entries are not released ! Fix it by hiding the origin mddev->thread before takeover, so that new allocating strip heads can be put into 'conf->inactive_list', which can be found by drop_one_stripe(). Fixes: 773ca82fa1ee ("raid5: make release_stripe lockless") Signed-off-by: Zhihao Cheng --- drivers/md/raid5.c | 37 ++++++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index c091bba95c31..7e87e8a60f5f 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -9039,19 +9039,38 @@ static void *raid5_takeover(struct mddev *mddev) * raid4 - trivial - just use a raid4 layout. * raid6 - Providing it is a *_6 layout */ - if (mddev->level =3D=3D 0) - return raid45_takeover_raid0(mddev, 5); - if (mddev->level =3D=3D 1) - return raid5_takeover_raid1(mddev); - if (mddev->level =3D=3D 4) { + void *ret =3D ERR_PTR(-EINVAL); + struct md_thread *thread; + + thread =3D rcu_dereference_protected(mddev->thread, + lockdep_is_held(&mddev->reconfig_mutex)); + /* + * Set mddev->thread to NULL before setup_conf() to avoid waking up + * wrong thread(eg. raid1), which can prevent the strips from being + * left unreleased in the error handling path(free_conf) of raid5_run. + */ + rcu_assign_pointer(mddev->thread, NULL); + + switch (mddev->level) { + case 0: + ret =3D raid45_takeover_raid0(mddev, 5); + break; + case 1: + ret =3D raid5_takeover_raid1(mddev); + break; + case 4: mddev->new_layout =3D ALGORITHM_PARITY_N; mddev->new_level =3D 5; - return setup_conf(mddev); + ret =3D setup_conf(mddev); + break; + case 6: + ret =3D raid5_takeover_raid6(mddev); + break; } - if (mddev->level =3D=3D 6) - return raid5_takeover_raid6(mddev); =20 - return ERR_PTR(-EINVAL); + rcu_assign_pointer(mddev->thread, thread); + + return ret; } =20 static void *raid4_takeover(struct mddev *mddev) --=20 2.52.0 From nobody Thu Sep 24 20:37:47 2026 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4972B3B8939; Mon, 21 Sep 2026 07:23:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789975437; cv=none; b=GWQYiZTY7IZlXT3NgWp/47kaZ/mD2FWH8hs4m9EonswQnk0mhgiFLlPLdORlX+CEzDZzlPNK32ONG/u1wGnbgNsHOdMUiPCBbp/CDAJy4T9ImcsENbFdiu0kt3nY08rW2Xn1YiIcpN2JvzK9p60P9lO6Ufpt+3ceoC5DOa/l5Kg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789975437; c=relaxed/simple; bh=dUezfQ/yTDCfQhHSobhiYmgjAque3re0xS4R43wf6tw=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qpghSotFi4l/gfPvG3YEZaxSz1Gv3gL3pQLNGw+dg5XSpFepOrjmrJTfo8HCnREMzz9YoC5ovYZGeeb/OWJLMT4VtjLZuBNs7IulGx7oT9ujHsdDhajZqjBGaWMyt8OzSZV8C7h1L5/CsQj1rYShF3JLLq+c3BUwANFBwfDGH6c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=K4N6IRxs; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="K4N6IRxs" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=q2RGVJPNOoEoks8aAaWtb8od8gkNXIWnWWblok4byvY=; b=K4N6IRxs+Nleg3SVHB8+GgPAu9kAX9NIOzCKqUAK5NmpMfY8C9PSzNldD/7/ZssGFox7YrJsW PDKltjNxCenrUuIXDM5pIDyXvh7nt85mRUDqTmiEuRq3JQWVaHjE4qJjZohFTOngUrwdDTQHjhv Xp3s2NhlnZO4V4NztTJZQw4= Received: from mail.maildlp.com (unknown [172.19.163.0]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4hpDtV34F4zpSy4; Mon, 21 Sep 2026 15:11:46 +0800 (CST) Received: from whupemo200011.china.huawei.com (unknown [7.152.185.179]) by mail.maildlp.com (Postfix) with ESMTPS id A482540561; Mon, 21 Sep 2026 15:23:40 +0800 (CST) Received: from huawei.com (10.50.85.155) by whupemo200011.china.huawei.com (7.152.185.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 15:23:39 +0800 From: Zhihao Cheng To: , , CC: , , , , Subject: [PATCH 2/3] md/raid5: Don't free conf on raid5_run failure Date: Mon, 21 Sep 2026 15:15:35 +0800 Message-ID: <20260921071537.2902362-3-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260921071537.2902362-1-chengzhihao1@huawei.com> References: <20260921071537.2902362-1-chengzhihao1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To whupemo200011.china.huawei.com (7.152.185.179) Content-Type: text/plain; charset="utf-8" Set 'raid_disks' after raid5_run() failure will trigger an null-ptr-deref problem: BUG: kernel NULL pointer dereference, address: 0000000000000038 RIP: 0010:raid5_check_reshape+0xad Call Trace: update_raid_disks+0x124 raid_disks_store+0x145 md_attr_store+0xd7 sysfs_kf_write+0x7c The trigger process is simple: mdadm --create /dev/md0 --level=3D1 --raid-devices=3D2 /dev/sda /dev/sdb --force --assume-clean # create raid1 echo 5 > /sys/block/md0/md/level level_store mddev->pers =3D pers mddev->private =3D priv raid5_run fail to abort (eg. raid5_create_ctx_pool fails) mddev->private =3D NULL echo 10 > /sys/block/md0/md/raid_disks raid_disks_store if (mddev->pers) // true update_raid_disks raid5_check_reshape conf =3D mddev->private conf->algorithm =3D mddev->new_layout // null-ptr-deref ! // similar process in do_md_stop->__md_stop_writes->raid5_quiesce Just like commit 35f20acaa358 ("md/raid0: don't free conf on raid0_run failure") does, fix it by not free conf on raid5_run failure. Fixes: 245f46c2c221e ("md: add ->takeover method to support changing the pe= rsonality managing an array") Signed-off-by: Zhihao Cheng --- drivers/md/raid5.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 7e87e8a60f5f..913e5a709e35 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -8263,8 +8263,6 @@ static int raid5_run(struct mddev *mddev) abort: md_unregister_thread(mddev, &mddev->thread); print_raid5_conf(conf); - free_conf(conf); - mddev->private =3D NULL; pr_warn("md/raid:%s: failed to run raid set.\n", mdname(mddev)); return ret; } --=20 2.52.0 From nobody Thu Sep 24 20:37:47 2026 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66C4C3B8D41; Mon, 21 Sep 2026 07:23:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789975436; cv=none; b=sH6AFVwRthThNL9DRDvcS3NcD+dYyzecOaS1UJX6g5pMRx7stWCkJ5ZMFg7dab9+W0AT2IpU+hQgcLkIEmY14cCFRx0x9SSOybyfIR/vXYaQOM/Pvfm75P2vTFbdaUNNGoRW7bxhoGORBJ+GfzaBcdPjbJETR3geXua8xE/ug0Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789975436; c=relaxed/simple; bh=KEUPBL54615weRyUwbUQob5rLs7Iwbct1zpw6tsonQU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sy5OBofGDVEUWsSPjryqkTBr0DomI8zp+/u1/JC6R3nsKseS4MgYwhsbUTEjZ4e+Oq66ARxlp7tTb/F29cAyDQfdVo+uVjQwRpRJ/OaOCypeLLxyu81Yr/w6dLw2LJAkJaEDJcZ06zdmVTenefFZ0BunVrEDr9EdRzST5F7NBvo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=4hFlw4Xt; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="4hFlw4Xt" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=oVi60O73/8T5TVpPXwgizHbL8pP8zx0+PMJEBZkQ/EI=; b=4hFlw4XtRGC28C4OFPTI9z9gqgZ3xbl8Bw2XvPq/J//bO2D1Nxc7ertOJe0GyxE5AZTq2RwHq m4/Or8zWvF0S3NxD9UK9nSVEoFxC4IksTI5PRDYuISSMOY9GN7E8MlHxaPWVdD7ujIkx23rFLdb ralqWO4E1w5IyVDlvZ7ONuk= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4hpDtW1KY3zpSy4; Mon, 21 Sep 2026 15:11:47 +0800 (CST) Received: from whupemo200011.china.huawei.com (unknown [7.152.185.179]) by mail.maildlp.com (Postfix) with ESMTPS id 683424057F; Mon, 21 Sep 2026 15:23:41 +0800 (CST) Received: from huawei.com (10.50.85.155) by whupemo200011.china.huawei.com (7.152.185.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 21 Sep 2026 15:23:40 +0800 From: Zhihao Cheng To: , , CC: , , , , Subject: [PATCH 3/3] md/raid10: Don't free conf on raid10_run failure Date: Mon, 21 Sep 2026 15:15:36 +0800 Message-ID: <20260921071537.2902362-4-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260921071537.2902362-1-chengzhihao1@huawei.com> References: <20260921071537.2902362-1-chengzhihao1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To whupemo200011.china.huawei.com (7.152.185.179) Content-Type: text/plain; charset="utf-8" Set 'raid_disks' after raid5_run() failure will trigger an null-ptr-deref problem: BUG: kernel NULL pointer dereference, address: 00000000000000dc RIP: 0010:_raw_spin_lock_irq+0x3d Call Trace: raise_barrier+0x3a raid10_quiesce+0x20 __md_stop_writes+0x6c do_md_stop+0xaa The trigger process is simple: mdadm --create /dev/md0 --level=3D0 --raid-devices=3D2 /dev/sda /dev/sdb --force --assume-clean # create raid0 echo 10 > /sys/block/md0/md/level level_store mddev->pers =3D pers mddev->private =3D priv raid10_run fail to out_free_conf (eg. enough fails) raid10_free_conf(conf) mddev->private =3D NULL echo inactive > /sys/block/md0/md/array_state array_state_store do_md_stop __md_stop_writes raid10_quiesce raise_barrier write_seqlock_irq(&conf->resync_lock) // null-ptr-deref ! Just like commit 35f20acaa358 ("md/raid0: don't free conf on raid0_run failure") does, fix it by not free conf on raid10_run failure. Fixes: 245f46c2c221e ("md: add ->takeover method to support changing the pe= rsonality managing an array") Signed-off-by: Zhihao Cheng --- drivers/md/raid10.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index 1093c798d9dd..9e4d4202f35c 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -3972,7 +3972,7 @@ static int raid10_run(struct mddev *mddev) if (fc > 1 || fo > 0) { pr_err("only near layout is supported by clustered" " raid10\n"); - goto out_free_conf; + goto out_unregister_thread; } } =20 @@ -3989,11 +3989,11 @@ static int raid10_run(struct mddev *mddev) =20 if (test_bit(Replacement, &rdev->flags)) { if (disk->replacement) - goto out_free_conf; + goto out_unregister_thread; disk->replacement =3D rdev; } else { if (disk->rdev) - goto out_free_conf; + goto out_unregister_thread; disk->rdev =3D rdev; } diff =3D (rdev->new_data_offset - rdev->data_offset); @@ -4013,7 +4013,7 @@ static int raid10_run(struct mddev *mddev) =20 if (err) { ret =3D err; - goto out_free_conf; + goto out_unregister_thread; } } =20 @@ -4021,17 +4021,17 @@ static int raid10_run(struct mddev *mddev) if (!enough(conf, -1)) { pr_err("md/raid10:%s: not enough operational mirrors.\n", mdname(mddev)); - goto out_free_conf; + goto out_unregister_thread; } =20 if (conf->reshape_progress !=3D MaxSector) { /* must ensure that shape change is supported */ if (conf->geo.far_copies !=3D 1 && conf->geo.far_offset =3D=3D 0) - goto out_free_conf; + goto out_unregister_thread; if (conf->prev.far_copies !=3D 1 && conf->prev.far_offset =3D=3D 0) - goto out_free_conf; + goto out_unregister_thread; } =20 mddev->degraded =3D 0; @@ -4081,7 +4081,7 @@ static int raid10_run(struct mddev *mddev) set_bit(MD_FAILFAST_SUPPORTED, &mddev->flags); =20 if (md_integrity_register(mddev)) - goto out_free_conf; + goto out_unregister_thread; =20 if (conf->reshape_progress !=3D MaxSector) { unsigned long before_length, after_length; @@ -4094,7 +4094,7 @@ static int raid10_run(struct mddev *mddev) if (max(before_length, after_length) > min_offset_diff) { /* This cannot work */ pr_warn("md/raid10: offset difference not enough to continue reshape\n"= ); - goto out_free_conf; + goto out_unregister_thread; } conf->offset_diff =3D min_offset_diff; =20 @@ -4106,10 +4106,8 @@ static int raid10_run(struct mddev *mddev) =20 return 0; =20 -out_free_conf: +out_unregister_thread: md_unregister_thread(mddev, &mddev->thread); - raid10_free_conf(conf); - mddev->private =3D NULL; out: return ret; } --=20 2.52.0