On Wed, Mar 11, 2020 at 12:34:33AM +0000, Damien Le Moal wrote: > Yes, I agree with you here. That would be nicer, but early attempt to do so > failed as we always ended up with potential races on number of zones/wp array > size in the case of a device change/revalidation. Moving the wp array allocation > and initialization to blk_revalidate_disk_zones() greatly simplifies the code > and removes the races as all updates to zone bitmaps, wp array and nr zones are > done under a queue freeze all together. Moving the wp array only to sd_zbc, even > using a queue freeze, leads to potential out-of-bounds accesses for the wp array. > > Another undesirable side effect of moving the wp array initialization to sd_zbc > is that we would need another full drive zone report after > blk_revalidate_disk_zones() own full report. That is costly. On 20TB SMR disks > with more than 75000 zones, the added delay is significant. Doing all > initialization within blk_revalidate_disk_zones() full zone report loop avoids > that added overhead. That explanation needs to got into the commit log.
