On 10/31/25 07:12, Damien Le Moal wrote:
The functions blk_zone_wplug_handle_reset_or_finish() and
blk_zone_wplug_handle_reset_all() both modify the zone write pointer
offset of zone write plugs that are the target of a reset, reset all or
finish zone management operation. However, these functions do this
modification before the BIO is executed. So if the zone operation fails,
the modified zone write pointer offsets become invalid.
Avoid this by modifying the zone write pointer offset of a zone write
plug that is the target of a zone management operation when the
operation completes. To do so, modify blk_zone_bio_endio() to call the
new function blk_zone_mgmt_bio_endio() which in turn calls the functions
blk_zone_reset_all_bio_endio(), blk_zone_reset_bio_endio() or
blk_zone_finish_bio_endio() depending on the operation of the completed
BIO, to modify a zone write plug write pointer offset accordingly.
These functions are called only if the BIO execution was successful.
Hmm.
Question remains: what _is_ the status of a write pointer once a
zone management operation is in flight?
I would argue it's turning into a Schroedinger state, and so we
cannot make any assumptions here.
In particular we cannot issue any other write I/O to that zone once
the operation is in flight, and so it becomes meaningless if we set
the write pointer before or after the zone operation.
Once the operation fails we have to issue a 'report write pointer'
command anyway as I'd be surprised if we could assume that a failure
in a zone management command would leave the write pointer unmodified.
So I would assume that zone write plugging already blocks the zone
while an zone management command is in flight.
But if it does, why do we need this patch?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
