On 2017-06-15 04:38, sochin.jiang wrote: > Thanks for your kindly reply. > > I do have made a mistake that ignoring the AIOContext lock. > > About the patch, firstly, if job->ret comes to be non-zero(also means > job->completed to be true) , blockjob 'callback'(common_block_job_cb) will be > called, blockjob error will be put into errp. It won't report success.
Oh, right, good.
> Secondly, blockjob fails with 'ret < 0' and without calling
> block_job_complete_sync(), we won't have segfault because bdrv_reopen won't
> be called.
commit_active_start() invokes bdrv_reopen(), and that segfaults for me
if the backing file is a bit unusual. See:
$ qemu-img create -f qcow2 \
-b "json:{'driver':'raw','file':{
'driver':'blkdebug','inject-error':[{
'event':'write_aio','once':true
}],
'image':{'driver':'null-co'}}}" \
overlay.qcow2
$ qemu-img commit overlay.qcow2
[1] 11080 segmentation fault (core dumped) qemu-img commit overlay.qcow2
Same if you actually write something to the overlay to trigger the write
error (which would fail the block job).
Yes, not directly related to your patch, which is why I've fixed it myself:
http://lists.nongnu.org/archive/html/qemu-block/2017-06/msg00424.html
> Also, with the use-after-free problems.
No, but I see you noticed that. :-)
Max
signature.asc
Description: OpenPGP digital signature
