Messages in this thread | | | Date | Tue, 2 Jul 2013 10:03:06 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 0/3] static keys: fix test/set races |
| |
On Mon, Jul 01, 2013 at 12:12:11AM -0400, Jason Baron wrote: > > Yes, I agree that 'higher' level locking may be required for some callers of > the newly proposed interface. However, I do think that the > static_key_slow_set_true()/false() provides a nice abstraction for some > callers, while addressing test/set() races, by making that sequence atomic. > > I view the proposed inteface of set_true()/set_false() as somewhat analogous > to an atomic_set() call. In the same way, the current > static_key_slow_inc()/dec() are analogous to atomic_inc()/dec(). > > It arguably makes the code code a bit more readable, transforming sequences > such as: > > if (!static_key_enabled(&control_var)) > static_key_slow_inc(&control_var); > > into: > > static_key_slow_set_true(&control_var); > > > I see at least 3 users of static_keys in the tree which I think would > benefit from this transformation. The 2 attached with this series, and the > usage in kernel/tracepoint.c.
I tend to agree with Jason here. I also dont' think the scheduler needs this; but the new API is more usable for binary switches as opposed to the refcount thing.
| |