+ write_bio->bi_iter.bi_size = chunk;
+ ret = submit_bio_wait(write_bio);
+ kfree(write_bio);
blk_mq_map_bio_put(write_bio) ?
or bio_uninit(write_bio); kfree(write_bio)?
hmm...
It continuously allocates and releases memory for bio,
Why don't you just allocate and reuse bio outside the loop?
Agree, we will update this in next version.
+ if (ret)
+ break;
+
+ pos_in += chunk;
+ pos_out += chunk;
+ }
+ cio->status = ret;
+ kvfree(emulation_io->buf);
+ kfree(emulation_io);
I have not usually seen an implementation that releases memory for
itself while performing a worker. ( I don't know what's right. :) )
The worker is already executing at this point.
We think releasing the reference after it starts executing should not
be an issue, and it didn't come-up in any of our testing too.
Since blkdev_copy_emulation() allocates memory for the emulation
and waits for it to be completed, wouldn't it be better to proceed
with the memory release for it in the same context?
That is, IMO, wouldn't it be better to free the memory related to
emulation in blkdev_copy_wait_io_completion()?
Above mentioned design works for synchronous IOs. But for asynchronous
IOs emulation job is punted to worker and submitter task returns.
Submitter doesn't wait for emulation to complete and memory is freed
later by worker.
Thank you,
Nitesh Shetty
