qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH] Revert "blockdev: add note that bl


From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] Revert "blockdev: add note that block_job_cb() must be thread-safe"
Date: Thu, 15 Oct 2015 17:17:38 +0200
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Oct 14, 2015 at 10:51:27PM -0400, Fam Zheng wrote:
> 
> 
> ----- Original Message -----
> > On Tue, Oct 13, 2015 at 06:16:15PM +0800, Fam Zheng wrote:
> > > This reverts commit 723c5d93c51bdb3adbc238ce90195c0864aa6cd5.
> > > 
> > > block_job_cb is called by block_job_completed, which is always called in
> > > a main loop bottom half in existing block jobs. So we don't need to
> > > worry about thread-safety here.
> > 
> > This is not correct.  Search for block_job_completed() callers.
> > 
> > For example, block/stream.c has early exit cases that call
> > block_job_completed() from the coroutine (i.e. dispatched from a
> > coroutine in another AioContext+IOThread).
> > 
> > I think you are assuming that all block_job_completed() callers are
> > called from a function scheduled using block_job_defer_to_main_loop().
> 
> No, I'm assuming all block_job_completed() callers are (and they should
> be) from main thread. Even the early exit cases in stream are so, because
> they are in the same thread as stream_start, which is main thread.

You are right, the early block_job_completed() calls in stream.c happen
in the main thread.

I'm concerned that we have no comments or assertions to check that the
assumption holds.  Luckily only stream.c relies on the trick of calling
block_job_completed() directly but knowing it runs from the main thread.

I'll send a patch to fix stream.c.  It needs to be done anyway since
there is a memory leak in the early block_job_completed() stream.c code.
Will CC you.

Stefan



reply via email to

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