Re: [Qemu-block] [PATCH v6 2/2] iothread: let aio_epoll_disable fit to aio_context_destroy

On Thu, 05/17 10:26, Jie Wang wrote: > epoll_available will only be set if epollfd != -1, os we s/os/so/ > can swap the two variables in aio_epoll_disable, and > aio_context_destroy can call aio_epoll_disable directly. If you put this as 1/2 in v7, you do not want to mention the

Re: [Qemu-block] [PATCH v6 1/2] iothread: fix epollfd leak in the process of delIOThread

Thanks for the quick iterations. A note on the patch submission: When sending patch series with git, please use git-send-email's "--thread --no-chain-reply-to" options, and also create a cover letter using "git format-patch --cover-letter". Or you can use git-publish. For more complete

[Qemu-block] [PATCH v6 2/2] iothread: let aio_epoll_disable fit to aio_context_destroy

epoll_available will only be set if epollfd != -1, os we can swap the two variables in aio_epoll_disable, and aio_context_destroy can call aio_epoll_disable directly. Signed-off-by: Jie Wang --- util/aio-posix.c | 10 -- 1 file changed, 4 insertions(+), 6

[Qemu-block] [PATCH v6 1/2] iothread: fix epollfd leak in the process of delIOThread

When we call addIOThread, the epollfd created in aio_context_setup, but not close it in the process of delIOThread, so the epollfd will leak. Signed-off-by: Jie Wang --- include/block/aio.h | 8 util/aio-posix.c| 9 + util/aio-win32.c| 4

Re: [Qemu-block] [PATCH v5] iothread: fix epollfd leak in the process of delIOThread

