[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140623222802.4900881c@gandalf.local.home>
Date: Mon, 23 Jun 2014 22:28:02 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: jbaron@...mai.com
Cc: andi@...stfloor.org, linux-kernel@...r.kernel.org,
mingo@...nel.org, peterz@...radead.org
Subject: Re: [PATCH 0/3] static keys: fix test/set races
Cleaning out my INBOX I found this patch series. It seems to have been
forgotten about. It ended up with Ingo and Peter agreeing with the way
things should be done and I thought Jason was going to send an update.
But that seems to never have happened.
Does this patch series still look legit? Should we pursue it?
-- Steve
On Fri, 28 Jun 2013 22:30:28 +0000 (GMT)
jbaron@...mai.com wrote:
> Hi,
>
> As pointed out by Andi Kleen, some static key users can be racy because they
> check the value of the key->enabled, and then subsequently update the branch
> direction. A number of call sites have 'higher' level locking that avoids this
> race, but the usage in the scheduler features does not. See:
> http://lkml.indiana.edu/hypermail/linux/kernel/1304.2/01655.html
>
> Thus, introduce a new API that does the check and set under the
> 'jump_label_mutex'. This should also allow to simplify call sites a bit.
>
> Users of static keys should use either the inc/dec or the set_true/set_false
> API.
>
> Thanks,
>
> -Jason
>
>
> Jason Baron (3):
> static_keys: Add a static_key_slow_set_true()/false() interface
> sched: fix static keys race in sched_feat
> udp: make use of static_key_slow_set_true() interface
>
> Documentation/static-keys.txt | 8 ++++++++
> include/linux/jump_label.h | 30 ++++++++++++++++++++++++++++++
> kernel/jump_label.c | 40 ++++++++++++++++++++++++++++++++++++++++
> kernel/sched/core.c | 12 +++++-------
> kernel/sched/sched.h | 10 +++++-----
> net/ipv4/udp.c | 9 ++++-----
> net/ipv6/udp.c | 9 ++++-----
> 7 files changed, 96 insertions(+), 22 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists