| Message ID | 20241125032250.1329977-1-weilongping@oppo.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | dm-crypt: set max_io_len as chunk_sectors of zoned device | expand |
On Mon, Nov 25, 2024 at 11:22:51AM +0800, LongPing Wei wrote: > When dm level submit a bio with bi_size > max_sectors_kb of lower device, > blk_mq_submit_bio will split it into several ones with limited bi_size. > It may be a potential unordered issue as it breaks the ZWL design in dm > on 6.6. What is ZWL? And why mention 6.6? And why do you care about ordering? There is no real ordering requirement in the block layer.
On 11/25/24 2:00 PM, Christoph Hellwig wrote: > On Mon, Nov 25, 2024 at 11:22:51AM +0800, LongPing Wei wrote: >> When dm level submit a bio with bi_size > max_sectors_kb of lower device, >> blk_mq_submit_bio will split it into several ones with limited bi_size. >> It may be a potential unordered issue as it breaks the ZWL design in dm >> on 6.6. > > What is ZWL? And why mention 6.6? And why do you care about ordering? > There is no real ordering requirement in the block layer. > ZWL == zone write locking. That is, the mq-deadline request-based write request ordering control we had before zone write plugging. This is about ordering of write requests resulting from a split BIO.
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 1ae2c71bb383..9b487ccb1ebc 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -3417,6 +3417,8 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv) */ DMDEBUG("Zone append operations will be emulated"); ti->emulate_zone_append = true; + WARN_ON(dm_set_target_max_io_len(ti, + cc->dev->bdev->bd_queue->limits.chunk_sectors)); } if (crypt_integrity_aead(cc) || cc->integrity_iv_size) {
When dm level submit a bio with bi_size > max_sectors_kb of lower device, blk_mq_submit_bio will split it into several ones with limited bi_size. It may be a potential unordered issue as it breaks the ZWL design in dm on 6.6. It would be better to split bio by dm_split_and_process_bio in dm level. Considering the design of __max_io_len in dm.c, setting max_io_len for the target is needed to make __max_io_len return a len <= max_sectors. Signed-off-by: LongPing Wei <weilongping@oppo.com> --- A potential case is: f2fs submit a bio to zoned device with 1024KiB size, and the max sectors is 1024(512KiB). ZWL of dm will just re-submit it to the lower device, then the bios will be splited into two bios. They would be submitted to differect software queue as the context may run on different cpus. If the previous one is on CPU0 and the later one is on CPU1, then the software queue of CPU1 dispatch the request before CPU0, the issue will be triggered. CPU0: CPU1: f2fs_submit_bio[task x] dm_submit_bio[task x] blk_mq_split_bios[task x] submit_bio_noacct[task x] submit_bio_noacct[task x] dispatch requrest in queue[kworker1] dispatch requrest in queue[kworker0] --- drivers/md/dm-crypt.c | 2 ++ 1 file changed, 2 insertions(+)