OK! I will split into two patches On 2018/5/17 11:04, Peter Xu wrote: > On Thu, May 17, 2018 at 08:42:43AM +0800, Jie Wang wrote: >> When we call addIOThread, the epollfd created in aio_context_setup, >> but not close it in the process of delIOThread, so the epollfd will leak. > > (maybe also

Re: [Qemu-block] [PATCH v5] iothread: fix epollfd leak in the process of delIOThread

On Thu, 05/17 08:42, Jie Wang wrote: > When we call addIOThread, the epollfd created in aio_context_setup, > but not close it in the process of delIOThread, so the epollfd will leak. > > Signed-off-by: Jie Wang > --- > include/block/aio.h | 8 > util/aio-posix.c

[Qemu-block] [PATCH v5] iothread: fix epollfd leak in the process of delIOThread

When we call addIOThread, the epollfd created in aio_context_setup, but not close it in the process of delIOThread, so the epollfd will leak. Signed-off-by: Jie Wang --- include/block/aio.h | 8 util/aio-posix.c| 13 ++--- util/aio-win32.c| 4

Re: [Qemu-block] [PATCH v4] iothread: fix epollfd leak in the process of delIOThread

On Wed, 05/16 19:43, Peter Xu wrote: > On Wed, May 16, 2018 at 07:14:53PM +0800, WangJie (Pluto) wrote: > > Hi, Peter Xu: > > If call aio_epoll_disable() here, aio_epoll_disable() will return > > before close ctx->epollfd, > > Because the ctx->epoll_enabled is false in the moment. > >

Re: [Qemu-block] Restoring bitmaps after failed/cancelled migration

On Wed, 05/16 18:52, Vladimir Sementsov-Ogievskiy wrote: > 16.05.2018 18:32, Kevin Wolf wrote: > > Am 16.05.2018 um 17:10 hat Vladimir Sementsov-Ogievskiy geschrieben: > > > 16.05.2018 15:47, Kevin Wolf wrote: > > > > Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben: > > > > >

Re: [Qemu-block] [PATCH v4] iothread: fix epollfd leak in the process of delIOThread

I agree, wait for a reply from Fam On 2018/5/16 19:43, Peter Xu wrote: > On Wed, May 16, 2018 at 07:14:53PM +0800, WangJie (Pluto) wrote: >> Hi, Peter Xu: >> If call aio_epoll_disable() here, aio_epoll_disable() will return >> before close ctx->epollfd, >> Because the ctx->epoll_enabled

Re: [Qemu-block] [Qemu-devel] Problem with data miscompare using scsi-hd, cache=none and io=threads

On 05/16/2018 06:35 PM, Daniel Henrique Barboza wrote: On 05/16/2018 04:47 AM, Paolo Bonzini wrote: On 15/05/2018 23:25, Daniel Henrique Barboza wrote: This is the current status of this investigation. I decided to start a discussion here, see if someone can point me something that I

Re: [Qemu-block] [Qemu-devel] [RFC PATCH 09/12] qapi/block-core: add BitmapMapping and BitmapEntry structs

On 05/16/2018 05:37 PM, Eric Blake wrote: >> +## >> +# @BitmapMapping: >> +# >> +# List of described regions correlated to a named bitmap. >> +# >> +# @name: The name of the bitmap whose range is described here >> +# >> +# @entries: A list of zero or more @BitmapEntry elements representing >> +# 

Re: [Qemu-block] [Qemu-devel] [RFC PATCH 08/12] qjson: allow caller to ask for arbitrary indent

On 05/16/2018 05:34 PM, Eric Blake wrote: > On 05/11/2018 08:25 PM, John Snow wrote: >> The function already exists, just expose it. >> >> Signed-off-by: John Snow >> --- >>   include/qapi/qmp/qjson.h |  1 + >>   qobject/qjson.c  | 21 +++-- >>   2 files

Re: [Qemu-block] [Qemu-devel] Problem with data miscompare using scsi-hd, cache=none and io=threads

On 05/16/2018 06:47 AM, Dr. David Alan Gilbert wrote: * Daniel Henrique Barboza (danie...@linux.ibm.com) wrote: Hi, I've been working in the last two months in a miscompare issue that happens when using a raid device and a SATA as scsi-hd (emulated SCSI) with cache=none and io=threads during

Re: [Qemu-block] [RFC PATCH 09/12] qapi/block-core: add BitmapMapping and BitmapEntry structs

On 05/11/2018 08:25 PM, John Snow wrote: Add two new structures for detailing the marked regions of bitmaps as saved in e.g. qcow2 files. Signed-off-by: John Snow --- qapi/block-core.json | 32 1 file changed, 32 insertions(+) diff --git

Re: [Qemu-block] [Qemu-devel] Problem with data miscompare using scsi-hd, cache=none and io=threads

On 05/16/2018 04:47 AM, Paolo Bonzini wrote: On 15/05/2018 23:25, Daniel Henrique Barboza wrote: This is the current status of this investigation. I decided to start a discussion here, see if someone can point me something that I overlooked or got it wrong, before I started changing the POSIX

Re: [Qemu-block] [RFC PATCH 08/12] qjson: allow caller to ask for arbitrary indent

On 05/11/2018 08:25 PM, John Snow wrote: The function already exists, just expose it. Signed-off-by: John Snow --- include/qapi/qmp/qjson.h | 1 + qobject/qjson.c | 21 +++-- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git

Re: [Qemu-block] [PATCH 14/42] job: Add reference counting

On 05/16/2018 03:56 PM, Kevin Wolf wrote: + +void job_unref(Job *job) +{ +if (--job->refcnt == 0) { Should this be free()-like and allow an incoming job == NULL as a no-op? This behaves like block_job_unref() always behavec, and I don't see a single caller having a NULL check before

Re: [Qemu-block] [PATCH 37/42] job: Move progress fields to Job

On 05/09/2018 11:26 AM, Kevin Wolf wrote: BlockJob has fields .offset and .len, which are actually misnomers today because they are no longer tied to block device sizes, but just progress counters. As such they make a lot of sense in generic Jobs. This patch moves the fields to Job and renames

Re: [Qemu-block] [Qemu-devel] [RFC PATCH 07/12] qcow2-bitmap: add basic bitmaps info

On 05/14/2018 11:12 AM, Vladimir Sementsov-Ogievskiy wrote: > 12.05.2018 04:25, John Snow wrote: >> Add functions for querying the basic information inside of bitmaps. >> Restructure the bitmaps flags masks to facilitate providing a list of >> flags belonging to the bitmap(s) being queried. >>

Re: [Qemu-block] [Qemu-devel] [RFC PATCH 06/12] qapi: add bitmap info

On 05/14/2018 10:30 AM, Vladimir Sementsov-Ogievskiy wrote: > 12.05.2018 04:25, John Snow wrote: >> Add some of the necessary scaffolding for reporting bitmap information. >> >> Signed-off-by: John Snow >> --- >>   qapi/block-core.json | 60 >>

Re: [Qemu-block] [PATCH 14/42] job: Add reference counting

Am 16.05.2018 um 20:17 hat Eric Blake geschrieben: > On 05/09/2018 11:26 AM, Kevin Wolf wrote: > > This moves reference counting from BlockJob to Job. > > > > In order to keep calling the BlockJob cleanup code when the job is > > deleted via job_unref(), introduce a new JobDriver.free callback.

Re: [Qemu-block] [PATCH 38/42] job: Add JOB_STATUS_CHANGE QMP event

On 05/16/2018 03:46 PM, Kevin Wolf wrote: +{ 'event': 'JOB_STATUS_CHANGE', + 'data': { 'id': 'str', +'status': 'JobStatus' } } Is it worth also trying to list the old state that the transition came from? But that's new compared to what block jobs are currently doing, so if we

Re: [Qemu-block] [PATCH 22/42] job: Move BlockJobCreateFlags to Job

Am 16.05.2018 um 21:13 hat Eric Blake geschrieben: > On 05/09/2018 11:26 AM, Kevin Wolf wrote: > > This renames the BlockJobCreateFlags constants, moves a few JOB_INTERNAL > > checks to job_create() and the auto_{finalize,dismiss} fields from > > BlockJob to Job. > > Do we still want to allow

Re: [Qemu-block] [PATCH 38/42] job: Add JOB_STATUS_CHANGE QMP event

Am 16.05.2018 um 21:26 hat Eric Blake geschrieben: > On 05/09/2018 11:26 AM, Kevin Wolf wrote: > > This adds a QMP event that is emitted whenever a job transitions from > > one status to another. For the event, a new qapi/job.json schema file is > > created which will contain all job-related

Re: [Qemu-block] [PATCH 38/42] job: Add JOB_STATUS_CHANGE QMP event

On 05/09/2018 11:26 AM, Kevin Wolf wrote: This adds a QMP event that is emitted whenever a job transitions from one status to another. For the event, a new qapi/job.json schema file is created which will contain all job-related definitions that aren't tied to the block layer. Signed-off-by:

Re: [Qemu-block] [PATCH 22/42] job: Move BlockJobCreateFlags to Job

On 05/09/2018 11:26 AM, Kevin Wolf wrote: This renames the BlockJobCreateFlags constants, moves a few JOB_INTERNAL checks to job_create() and the auto_{finalize,dismiss} fields from BlockJob to Job. Do we still want to allow auto-finalize on all jobs, or should we keep it just for legacy

Re: [Qemu-block] [PATCH 23/42] blockjob: Split block_job_event_pending()

On 05/09/2018 11:26 AM, Kevin Wolf wrote: block_job_event_pending() doesn't only send a QMP event, but it also transitions to the PENDING state. Split the function so that we get one part only sending the event (like other block_job_event_* functions) and another part than does the state

Re: [Qemu-block] [PATCH 17/42] job: Move defer_to_main_loop to Job

On 05/09/2018 11:26 AM, Kevin Wolf wrote: Signed-off-by: Kevin Wolf --- Rather sparse on the commit message, given the other comments in this thread. +++ b/include/qemu/job.h @@ -58,6 +58,9 @@ typedef struct Job { */ bool cancelled; +/** Set to true

Re: [Qemu-block] [PATCH 17/42] job: Move defer_to_main_loop to Job

On 05/16/2018 05:51 AM, Max Reitz wrote: -static void commit_complete(BlockJob *job, void *opaque) +static void commit_complete(Job *job, void *opaque) { -CommitBlockJob *s = container_of(job, CommitBlockJob, common); +CommitBlockJob *s = container_of(job, CommitBlockJob, common.job);

Re: [Qemu-block] [PATCH 14/42] job: Add reference counting

On 05/09/2018 11:26 AM, Kevin Wolf wrote: This moves reference counting from BlockJob to Job. In order to keep calling the BlockJob cleanup code when the job is deleted via job_unref(), introduce a new JobDriver.free callback. Every block job must use block_job_free() for this callback, this is

Re: [Qemu-block] [PATCH 13/42] job: Move state transitions to Job

On 05/09/2018 11:26 AM, Kevin Wolf wrote: This moves BlockJob.status and the closely related functions (block_)job_state_transition() and (block_)job_apply_verb to Job. The two QAPI enums are renamed to JobStatus and JobVerb. Signed-off-by: Kevin Wolf ---

Re: [Qemu-block] [PATCH 12/42] job: Maintain a list of all jobs

On 05/09/2018 11:26 AM, Kevin Wolf wrote: This moves the job list from BlockJob to Job. Now we can check for duplicate IDs in job_create(). Signed-off-by: Kevin Wolf --- include/block/blockjob.h | 3 --- include/qemu/job.h | 19 +++ blockjob.c

[Qemu-block] [PULL 3/4] nfs: Fix error path in nfs_options_qdict_to_qapi()

From: Kevin Wolf Don't throw away local_err, but propagate it to errp. Signed-off-by: Kevin Wolf Message-id: 20180516161034.27440-1-kw...@redhat.com Reviewed-by: Eric Blake Reviewed-by: Jeff Cody Signed-off-by: Jeff

[Qemu-block] [PULL 1/4] qemu-iotests: reduce chance of races in 185

From: Stefan Hajnoczi Commit 8565c3ab537e78f3e69977ec2c609dc9417a806e ("qemu-iotests: fix 185") identified a race condition in a sub-test. Similar issues also affect the other sub-tests. If disk I/O completes quickly, it races with the QMP 'quit' command. This causes

Re: [Qemu-block] [Qemu-devel] [PATCH 18/42] job: Move coroutine and related code to Job

On 05/16/2018 12:50 PM, Kevin Wolf wrote: > Am 15.05.2018 um 01:02 hat John Snow geschrieben: >> >> >> On 05/09/2018 12:26 PM, Kevin Wolf wrote: >>> This commit moves some core functions for dealing with the job coroutine >>> from BlockJob to Job. This includes primarily entering the coroutine

[Qemu-block] [PULL 2/4] blockjob: do not cancel timer in resume

From: Stefan Hajnoczi Currently the timer is cancelled and the block job is entered by block_job_resume(). This behavior causes drain to run extra blockjob iterations when the job was sleeping due to the ratelimit. This patch leaves the job asleep when block_job_resume()

[Qemu-block] [PULL 0/4] Block patches

The following changes since commit c416eecea5f3aea863ab8fda5a36a24157b8f704: Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2018-05-15 17:02:00 +0100) are available in the git repository at: git://github.com/codyprime/qemu-kvm-jtc.git tags/block-pull-request

[Qemu-block] [PULL 4/4] nfs: Remove processed options from QDict

From: Kevin Wolf Commit c22a03454 QAPIfied option parsing in the NFS block driver, but forgot to remove all the options we processed. Therefore, we get an error in bdrv_open_inherit(), which thinks the remaining options are invalid. Trying to open an NFS image will result in an

Re: [Qemu-block] [PATCH 11/42] job: Add job_delete()

On 05/09/2018 11:26 AM, Kevin Wolf wrote: This moves freeing the Job object and its fields from block_job_unref() to job_delete(). Signed-off-by: Kevin Wolf --- include/qemu/job.h | 3 +++ blockjob.c | 3 +-- job.c | 6 ++ 3 files changed, 10

Re: [Qemu-block] [PATCH] nfs: Fix error path in nfs_options_qdict_to_qapi()

On Wed, May 16, 2018 at 06:10:34PM +0200, Kevin Wolf wrote: > Don't throw away local_err, but propagate it to errp. > > Signed-off-by: Kevin Wolf > --- > block/nfs.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/block/nfs.c b/block/nfs.c > index

Re: [Qemu-block] [PATCH] nfs: Remove processed options from QDict

On Wed, May 16, 2018 at 06:08:16PM +0200, Kevin Wolf wrote: > Commit c22a03454 QAPIfied option parsing in the NFS block driver, but > forgot to remove all the options we processed. Therefore, we get an > error in bdrv_open_inherit(), which thinks the remaining options are > invalid. Trying to open

Re: [Qemu-block] [Qemu-devel] [PATCH 18/42] job: Move coroutine and related code to Job

Am 15.05.2018 um 01:02 hat John Snow geschrieben: > > > On 05/09/2018 12:26 PM, Kevin Wolf wrote: > > This commit moves some core functions for dealing with the job coroutine > > from BlockJob to Job. This includes primarily entering the coroutine > > (both for the first and reentering) and

Re: [Qemu-block] [Qemu-devel] [PATCH] nfs: Fix error path in nfs_options_qdict_to_qapi()

On 05/16/2018 11:10 AM, Kevin Wolf wrote: Don't throw away local_err, but propagate it to errp. Signed-off-by: Kevin Wolf --- block/nfs.c | 1 + 1 file changed, 1 insertion(+) Reviewed-by: Eric Blake diff --git a/block/nfs.c b/block/nfs.c index

Re: [Qemu-block] [Qemu-devel] [PATCH] nfs: Remove processed options from QDict

On 05/16/2018 11:08 AM, Kevin Wolf wrote: Commit c22a03454 QAPIfied option parsing in the NFS block driver, but forgot to remove all the options we processed. Therefore, we get an error in bdrv_open_inherit(), which thinks the remaining options are invalid. Trying to open an NFS image will

Re: [Qemu-block] [PATCH 38/42] job: Add JOB_STATUS_CHANGE QMP event

Am 15.05.2018 um 00:11 hat Max Reitz geschrieben: > You forgot to adjust 094, and although I cannot prove it (I don't have > an nfs setup handy right now), I have a hunch that this patch breaks 173 > as well. NFS qemu-iotests look completely broken. And the block driver, too. I've sent a fix for

[Qemu-block] [PATCH] nfs: Remove processed options from QDict

Commit c22a03454 QAPIfied option parsing in the NFS block driver, but forgot to remove all the options we processed. Therefore, we get an error in bdrv_open_inherit(), which thinks the remaining options are invalid. Trying to open an NFS image will result in an error like this: Block protocol

[Qemu-block] [PATCH] nfs: Fix error path in nfs_options_qdict_to_qapi()

Don't throw away local_err, but propagate it to errp. Signed-off-by: Kevin Wolf --- block/nfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/nfs.c b/block/nfs.c index d6364d28bb..3349b67a76 100644 --- a/block/nfs.c +++ b/block/nfs.c @@ -571,6 +571,7 @@ static

Re: [Qemu-block] Restoring bitmaps after failed/cancelled migration

16.05.2018 18:32, Kevin Wolf wrote: Am 16.05.2018 um 17:10 hat Vladimir Sementsov-Ogievskiy geschrieben: 16.05.2018 15:47, Kevin Wolf wrote: Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben: 14.05.2018 09:41, Fam Zheng wrote: On Wed, 04/18 17:00, Vladimir

Re: [Qemu-block] Restoring bitmaps after failed/cancelled migration

Am 16.05.2018 um 17:10 hat Vladimir Sementsov-Ogievskiy geschrieben: > 16.05.2018 15:47, Kevin Wolf wrote: > > Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben: > > > 14.05.2018 09:41, Fam Zheng wrote: > > > > On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote: > > > > > Is

Re: [Qemu-block] Restoring bitmaps after failed/cancelled migration

16.05.2018 15:47, Kevin Wolf wrote: Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben: 14.05.2018 09:41, Fam Zheng wrote: On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote: Is it possible, that target will change the disk, and then we return control to the source? In

Re: [Qemu-block] [PATCH v3 4/8] xen_backend: add an emulation of grant copy

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 16 May 2018 15:31 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; qemu-block@nongnu.org; qemu- > de...@nongnu.org; Stefano Stabellini >

Re: [Qemu-block] [PATCH v3 4/8] xen_backend: add an emulation of grant copy

On Fri, May 04, 2018 at 08:26:03PM +0100, Paul Durrant wrote: > Not all Xen environments support the xengnttab_grant_copy() operation. > E.g. where the OS is FreeBSD or Xen is older than 4.8.0. > > This patch introduces an emulation of that operation using > xengnttab_map_domain_grant_refs() and

Re: [Qemu-block] [PATCH v3 3/8] xen: remove other open-coded use of libxengnttab

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 16 May 2018 15:14 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; qemu-block@nongnu.org; qemu- > de...@nongnu.org; Stefano Stabellini ; Greg

Re: [Qemu-block] [PATCH v3 1/8] xen_backend: add grant table helpers

On Fri, May 04, 2018 at 08:26:00PM +0100, Paul Durrant wrote: > This patch adds grant table helper functions to the xen_backend code to > localize error reporting and use of xen_domid. > > The patch also defers the call to xengnttab_open() until just before the > initialise method in XenDevOps is

Re: [Qemu-block] [PATCH v3 2/8] xen_disk: remove open-coded use of libxengnttab

On Fri, May 04, 2018 at 08:26:01PM +0100, Paul Durrant wrote: > Now that helpers are present in xen_backend, this patch removes open-coded > calls to libxengnttab from the xen_disk code. > > This patch also fixes one whitspace error in the assignment of the > XenDevOps initialise method. > >

Re: [Qemu-block] [PATCH v3 3/8] xen: remove other open-coded use of libxengnttab

On Fri, May 04, 2018 at 08:26:02PM +0100, Paul Durrant wrote: > Now that helpers are available in xen_backend, use them throughout all > Xen PV backends. > > Signed-off-by: Paul Durrant > --- > diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c > index 20c43a6..73d6f1b

Re: [Qemu-block] Restoring bitmaps after failed/cancelled migration

Am 14.05.2018 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben: > 14.05.2018 09:41, Fam Zheng wrote: > > On Wed, 04/18 17:00, Vladimir Sementsov-Ogievskiy wrote: > > > Is it possible, that target will change the disk, and then we return > > > control > > > to the source? In this case bitmaps

Re: [Qemu-block] [PATCH v4] iothread: fix epollfd leak in the process of delIOThread

On Wed, May 16, 2018 at 07:14:53PM +0800, WangJie (Pluto) wrote: > Hi, Peter Xu: > If call aio_epoll_disable() here, aio_epoll_disable() will return > before close ctx->epollfd, > Because the ctx->epoll_enabled is false in the moment. > In the process of addIOThread,

Re: [Qemu-block] [PATCH 40/42] job: Add query-jobs QMP command

Am 15.05.2018 um 01:09 hat Max Reitz geschrieben: > On 2018-05-09 18:26, Kevin Wolf wrote: > > This adds a minimal query-jobs implementation that shouldn't pose many > > design questions. It can later be extended to expose more information, > > and especially job-specific information. > > > >

Re: [Qemu-block] [PATCH v4] iothread: fix epollfd leak in the process of delIOThread

Hi, Peter Xu: If call aio_epoll_disable() in aio_context_destroy, aio_epoll_disable() will return before close(ctx->epollfd), Because the ctx->epoll_enabled is false in the moment. In the process of addIOThread, aio_context_setup created epoll without call

Re: [Qemu-block] [PATCH v4] iothread: fix epollfd leak in the process of delIOThread

Hi, Peter Xu: If call aio_epoll_disable() here, aio_epoll_disable() will return before close ctx->epollfd, Because the ctx->epoll_enabled is false in the moment. In the process of addIOThread, aio_context_setup created epoll without call aio_epoll_try_enable, so

Re: [Qemu-block] [PATCH 32/42] job: Move completion and cancellation to Job

On 2018-05-15 14:59, Kevin Wolf wrote: > Am 14.05.2018 um 22:53 hat Max Reitz geschrieben: >> On 2018-05-09 18:26, Kevin Wolf wrote: >>> This moves the top-level job completion and cancellation functions from >>> BlockJob to Job. >>> >>> Signed-off-by: Kevin Wolf > >>> @@

Re: [Qemu-block] [PATCH 17/42] job: Move defer_to_main_loop to Job

On 2018-05-15 14:17, Kevin Wolf wrote: > Am 14.05.2018 um 17:52 hat Max Reitz geschrieben: >> On 2018-05-09 18:26, Kevin Wolf wrote: >>> Signed-off-by: Kevin Wolf >>> --- >>> include/block/blockjob.h | 5 >>> include/block/blockjob_int.h | 19 --- >>>

[Qemu-block] [PATCH v3] iothread: fix epollfd leak in the process of delIOThread

From: w00251574 When we call addIOThread, the epollfd created in aio_context_setup, but not close it in the process of delIOThread, so the epollfd will leak. Signed-off-by: Jie Wang --- include/block/aio.h | 8 util/aio-posix.c| 9

Re: [Qemu-block] [Qemu-devel] Problem with data miscompare using scsi-hd, cache=none and io=threads

* Daniel Henrique Barboza (danie...@linux.ibm.com) wrote: > Hi, > > I've been working in the last two months in a miscompare issue that happens > when using a raid device and a SATA as scsi-hd (emulated SCSI) with > cache=none and io=threads during a hardware stress test. I'll summarize it > here

Re: [Qemu-block] [PATCH v2] iothread: fix epollfd leak in the process of delIOThread

On Wed, May 16, 2018 at 02:39:44PM +0800, Jie Wang wrote: > From: w00251574 (Maybe you'd prefer to still use "Jie Wang" here? :) > > When we call addIOThread, the epollfd created in aio_context_setup, > but not close it in the process of delIOThread, so the epollfd will

Re: [Qemu-block] [PATCH v2] iothread: fix epollfd leak in the process of delIOThread

On Wed, 05/16 14:39, Jie Wang wrote: > From: w00251574 > > When we call addIOThread, the epollfd created in aio_context_setup, > but not close it in the process of delIOThread, so the epollfd will leak. > > Signed-off-by: Jie Wang > --- >

[Qemu-block] [PATCH v2] iothread: fix epollfd leak in the process of delIOThread

From: w00251574 When we call addIOThread, the epollfd created in aio_context_setup, but not close it in the process of delIOThread, so the epollfd will leak. Signed-off-by: Jie Wang --- include/block/aio.h | 8 util/aio-posix.c| 7

Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads

On 15/05/2018 23:25, Daniel Henrique Barboza wrote: > This is the current status of this investigation. I decided to start a > discussion here, see if someone can point me something that I overlooked > or got it wrong, before I started changing the POSIX thread pool > behavior to see if I can