On 2020-04-19 8:21 p.m., Damien Le Moal wrote:
On 2020/04/19 0:56, Bart Van Assche wrote:
On 2020-04-17 05:15, Johannes Thumshirn wrote:
In order to reduce memory consumption, the only cached item is the offset
of the write pointer from the start of the zone, everything else can be
calculated. On an example drive with 52156 zones, the additional memory
consumption of the cache is thus 52156 * 4 = 208624 Bytes or 51 4k Byte
pages. The performance impact is neglectable for a spinning drive.
What will happen if e.g. syzkaller mixes write() system calls with SG_IO
writes? Can that cause a mismatch between the cached write pointer and
the write pointer maintained by the drive? If so, should SG_IO perhaps
be disallowed if the write pointer is cached?
Bart,
Yes, SG_IO write will change the WP on the device side, causing the driver WP
cache to go out of sync with the device. We actually use that for testing and
generating write errors.
But that is not a problem limited to this new write pointer caching scheme. Any
zoned drive user can hit this problem (dm-zoned or f2fs currently). More
generally speaking, SG_IO writes can corrupt data/metadata on any regular disk
without (for instance) the file system noticing until the corrupted
data/metadata is accessed. SG_IO to a disk is not disabled if the disk has a
mounted file system. Also, since the series adds unconditional write pointer
caching with CONFIG_BLK_DEV_ZONED enabled, that would disable SG_IO permanently
in this case, and negatively impact a lot of userspace tools relying on it (FW
update, power management, SMART, etc).
Putting my smartmontools maintainer hat on, I don't like the sound of that.
We have spent time in the past discussing black and white lists, but they
can't cope with vendor specific commands. Then there are commands that both
sd and smartmontools might have good cause to use; MODE SELECT comes to
mind. Changing the setting of the URSWRZ_M bit in the Zoned Block Device
Control page, for example, could upset the apple cart.
Doug Gilbert
