search for: next_stat

Split h->state into: - h->state = the state on entry to the locked region - h->next_state = the current state and what the "publicly visible" state will become when we leave the locked region Some calls to get_state become calls to get_next_state depending on which of these they are trying to read. Calls to set_state become set_next_state because that is what gets update...

On Wed, Jun 05, 2019 at 12:15:37PM +0100, Richard W.M. Jones wrote: > -#define set_state(h,next_state) ((h)->state) = (next_state) > +#define set_next_state(h,_next_state) ((h)->next_state) = (_next_state) > +#define get_next_state(h) ((h)->next_state) > #define get_state(h) ((h)->state) So I wonder if it's better to rename get_state as get_last_state or get_visible_stat...

On 6/5/19 8:03 AM, Richard W.M. Jones wrote: > On Wed, Jun 05, 2019 at 01:35:32PM +0100, Richard W.M. Jones wrote: >> On Wed, Jun 05, 2019 at 12:15:37PM +0100, Richard W.M. Jones wrote: >>> -#define set_state(h,next_state) ((h)->state) = (next_state) >>> +#define set_next_state(h,_next_state) ((h)->next_state) = (_next_state) >>> +#define get_next_state(h) ((h)->next_state) >>> #define get_state(h) ((h)->state) >> >> So I wonder if it's better to rename get_st...

I need to think about this patch series a bit more, but it does at least pass the tests. Rich.

