qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 5/6] blockjob: refactor backup_start as backu


From: John Snow
Subject: Re: [Qemu-devel] [PATCH v3 5/6] blockjob: refactor backup_start as backup_job_create
Date: Tue, 8 Nov 2016 00:41:50 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0



On 11/03/2016 09:17 AM, Kevin Wolf wrote:
Am 02.11.2016 um 18:50 hat John Snow geschrieben:
Refactor backup_start as backup_job_create, which only creates the job,
but does not automatically start it. The old interface, 'backup_start',
is not kept in favor of limiting the number of nearly-identical interfaces
that would have to be edited to keep up with QAPI changes in the future.

Callers that wish to synchronously start the backup_block_job can
instead just call block_job_start immediately after calling
backup_job_create.

Transactions are updated to use the new interface, calling block_job_start
only during the .commit phase, which helps prevent race conditions where
jobs may finish before we even finish building the transaction. This may
happen, for instance, during empty block backup jobs.

Reported-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: John Snow <address@hidden>

+static void drive_backup_commit(BlkActionState *common)
+{
+    DriveBackupState *state = DO_UPCAST(DriveBackupState, common, common);
+    if (state->job) {
+        block_job_start(state->job);
+    }
 }

How could state->job ever be NULL?


Mechanical thinking. It can't. (I definitely didn't copy paste from the .abort routines. Definitely.)

Same question for abort, and for blockdev_backup_commit/abort.


Abort ... we may not have created the job successfully. Abort gets called whether or not we made it to or through the matching .prepare.

Kevin


--js



reply via email to

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