From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: vsementsov@virtuozzo.com, qemu-block@nongnu.org,
jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 5/6] blockjob: refactor backup_start as backup_job_create
Date: Tue, 8 Nov 2016 10:11:19 +0100 [thread overview]
Message-ID: <20161108091119.GA5088@noname.str.redhat.com> (raw)
In-Reply-To: <f3efc94f-12f9-7728-f4cf-88f9bd205426@redhat.com>
Am 08.11.2016 um 06:41 hat John Snow geschrieben:
> 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 <vsementsov@virtuozzo.com>
> >>Signed-off-by: John Snow <jsnow@redhat.com>
> >
> >>+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.
Ah, yes, I always forget about this. It's so counterintuitive (and
bdrv_reopen() actually works differently, it only aborts entries that
have successfully been prepared).
Is there a good reason why qmp_transaction() works this way, especially
since we have a separate .clean function?
Kevin
next prev parent reply other threads:[~2016-11-08 9:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 17:50 [Qemu-devel] [PATCH v3 0/6] jobs: fix transactional race condition John Snow
2016-11-02 17:50 ` [Qemu-devel] [PATCH v3 1/6] blockjob: fix dead pointer in txn list John Snow
2016-11-08 2:47 ` Jeff Cody
2016-11-02 17:50 ` [Qemu-devel] [PATCH v3 2/6] blockjob: add .clean property John Snow
2016-11-08 2:51 ` Jeff Cody
2016-11-02 17:50 ` [Qemu-devel] [PATCH v3 3/6] blockjob: add .start field John Snow
2016-11-08 2:58 ` Jeff Cody
2016-11-02 17:50 ` [Qemu-devel] [PATCH v3 4/6] blockjob: add block_job_start John Snow
2016-11-03 12:17 ` Kevin Wolf
2016-11-08 2:02 ` John Snow
2016-11-08 2:05 ` Jeff Cody
2016-11-08 2:20 ` John Snow
2016-11-08 9:16 ` Kevin Wolf
2016-11-02 17:50 ` [Qemu-devel] [PATCH v3 5/6] blockjob: refactor backup_start as backup_job_create John Snow
2016-11-03 13:17 ` Kevin Wolf
2016-11-08 5:41 ` John Snow
2016-11-08 9:11 ` Kevin Wolf [this message]
2016-11-08 15:24 ` John Snow
2016-11-08 18:30 ` Jeff Cody
2016-11-08 3:14 ` Jeff Cody
2016-11-02 17:50 ` [Qemu-devel] [PATCH v3 6/6] iotests: add transactional failure race test John Snow
2016-11-03 13:21 ` [Qemu-devel] [PATCH v3 0/6] jobs: fix transactional race condition Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161108091119.GA5088@noname.str.redhat.com \
--to=kwolf@redhat.com \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).