...oid *data) @@ -106,13 +95,11 @@ static int powernow_cpufreq_target(struc { struct acpi_cpufreq_data *data = cpufreq_drv_data[policy->cpu]; struct processor_performance *perf; - struct cpufreq_freqs freqs; cpumask_t online_policy_cpus; - struct drv_cmd cmd; - unsigned int next_state = 0; /* Index into freq_table */ - unsigned int next_perf_state = 0; /* Index into perf table */ - int result = 0; - int j = 0; + unsigned int next_state; /* Index into freq_table */ + unsigned int next_perf_state; /* Index into perf table */ + int result; + int j; if (...

...rw.c | 4 ++-- 6 files changed, 29 insertions(+), 26 deletions(-) diff --git a/generator/generator b/generator/generator index 8ed0a06..a3fbea9 100755 --- a/generator/generator +++ b/generator/generator @@ -2415,11 +2415,11 @@ let generate_lib_states_c () = pr " enum state next_state = %s;\n" state_enum; pr "\n"; pr " r = _enter_%s (h, &next_state, blocked);\n" state_enum; - pr " if (h->state != next_state) {\n"; + pr " if (get_state (h) != next_state) {\n"; pr " debug (h, \"tran...

...to %.READY as soon > as it would block, which in turn jumps right back into ISSUE_COMMAND > because we have a pending request not fully sent yet). Since the > jaunt through REPLY was non-blocking, it is unlikely that the POLLOUT > situation has changed in the meantime, so if we use SET_NEXT_STATE() > to step back into SEND_REQUEST, our recv() call will likely fail with > EAGAIN, once again blocking us until our next POLLOUT. Although the > wasted syscall is not on the hot-path (after all, we can't progress > until data arrives from the server), it's slightly cleaner if...

...of the handle When we leave the locked region we update h->public_state with h->state, so that from outside the lock the handle appears to move atomically from its previous state to the final state without going through any intermediate states. Some calls to ‘get_state’ become calls to ‘get_next_state’ if the need the real state. Others which need to see the publicly visible state are changed to ‘get_public_state’. All calls to ‘set_state’ become ‘set_next_state’ because that is the real state that gets updated. The purpose of this patch is to make it easier to reason about the state in lock...

...of the handle When we leave the locked region we update h->public_state with h->state, so that from outside the lock the handle appears to move atomically from its previous state to the final state without going through any intermediate states. Some calls to ‘get_state’ become calls to ‘get_next_state’ if the need the real state. Others which need to see the publicly visible state are changed to ‘get_public_state’. All calls to ‘set_state’ become ‘set_next_state’ because that is the real state that gets updated. The purpose of this patch is to make it easier to reason about the state in lock...

...on >> as it would block, which in turn jumps right back into ISSUE_COMMAND >> because we have a pending request not fully sent yet). Since the >> jaunt through REPLY was non-blocking, it is unlikely that the POLLOUT >> situation has changed in the meantime, so if we use SET_NEXT_STATE() >> to step back into SEND_REQUEST, our recv() call will likely fail with >> EAGAIN, once again blocking us until our next POLLOUT. Although the >> wasted syscall is not on the hot-path (after all, we can't progress >> until data arrives from the server), it's sli...

v1 was here: https://www.redhat.com/archives/libguestfs/2019-June/thread.html#00055 v2 was here: https://www.redhat.com/archives/libguestfs/2019-June/thread.html#00067 v3: - Fix atomicly -> atomically in commit message. - Fix a comment. - Fix TOCTTOU: There is now an inline function generated called <name>_is_permitted_state, and this is called twice, first outside the

....ml > index 274e290952..52c497646d 100644 > --- a/generator/state_machine_generator.ml > +++ b/generator/state_machine_generator.ml > @@ -380,9 +380,6 @@ let > pr " h, &next, blocked\n"; > pr " );\n"; > pr " if (get_next_state (h) != next) {\n"; > - pr " debug (h, \"transition: %%s -> %%s\",\n"; > - pr " \"%s\",\n" display_name; > - pr " nbd_internal_state_short_string (next));\n"; > pr " set_next_s...

...amfs.c~allow-no-trailer init/initramfs.c --- gr_work/init/initramfs.c~allow-no-trailer 2004-12-03 16:54:02.778579302 -0600 +++ gr_work-miltonm/init/initramfs.c 2004-12-03 16:54:02.789577561 -0600 @@ -241,10 +241,9 @@ static __initdata int wfd; static int __init do_name(void) { state = SkipIt; - next_state = Start; + next_state = Reset; if (strcmp(collected, "TRAILER!!!") == 0) { free_hash(); - next_state = Reset; return 0; } if (dry_run) @@ -295,7 +294,7 @@ static int __init do_symlink(void) sys_symlink(collected + N_ALIGN(name_len), collected); sys_lchown(collected, uid,...

...100644 --- a/generator/states.c +++ b/generator/states.c @@ -91,8 +91,8 @@ send_from_wbuf (struct nbd_handle *h) ssize_t r; if (h->wlen == 0) - return 0; /* move to next state */ - r = h->sock->ops->send (h, h->sock, h->wbuf, h->wlen, 0); + goto next_state; + r = h->sock->ops->send (h, h->sock, h->wbuf, h->wlen, h->wflags); if (r == -1) { if (errno == EAGAIN || errno == EWOULDBLOCK) return 1; /* more data */ @@ -102,9 +102,13 @@ send_from_wbuf (struct nbd_handle *h) h->wbuf += r; h->wl...

On 6/5/19 6:15 AM, Richard W.M. Jones wrote: > Split h->state into: > > - h->state = the state on entry to the locked region > > - h->next_state = the current state and what the "publicly visible" > state will become when we leave the locked region The rest of this thread discusses potential other names, such as h->public_state for the state visible to unlocked code and h->state for internal while still locked; I tru...

On Wed, Jun 05, 2019 at 01:35:32PM +0100, Richard W.M. Jones wrote: > On Wed, Jun 05, 2019 at 12:15:37PM +0100, Richard W.M. Jones wrote: > > -#define set_state(h,next_state) ((h)->state) = (next_state) > > +#define set_next_state(h,_next_state) ((h)->next_state) = (_next_state) > > +#define get_next_state(h) ((h)->next_state) > > #define get_state(h) ((h)->state) > > So I wonder if it's better to rename get_state as get_last_...

...args) in > > List.iter (pr ", %s") argnames; > > pr ");\n"; > > - if is_locked then > > - pr " pthread_mutex_unlock (&h->lock);\n"; > > + if is_locked then ( > > + pr " if (h->state != h->next_state)\n"; > > + pr " h->state = h->next_state;\n"; > > + pr " pthread_mutex_unlock (&h->lock);\n" > > + ); > > pr " return ret;\n"; > > pr "}\n"; > > pr "\n"; > &g...

...rned on) - only set the (global) bus master reload flag once (when the first target CPU gets processed) Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -439,8 +439,8 @@ static void acpi_processor_idle(void) (next_state = cpuidle_current_governor->select(power)) > 0 ) { cx = &power->states[next_state]; - if ( power->flags.bm_check && acpi_idle_bm_check() - && cx->type == ACPI_STATE_C3 ) + if ( cx->type == ACPI_STATE_C3 && power-...

These patches aren't related to each other, but both are quite simple. The second one requires particular attention - it's my experience that printing out the state transitions in debug mode has never helped me to diagnose a bug, but it has made the debug logs huge and hard to follow. However that might just be me! Has it helped anyone else? Also I'm open to the concept of debug

...locking (it returns to %.READY as soon as it would block, which in turn jumps right back into ISSUE_COMMAND because we have a pending request not fully sent yet). Since the jaunt through REPLY was non-blocking, it is unlikely that the POLLOUT situation has changed in the meantime, so if we use SET_NEXT_STATE() to step back into SEND_REQUEST, our recv() call will likely fail with EAGAIN, once again blocking us until our next POLLOUT. Although the wasted syscall is not on the hot-path (after all, we can't progress until data arrives from the server), it's slightly cleaner if we instead declare...