From: John Snow <jsnow@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: pkrempa@redhat.com, jtc@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [RFC v4 05/21] blockjobs: add state transition table
Date: Tue, 27 Feb 2018 13:58:57 -0500 [thread overview]
Message-ID: <00eb295a-5ccd-ff7b-f11b-78b9ac2286ca@redhat.com> (raw)
In-Reply-To: <20180227170849.GC5269@localhost.localdomain>
On 02/27/2018 12:08 PM, Kevin Wolf wrote:
> Am 27.02.2018 um 17:45 hat John Snow geschrieben:
>>
>>
>> On 02/27/2018 11:27 AM, Kevin Wolf wrote:
>>> Am 24.02.2018 um 00:51 hat John Snow geschrieben:
>>>> The state transition table has mostly been implied. We're about to make
>>>> it a bit more complex, so let's make the STM explicit instead.
>>>>
>>>> Perform state transitions with a function that for now just asserts the
>>>> transition is appropriate.
>>>>
>>>> Transitions:
>>>> Undefined -> Created: During job initialization.
>>>> Created -> Running: Once the job is started.
>>>> Jobs cannot transition from "Created" to "Paused"
>>>> directly, but will instead synchronously transition
>>>> to running to paused immediately.
>>>> Running -> Paused: Normal workflow for pauses.
>>>> Running -> Ready: Normal workflow for jobs reaching their sync point.
>>>> (e.g. mirror)
>>>> Ready -> Standby: Normal workflow for pausing ready jobs.
>>>> Paused -> Running: Normal resume.
>>>> Standby -> Ready: Resume of a Standby job.
>>>>
>>>>
>>>> +---------+
>>>> |UNDEFINED|
>>>> +--+------+
>>>> |
>>>> +--v----+
>>>> |CREATED|
>>>> +--+----+
>>>> |
>>>> +--v----+ +------+
>>>> |RUNNING<----->PAUSED|
>>>> +--+----+ +------+
>>>> |
>>>> +--v--+ +-------+
>>>> |READY<------->STANDBY|
>>>> +-----+ +-------+
>>>>
>>>>
>>>> Notably, there is no state presently defined as of this commit that
>>>> deals with a job after the "running" or "ready" states, so this table
>>>> will be adjusted alongside the commits that introduce those states.
>>>>
>>>> Signed-off-by: John Snow <jsnow@redhat.com>
>>>> ---
>>>> block/trace-events | 3 +++
>>>> blockjob.c | 42 ++++++++++++++++++++++++++++++++++++------
>>>> 2 files changed, 39 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/block/trace-events b/block/trace-events
>>>> index 02dd80ff0c..b75a0c8409 100644
>>>> --- a/block/trace-events
>>>> +++ b/block/trace-events
>>>> @@ -4,6 +4,9 @@
>>>> bdrv_open_common(void *bs, const char *filename, int flags, const char *format_name) "bs %p filename \"%s\" flags 0x%x format_name \"%s\""
>>>> bdrv_lock_medium(void *bs, bool locked) "bs %p locked %d"
>>>>
>>>> +# blockjob.c
>>>> +block_job_state_transition(void *job, int ret, const char *legal, const char *s0, const char *s1) "job %p (ret: %d) attempting %s transition (%s-->%s)"
>>>> +
>>>> # block/block-backend.c
>>>> blk_co_preadv(void *blk, void *bs, int64_t offset, unsigned int bytes, int flags) "blk %p bs %p offset %"PRId64" bytes %u flags 0x%x"
>>>> blk_co_pwritev(void *blk, void *bs, int64_t offset, unsigned int bytes, int flags) "blk %p bs %p offset %"PRId64" bytes %u flags 0x%x"
>>>> diff --git a/blockjob.c b/blockjob.c
>>>> index 1be9c20cff..d745b3bb69 100644
>>>> --- a/blockjob.c
>>>> +++ b/blockjob.c
>>>> @@ -28,6 +28,7 @@
>>>> #include "block/block.h"
>>>> #include "block/blockjob_int.h"
>>>> #include "block/block_int.h"
>>>> +#include "block/trace.h"
>>>> #include "sysemu/block-backend.h"
>>>> #include "qapi/error.h"
>>>> #include "qapi/qmp/qerror.h"
>>>> @@ -41,6 +42,34 @@
>>>> * block_job_enter. */
>>>> static QemuMutex block_job_mutex;
>>>>
>>>> +/* BlockJob State Transition Table */
>>>> +bool BlockJobSTT[BLOCK_JOB_STATUS__MAX][BLOCK_JOB_STATUS__MAX] = {
>>>> + /* U, C, R, P, Y, S */
>>>> + /* U: */ [BLOCK_JOB_STATUS_UNDEFINED] = {0, 1, 0, 0, 0, 0},
>>>
>>> Even at the end of the series, this is the only use of
>>> BLOCK_JOB_STATUS_UNDEFINED.
>>>
>>>> + /* C: */ [BLOCK_JOB_STATUS_CREATED] = {0, 0, 1, 0, 0, 0},
>>>> + /* R: */ [BLOCK_JOB_STATUS_RUNNING] = {0, 0, 0, 1, 1, 0},
>>>> + /* P: */ [BLOCK_JOB_STATUS_PAUSED] = {0, 0, 1, 0, 0, 0},
>>>> + /* Y: */ [BLOCK_JOB_STATUS_READY] = {0, 0, 0, 0, 0, 1},
>>>> + /* S: */ [BLOCK_JOB_STATUS_STANDBY] = {0, 0, 0, 0, 1, 0},
>>>> +};
>>>> +
>>>> +static void block_job_state_transition(BlockJob *job, BlockJobStatus s1)
>>>> +{
>>>> + BlockJobStatus s0 = job->status;
>>>> + if (s0 == s1) {
>>>> + return;
>>>> + }
>>>> + assert(s1 >= 0 && s1 <= BLOCK_JOB_STATUS__MAX);
>>>> + trace_block_job_state_transition(job, job->ret, BlockJobSTT[s0][s1] ?
>>>> + "allowed" : "disallowed",
>>>> + qapi_enum_lookup(&BlockJobStatus_lookup,
>>>> + s0),
>>>> + qapi_enum_lookup(&BlockJobStatus_lookup,
>>>> + s1));
>>>> + assert(BlockJobSTT[s0][s1]);
>>>> + job->status = s1;
>>>> +}
>>>> +
>>>> static void block_job_lock(void)
>>>> {
>>>> qemu_mutex_lock(&block_job_mutex);
>>>> @@ -320,7 +349,7 @@ void block_job_start(BlockJob *job)
>>>> job->pause_count--;
>>>> job->busy = true;
>>>> job->paused = false;
>>>> - job->status = BLOCK_JOB_STATUS_RUNNING;
>>>> + block_job_state_transition(job, BLOCK_JOB_STATUS_RUNNING);
>>>> bdrv_coroutine_enter(blk_bs(job->blk), job->co);
>>>> }
>>>>
>>>> @@ -704,6 +733,7 @@ void *block_job_create(const char *job_id, const BlockJobDriver *driver,
>>>> job->refcnt = 1;
>>>> job->manual = (flags & BLOCK_JOB_MANUAL);
>>>> job->status = BLOCK_JOB_STATUS_CREATED;
>>>> + block_job_state_transition(job, BLOCK_JOB_STATUS_CREATED);
>>>
>>> So did you intend to start with BLOCK_JOB_STATUS_UNDEFINED and then
>>> transition to BLOCK_JOB_STATUS_CREATED?
>>>
Oh, crud, yes. This is a refactoring issue that snuck in. I didn't even
realize after your first mail because I believed so strongly that I had
not done it this way.
>>> Or should we completely remove BLOCK_JOB_STATUS_UNDEFINED, keep the
>>> initialisation and not call block_job_state_transition() here?
>>>
>>> Kevin
>>>
>>
>> We can do that;
>>
>> I had it start as "Undefined" because I liked how a g_new0() object will
>> default to that state, so it felt "safe."
>>
>> On the negatives, it does mean that technically you COULD witness a job
>> in this state if QEMU did something wrong, which would be confusing
>> because you wouldn't be able to fix it via QMP.
>
> I don't really mind which way you do it as long as the code seems
> self-consistent. You could change the initialisation this way:
>
> job->status = BLOCK_JOB_STATUS_UNDEFINED;
> block_job_state_transition(job, BLOCK_JOB_STATUS_CREATED);
>
> Or if you want to make use of the fact that g_new0() already results in
> BLOCK_JOB_STATUS_UNDEFINED, you can omit the first line.
>
> I'm also not strictly opposed to a CREATED -> CREATED transition, even
> though it looks a bit odd. But then there is no reason to allow an
> UNDEFINED -> CREATED transition that never happens in practice.
> UNDEFINED would then be a completely unused state that could only be
> active in the case of a bug.
>
> Kevin
>
next prev parent reply other threads:[~2018-02-27 18:59 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 23:51 [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 01/21] blockjobs: fix set-speed kick John Snow
2018-02-27 16:32 ` Eric Blake
2018-02-27 17:18 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 02/21] blockjobs: model single jobs as transactions John Snow
2018-02-27 16:36 ` Eric Blake
2018-02-27 17:18 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 03/21] blockjobs: add manual property John Snow
2018-02-27 16:39 ` Eric Blake
2018-02-27 17:18 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 04/21] blockjobs: add status enum John Snow
2018-02-27 16:44 ` Eric Blake
2018-02-27 17:19 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 05/21] blockjobs: add state transition table John Snow
2018-02-27 16:27 ` Kevin Wolf
2018-02-27 16:45 ` John Snow
2018-02-27 17:08 ` Kevin Wolf
2018-02-27 18:58 ` John Snow [this message]
2018-02-27 18:58 ` Eric Blake
2018-02-27 19:06 ` John Snow
2018-02-27 19:22 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 06/21] iotests: add pause_wait John Snow
2018-02-27 17:19 ` Kevin Wolf
2018-02-27 19:01 ` Eric Blake
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 07/21] blockjobs: add block_job_verb permission table John Snow
2018-02-27 17:19 ` Kevin Wolf
2018-02-27 19:25 ` Eric Blake
2018-02-27 19:38 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 08/21] blockjobs: add ABORTING state John Snow
2018-02-27 19:34 ` Eric Blake
2018-02-28 14:54 ` Kevin Wolf
2018-02-28 19:26 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 09/21] blockjobs: add CONCLUDED state John Snow
2018-02-27 19:38 ` Eric Blake
2018-02-27 19:44 ` John Snow
2018-02-28 15:37 ` Kevin Wolf
2018-02-28 19:29 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 10/21] blockjobs: add NULL state John Snow
2018-02-27 19:41 ` Eric Blake
2018-02-28 15:42 ` Kevin Wolf
2018-02-28 20:04 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 11/21] blockjobs: add block_job_dismiss John Snow
2018-02-27 19:44 ` Eric Blake
2018-02-28 15:53 ` Kevin Wolf
2018-02-28 20:35 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 12/21] blockjobs: ensure abort is called for cancelled jobs John Snow
2018-02-27 19:49 ` Eric Blake
2018-02-27 20:43 ` John Snow
2018-02-28 16:05 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 13/21] blockjobs: add commit, abort, clean helpers John Snow
2018-02-27 19:50 ` Eric Blake
2018-02-28 16:07 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 14/21] blockjobs: add block_job_txn_apply function John Snow
2018-02-27 19:52 ` Eric Blake
2018-02-28 16:32 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 15/21] blockjobs: add prepare callback John Snow
2018-02-27 19:56 ` Eric Blake
2018-02-27 20:45 ` John Snow
2018-02-28 17:04 ` Kevin Wolf
2018-03-07 3:19 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status John Snow
2018-02-27 20:00 ` Eric Blake
2018-02-27 20:50 ` John Snow
2018-02-28 17:46 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 17/21] blockjobs: add PENDING status and event John Snow
2018-02-27 20:05 ` Eric Blake
2018-02-27 20:54 ` John Snow
2018-02-28 17:55 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize John Snow
2018-02-27 20:13 ` Eric Blake
2018-02-28 18:15 ` Kevin Wolf
2018-02-28 19:14 ` John Snow
2018-03-01 10:01 ` Kevin Wolf
2018-03-01 19:24 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 19/21] blockjobs: Expose manual property John Snow
2018-02-27 20:16 ` Eric Blake
2018-02-27 20:42 ` John Snow
2018-02-27 21:57 ` John Snow
2018-02-27 22:27 ` Eric Blake
2018-02-28 18:23 ` Kevin Wolf
2018-02-28 19:19 ` John Snow
2018-02-28 18:25 ` Kevin Wolf
2018-02-28 19:20 ` John Snow
2018-02-28 19:27 ` [Qemu-devel] [Qemu-block] " Eric Blake
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 20/21] iotests: test manual job dismissal John Snow
2018-02-27 20:21 ` Eric Blake
2018-02-27 20:41 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 21/21] blockjobs: add manual_mgmt option to transactions John Snow
2018-02-27 20:24 ` Eric Blake
2018-02-28 18:29 ` Kevin Wolf
2018-02-28 19:24 ` John Snow
2018-03-01 10:10 ` Kevin Wolf
2018-02-24 0:30 ` [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management no-reply
2018-02-24 14:31 ` no-reply
2018-02-27 21:01 ` John Snow
2018-02-28 18:32 ` Kevin Wolf
2018-02-25 23:25 ` no-reply
2018-02-27 20:58 ` John Snow
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=00eb295a-5ccd-ff7b-f11b-78b9ac2286ca@redhat.com \
--to=jsnow@redhat.com \
--cc=jtc@redhat.com \
--cc=kwolf@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).