On 2020/03/11 15:24, Christoph Hellwig wrote: > 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. > OK. Will do. -- Damien Le Moal Western Digital Research
