On 1/12/23 07:08, Damien Le Moal wrote: > On 1/11/23 21:23, Johannes Thumshirn wrote: >> On 10.01.23 14:08, Damien Le Moal wrote: >>> Using REQ_OP_ZONE_APPEND operations for synchronous writes to sequential >>> files succeeds regardless of the zone write pointer position, as long as >>> the target zone is not full. This means that if an external (buggy) >>> application writes to the zone of a sequential file underneath the file >>> system, subsequent file write() operation will succeed but the file size >>> will not be correct and the file will contain invalid data written by >>> another application. >>> >>> Modify zonefs_file_dio_append() to check the written sector of an append >>> write (returned in bio->bi_iter.bi_sector) and return -EIO if there is a >>> mismatch with the file zone wp offset field. This change triggers a call >>> to zonefs_io_error() and a zone check. Modify zonefs_io_error_cb() to >>> not expose the unexpected data after the current inode size when the >>> errors=remount-ro mode is used. Other error modes are correctly handled >>> already. >> >> This only happens on ZNS and null_blk, doesn't it? On SCSI the Zone Append >> emulation should catch this error before. > > Yes. The zone append will fail with scsi sd emulation so this change is > not useful in that case. But null_blk and ZNS drives will not fail the > zone append, resulting in a bad file size without this check. Let me retract that... For scsi sd, the zone append emulation will do its job if an application writes to a zone under the file system. Then zonefs issuing a zone append will also succeed and we end up with the bad inode size. We would get a zone append failure in zonefs with scsi sd if the corruption to the zone was done with a passthrough command as these will not result in sd_zbc zone write pointer tracking doing its job. -- Damien Le Moal Western Digital Research
