Re: racy jump label users

Hi Andi, Agreed. However, other users of 'static_key_enabled()', provide their own locking. For example, in kernel/tracepoint.c, 'static_key_enabled()', relies on the tracepoints_mutex. Were there any other users that are problematic? I agree a 'setstate' would be nice. Maybe something like:

Re: racy jump label users

Hi Andi, Agreed. However, other users of 'static_key_enabled()', provide their own locking. For example, in kernel/tracepoint.c, 'static_key_enabled()', relies on the tracepoints_mutex. Were there any other users that are problematic? I agree a 'setstate' would be nice. Maybe something like:

racy jump label users

Jason, I noticed that a lot of the jump label users are racy, because they implement something like this static void sched_feat_disable(int i) { if (static_key_enabled(_feat_keys[i])) static_key_slow_dec(_feat_keys[i]); } static void sched_feat_enable(int i) { if

racy jump label users

Jason, I noticed that a lot of the jump label users are racy, because they implement something like this static void sched_feat_disable(int i) { if (static_key_enabled(sched_feat_keys[i])) static_key_slow_dec(sched_feat_keys[i]); } static void sched_feat_enable(int i) {