Re: [PATCH 1/2] md: fix WARN_ON if create symlink fail in bind_rdev_to_array()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

在 2023/12/25 9:11, Song Liu 写道:
On Thu, Dec 21, 2023 at 5:17 PM Li Nan <linan666@xxxxxxxxxxxxxxx> wrote:



在 2023/12/22 2:58, Song Liu 写道:
[...]
In general, I would like to avoid adding flags if possible.


This flag is mainly used to fix deadlock in next patch. Or should we
export bd_find_holder_disk()? Link hodler if it return NULL.
just like:

    rdev_for_each_rcu
      if (!bd_find_holder_disk)
        bd_link_disk_holder

I was thinking we will not need the flag if we fail bind_rdev_to_array()
on error (below).



   };

   static inline int is_badblock(struct md_rdev *rdev, sector_t s, int sectors,
diff --git a/drivers/md/md.c b/drivers/md/md.c
index e05858653a41..d6612b922c76 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2526,7 +2526,8 @@ static int bind_rdev_to_array(struct md_rdev *rdev, struct mddev *mddev)
                  sysfs_get_dirent_safe(rdev->kobj.sd, "bad_blocks");

          list_add_rcu(&rdev->same_set, &mddev->disks);
-       bd_link_disk_holder(rdev->bdev, mddev->gendisk);
+       if (!bd_link_disk_holder(rdev->bdev, mddev->gendisk))
+               set_bit(SymlinkCreated, &rdev->flags);

Shall we just fail bind_rdev_to_array() if bd_link_disk_holder()
returns non-zero?


I keep this action because of commit 00bcb4ac7ee7 ("md: reduce
dependence on sysfs."). Fail bind_rdev_to_array is good to me.

I wonder whether the assumption in 00bcb4ac7ee7 is still true. If
bd_link_disk_holder() fails for valid reasons, we need to handle it
properly (set a flag, check the flag on unlink, etc.). If we only fail
bd_link_disk_holder() on extreme cases (ENOMEM, etc.), we can
just fail bind_rdev_to_array().

I totally agree! Currently, bd_link_disk_holder() from md won't return
-EINVAL, it will return -ENOMEM or -ENODEV if underlying disk is
deleted, which means bind_rdev_to_array() should fail as well.

The only problem is that this will make next patch more complicated, but
I think this can be solved.

Thanks,
Kuai

Thanks,
Song
.






[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux