qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] segfault in parallel blockjobs (iotest 30)


From: John Snow
Subject: Re: [Qemu-devel] [Qemu-block] segfault in parallel blockjobs (iotest 30)
Date: Wed, 22 Nov 2017 10:58:31 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0


On 11/22/2017 07:55 AM, Alberto Garcia wrote:
> On Tue 21 Nov 2017 04:18:13 PM CET, Anton Nefedov wrote:
>>  >> keep BlockJob referenced while it is
>>  >> paused (by block_job_pause/resume_all()). That should prevent it from
>>  >> deleting the BB.
>>
>> looks kind of hacky; maybe referencing in block_job_pause() (and not
>> just pause_all) seems more correct? I think it didn't work for me
>> right away though. But I can look more.
> 
> This fixes one crash for me (but only the test_stream_commit, it doesn't
> fix iotest 030 completely), but I agree it looks kind of hacky.
> 
> Peharps replacing block_job_next() with QLIST_FOREACH_SAFE() is a good
> idea, though, I guess resuming a block job can theoretically lead to its
> destruction?
> 

Indirectly, though I think currently all implemented blockjobs defer to
the main loop first as an implementation detail of the job, and then the
.abort/.commit decision will put down the last reference that the job
keeps for itself.

(Other entities may hold a reference though, like a transaction.)

[I'd love to implement a shim that forces this, but it's not important
right now.]

Whether or not you can count on the job to be there after a resume
depends on what kind of locks or threading guarantees you can make in
the context you're asking the question.

But that sounds dangerous in case any implementation detail changes, so
maybe don't.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]