Messages in this thread | | | Date | Thu, 5 Jan 2012 09:20:05 +0200 | From | Gleb Natapov <> | Subject | Re: [PATCH] jump label: close race in jump_label_inc() vs. jump_label_dec() |
| |
On Wed, Jan 04, 2012 at 10:32:37AM -0500, Jason Baron wrote: > The previous fix to ensure that jump_label_inc() does not return until the jump > is completely patched, opened up a race in the inc/dec path. The scenario is: > > key->enabled = 0; > > CPU 0 CPU 1 > ----- ----- > > jump_label_inc(): jump_label_dec(): > > 1) if (atomic_read(&key->enabled) == 0) > jump_label_update(key, JUMP_LABEL_ENABLE); > > 2) if (!atomic_dec_and_mutex_lock(&key->enabled, &jump_label_mutex)) > return; > > 3) atomic_inc(&key->enabled); > > So now, key->enabled = 0, but the jump has been enabled, which is an invalid > state. > Isn't it an indication of a higher level bug if jump_label_dec() is called on a disabled jump label? In other words isn't key->enabled == -1 invalid sate by itself? I do not see how the call sequence above can happen with perf events for instance. jump_label_dec() is called on event destruction and if key->enabled = 0 then there is no events to destroy.
-- Gleb.
| |