]> git.ipfire.org Git - thirdparty/mdadm.git/commit
Fix race of "mdadm --add" and "mdadm --incremental"
authorLi Xiao Keng <lixiaokeng@huawei.com>
Thu, 7 Sep 2023 11:37:44 +0000 (19:37 +0800)
committerJes Sorensen <jes@trained-monkey.org>
Thu, 26 Oct 2023 21:42:01 +0000 (17:42 -0400)
commited2c2cb3d440f3bd2692f1896446c4bcc703f05c
treef4c9656c00003b7159b09032531d1561a234b249
parent28fc84168646910a9271ebe1a12b1571e14f5900
Fix race of "mdadm --add" and "mdadm --incremental"

There is a raid1 with sda and sdb. And we add sdc to this raid,
it may return -EBUSY.

The main process of --add:
1. dev_open(sdc) in Manage_add
2. store_super1(st, di->fd) in write_init_super1
3. fsync(fd) in store_super1
4. close(di->fd) in write_init_super1
5. ioctl(ADD_NEW_DISK)

Step 2 and 3 will add sdc to metadata of raid1. There will be
udev(change of sdc) event after step4. Then "/usr/sbin/mdadm
--incremental --export $devnode --offroot $env{DEVLINKS}"
will be run, and the sdc will be added to the raid1. Then
step 5 will return -EBUSY because it checks if device isn't
claimed in md_import_device()->lock_rdev()->blkdev_get_by_dev()
->blkdev_get().

It will be confusing for users because sdc is added first time.
The "incremental" will get map_lock before add sdc to raid1.
So we add map_lock before write_init_super in "mdadm --add"
to fix the race of "add" and "incremental".

Signed-off-by: Li Xiao Keng <lixiaokeng@huawei.com>
Signed-off-by: Guanqin Miao <miaoguanqin@huawei.com>
Reviewed-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Jes Sorensen <jes@trained-monkey.org>
Manage.c