| Message ID | 20240327112902.1184822-3-vschneid@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | context_tracking, rcu: Standardize naming related to contex_tracking.state | expand |
Le Wed, Mar 27, 2024 at 12:29:02PM +0100, Valentin Schneider a écrit : > The symbols relating to the CT_STATE part of context_tracking.state are now > all prefixed with CT_STATE. > > The RCU dynticks counter part of that atomic variable still involves > symbols with different prefixes, align them all to be prefixed with > CT_DYNTICKS, as CT_DYNTICKS_MASK already is. > > Signed-off-by: Valentin Schneider <vschneid@redhat.com> It used to be that RCU extended quiescent state and dynticks enter/exit were coupled. But this isn't the case anymore. Nowadays RCU stops watching some time later after dynticks is entered. I wonder if we shouldn't take advantage of that cleanup for a meaning that really reflect that RCU stops watching from there. Paul what do you think? CT_EQS_IDX ? CT_RCUEQS_IDX? CT_RCUOFF_IDX? ...? Thanks.
On Thu, Apr 04, 2024 at 03:38:40PM +0200, Frederic Weisbecker wrote: > Le Wed, Mar 27, 2024 at 12:29:02PM +0100, Valentin Schneider a écrit : > > The symbols relating to the CT_STATE part of context_tracking.state are now > > all prefixed with CT_STATE. > > > > The RCU dynticks counter part of that atomic variable still involves > > symbols with different prefixes, align them all to be prefixed with > > CT_DYNTICKS, as CT_DYNTICKS_MASK already is. > > > > Signed-off-by: Valentin Schneider <vschneid@redhat.com> > > It used to be that RCU extended quiescent state and dynticks enter/exit > were coupled. But this isn't the case anymore. Nowadays RCU stops watching > some time later after dynticks is entered. I knew that consolidation of atomic operations was too good to last... > I wonder if we shouldn't take advantage of that cleanup for a meaning that > really reflect that RCU stops watching from there. > > Paul what do you think? CT_EQS_IDX ? CT_RCUEQS_IDX? CT_RCUOFF_IDX? ...? "After what you just did? You can just RCU off!!!" Sorry, couldn't resist... I am having a hard time getting too excited about the name. I could suggest CT_RCU_WATCHING_IDX, but that isn't exactly the shortest possible name. Thanx, Paul
Le Tue, Apr 09, 2024 at 12:53:03PM -0700, Paul E. McKenney a écrit : > On Thu, Apr 04, 2024 at 03:38:40PM +0200, Frederic Weisbecker wrote: > > Le Wed, Mar 27, 2024 at 12:29:02PM +0100, Valentin Schneider a écrit : > > > The symbols relating to the CT_STATE part of context_tracking.state are now > > > all prefixed with CT_STATE. > > > > > > The RCU dynticks counter part of that atomic variable still involves > > > symbols with different prefixes, align them all to be prefixed with > > > CT_DYNTICKS, as CT_DYNTICKS_MASK already is. > > > > > > Signed-off-by: Valentin Schneider <vschneid@redhat.com> > > > > It used to be that RCU extended quiescent state and dynticks enter/exit > > were coupled. But this isn't the case anymore. Nowadays RCU stops watching > > some time later after dynticks is entered. > > I knew that consolidation of atomic operations was too good to last... > > > I wonder if we shouldn't take advantage of that cleanup for a meaning that > > really reflect that RCU stops watching from there. > > > > Paul what do you think? CT_EQS_IDX ? CT_RCUEQS_IDX? CT_RCUOFF_IDX? ...? > > "After what you just did? You can just RCU off!!!" > > Sorry, couldn't resist... > > I am having a hard time getting too excited about the name. I could > suggest CT_RCU_WATCHING_IDX, but that isn't exactly the shortest > possible name. I really like CT_RCU_WATCHING. It says everything. The _IDX isn't even needed after all. What do you think? Thanks. > Thanx, Paul
On Wed, Apr 10, 2024 at 12:30:55PM +0200, Frederic Weisbecker wrote: > Le Tue, Apr 09, 2024 at 12:53:03PM -0700, Paul E. McKenney a écrit : > > On Thu, Apr 04, 2024 at 03:38:40PM +0200, Frederic Weisbecker wrote: > > > Le Wed, Mar 27, 2024 at 12:29:02PM +0100, Valentin Schneider a écrit : > > > > The symbols relating to the CT_STATE part of context_tracking.state are now > > > > all prefixed with CT_STATE. > > > > > > > > The RCU dynticks counter part of that atomic variable still involves > > > > symbols with different prefixes, align them all to be prefixed with > > > > CT_DYNTICKS, as CT_DYNTICKS_MASK already is. > > > > > > > > Signed-off-by: Valentin Schneider <vschneid@redhat.com> > > > > > > It used to be that RCU extended quiescent state and dynticks enter/exit > > > were coupled. But this isn't the case anymore. Nowadays RCU stops watching > > > some time later after dynticks is entered. > > > > I knew that consolidation of atomic operations was too good to last... > > > > > I wonder if we shouldn't take advantage of that cleanup for a meaning that > > > really reflect that RCU stops watching from there. > > > > > > Paul what do you think? CT_EQS_IDX ? CT_RCUEQS_IDX? CT_RCUOFF_IDX? ...? > > > > "After what you just did? You can just RCU off!!!" > > > > Sorry, couldn't resist... > > > > I am having a hard time getting too excited about the name. I could > > suggest CT_RCU_WATCHING_IDX, but that isn't exactly the shortest > > possible name. > > I really like CT_RCU_WATCHING. It says everything. The _IDX isn't even > needed after all. What do you think? Works for me! Thanx, Paul
On 10/04/24 12:19, Paul E. McKenney wrote: > On Wed, Apr 10, 2024 at 12:30:55PM +0200, Frederic Weisbecker wrote: >> Le Tue, Apr 09, 2024 at 12:53:03PM -0700, Paul E. McKenney a écrit : >> > I am having a hard time getting too excited about the name. I could >> > suggest CT_RCU_WATCHING_IDX, but that isn't exactly the shortest >> > possible name. >> >> I really like CT_RCU_WATCHING. It says everything. The _IDX isn't even >> needed after all. What do you think? > > Works for me! > Sounds good to me too, thanks for the suggestion :) Now, what about ct_dynticks() & friends? I was about to do: -static __always_inline int ct_dynticks(void) +static __always_inline int ct_rcu_watching(void) { - return atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_DYNTICKS_MASK; + return atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_RCU_WATCHING_MASK; } ... but then realised that there's more siblings to the rcu_dynticks*() family; AFAICT dynticks_nesting could also get the rcu_watching prefix treatment, `rcu_dynticks_task_exit() -> rcu_watching_task_exit` doesn't sound as obvious though. The rcu_dyntick event probably can't be renamed either. I'm not sure how far to take the renaming; seeing things like: notrace bool rcu_is_watching(void) { bool ret; preempt_disable_notrace(); ret = !rcu_dynticks_curr_cpu_in_eqs(); preempt_enable_notrace(); return ret; } EXPORT_SYMBOL_GPL(rcu_is_watching); makes me think most of the rcu_*dynticks / rcu_*eqs stuff could get an rcu_watching facelift? Here are my current considerations for identifiers used in context_tracking in decreasing order of confidence: | Old | New | |---------------------------------------+---------------------------------------------------------------| | RCU_DYNTICKS_IDX | CT_RCU_WATCHING | | RCU_DYNTICKS_MASK | CT_RCU_WATCHING_MASK | | context_tracking.dynticks_nesting | context_tracking.rcu_watching_nesting | | context_tracking.dynticks_nmi_nesting | context_tracking.rcu_watching_nmi_nesting [bit of a mouthful] | | rcu_dynticks_curr_cpu_in_eqs() | rcu_watching_curr_cpu() [with an added negation] | |---------------------------------------+---------------------------------------------------------------| | TRACE_EVENT_RCU(rcu_dyntick, | [Can't change?] | |---------------------------------------+---------------------------------------------------------------| | rcu_dynticks_task_enter() | rcu_watching_task_enter() | | rcu_dynticks_task_exit() | rcu_watching_task_exit() | | rcu_dynticks_task_trace_enter() | rcu_watching_task_trace_enter() | | rcu_dynticks_task_trace_exit() | rcu_watching_task_trace_exit() | Thoughts?
Le Mon, Apr 15, 2024 at 06:36:31PM +0200, Valentin Schneider a écrit : > On 10/04/24 12:19, Paul E. McKenney wrote: > > On Wed, Apr 10, 2024 at 12:30:55PM +0200, Frederic Weisbecker wrote: > >> Le Tue, Apr 09, 2024 at 12:53:03PM -0700, Paul E. McKenney a écrit : > >> > I am having a hard time getting too excited about the name. I could > >> > suggest CT_RCU_WATCHING_IDX, but that isn't exactly the shortest > >> > possible name. > >> > >> I really like CT_RCU_WATCHING. It says everything. The _IDX isn't even > >> needed after all. What do you think? > > > > Works for me! > > > > Sounds good to me too, thanks for the suggestion :) > > Now, what about ct_dynticks() & friends? I was about to do: > > -static __always_inline int ct_dynticks(void) > +static __always_inline int ct_rcu_watching(void) > { > - return atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_DYNTICKS_MASK; > + return atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_RCU_WATCHING_MASK; > } Yup! > > ... but then realised that there's more siblings to the rcu_dynticks*() > family; Ouch right, sorry I forgot there is so much of this namespace. But in case you're willing to clean that up: > > AFAICT dynticks_nesting could also get the rcu_watching prefix treatment, > `rcu_dynticks_task_exit() -> rcu_watching_task_exit` doesn't sound as rcu_tasks_exit() ? But Paul, is there a reason why check_holdout_task() doesn't check ct_dynticks_cpu(task_cpu(t)) instead of maintaining this separate counter? > obvious though. The rcu_dyntick event probably can't be renamed either. I think we can rename trace_rcu_dyntick() to trace_rcu_watching() > > I'm not sure how far to take the renaming; seeing things like: > > notrace bool rcu_is_watching(void) > { > bool ret; > > preempt_disable_notrace(); > ret = !rcu_dynticks_curr_cpu_in_eqs(); > preempt_enable_notrace(); > return ret; > } > EXPORT_SYMBOL_GPL(rcu_is_watching); > > makes me think most of the rcu_*dynticks / rcu_*eqs stuff could get an > rcu_watching facelift? The eqs part can stay as-is. But the *dynticks* needs an update. > > Here are my current considerations for identifiers used in context_tracking > in decreasing order of confidence: > > | Old | New | > |---------------------------------------+---------------------------------------------------------------| > | RCU_DYNTICKS_IDX | CT_RCU_WATCHING | > | RCU_DYNTICKS_MASK | CT_RCU_WATCHING_MASK | > | context_tracking.dynticks_nesting | context_tracking.rcu_watching_nesting | This can be context_tracking.nesting (and yes one day we might need to lock up context_tracking.nesting and context_tracking.recursion together in a room and see who wins after a day or two). > | context_tracking.dynticks_nmi_nesting | context_tracking.rcu_watching_nmi_nesting [bit of a mouthful] | context_tracking.nmi_nesting > | rcu_dynticks_curr_cpu_in_eqs() | rcu_watching_curr_cpu() [with an added negation] | Nice! > |---------------------------------------+---------------------------------------------------------------| > | TRACE_EVENT_RCU(rcu_dyntick, | [Can't change?] | It can change. Officially trace events aren't ABI. Unoficially I wouldn't dare changing the sched switch trace event but this one is fine. > |---------------------------------------+---------------------------------------------------------------| > | rcu_dynticks_task_enter() | rcu_watching_task_enter()> | | rcu_tasks_enter() ? > | rcu_dynticks_task_exit() | rcu_watching_task_exit() | rcu_tasks_exit() ? > | rcu_dynticks_task_trace_enter() | rcu_watching_task_trace_enter() | rcu_tasks_trace_enter()? > | rcu_dynticks_task_trace_exit() | rcu_watching_task_trace_exit() | rcu_tasks_trace_exit() ? Thanks. > > Thoughts? >
On 15/04/24 23:08, Frederic Weisbecker wrote: > Le Mon, Apr 15, 2024 at 06:36:31PM +0200, Valentin Schneider a écrit : >> >> Sounds good to me too, thanks for the suggestion :) >> >> Now, what about ct_dynticks() & friends? I was about to do: >> >> -static __always_inline int ct_dynticks(void) >> +static __always_inline int ct_rcu_watching(void) >> { >> - return atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_DYNTICKS_MASK; >> + return atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_RCU_WATCHING_MASK; >> } > > Yup! > >> >> ... but then realised that there's more siblings to the rcu_dynticks*() >> family; > > Ouch right, sorry I forgot there is so much of this namespace. But in case you're > willing to clean that up: > While I'm at it, I figure I might as well. >> >> AFAICT dynticks_nesting could also get the rcu_watching prefix treatment, >> `rcu_dynticks_task_exit() -> rcu_watching_task_exit` doesn't sound as > > rcu_tasks_exit() ? > > But Paul, is there a reason why check_holdout_task() doesn't check > ct_dynticks_cpu(task_cpu(t)) instead of maintaining this separate counter? > >> obvious though. The rcu_dyntick event probably can't be renamed either. > > I think we can rename trace_rcu_dyntick() to trace_rcu_watching() > >> >> I'm not sure how far to take the renaming; seeing things like: >> >> notrace bool rcu_is_watching(void) >> { >> bool ret; >> >> preempt_disable_notrace(); >> ret = !rcu_dynticks_curr_cpu_in_eqs(); >> preempt_enable_notrace(); >> return ret; >> } >> EXPORT_SYMBOL_GPL(rcu_is_watching); >> >> makes me think most of the rcu_*dynticks / rcu_*eqs stuff could get an >> rcu_watching facelift? > > The eqs part can stay as-is. But the *dynticks* needs an update. > >> >> Here are my current considerations for identifiers used in context_tracking >> in decreasing order of confidence: >> >> | Old | New | >> |---------------------------------------+---------------------------------------------------------------| >> | RCU_DYNTICKS_IDX | CT_RCU_WATCHING | >> | RCU_DYNTICKS_MASK | CT_RCU_WATCHING_MASK | >> | context_tracking.dynticks_nesting | context_tracking.rcu_watching_nesting | > > This can be context_tracking.nesting (and yes one day we might need to lock up > context_tracking.nesting and context_tracking.recursion together in a room and see > who wins after a day or two). > Much better! >> | context_tracking.dynticks_nmi_nesting | context_tracking.rcu_watching_nmi_nesting [bit of a mouthful] | > > context_tracking.nmi_nesting > >> | rcu_dynticks_curr_cpu_in_eqs() | rcu_watching_curr_cpu() [with an added negation] | > > Nice! > >> |---------------------------------------+---------------------------------------------------------------| >> | TRACE_EVENT_RCU(rcu_dyntick, | [Can't change?] | > > It can change. Officially trace events aren't ABI. Unoficially I wouldn't dare > changing the sched switch trace event but this one is fine. > Cool, away it goes then :) >> |---------------------------------------+---------------------------------------------------------------| >> | rcu_dynticks_task_enter() | rcu_watching_task_enter()> | | > > rcu_tasks_enter() ? > >> | rcu_dynticks_task_exit() | rcu_watching_task_exit() | > > rcu_tasks_exit() ? > >> | rcu_dynticks_task_trace_enter() | rcu_watching_task_trace_enter() | > > rcu_tasks_trace_enter()? > >> | rcu_dynticks_task_trace_exit() | rcu_watching_task_trace_exit() | > > rcu_tasks_trace_exit() ? > Now that you point it out, it looks obvious! > Thanks. > >> >> Thoughts? >>
diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h index 28fcfa1849032..a9c3f2c0e04e3 100644 --- a/include/linux/context_tracking.h +++ b/include/linux/context_tracking.h @@ -119,7 +119,7 @@ extern void ct_idle_exit(void); */ static __always_inline bool rcu_dynticks_curr_cpu_in_eqs(void) { - return !(raw_atomic_read(this_cpu_ptr(&context_tracking.state)) & RCU_DYNTICKS_IDX); + return !(raw_atomic_read(this_cpu_ptr(&context_tracking.state)) & CT_DYNTICKS_IDX); } /* @@ -142,7 +142,7 @@ static __always_inline bool warn_rcu_enter(void) preempt_disable_notrace(); if (rcu_dynticks_curr_cpu_in_eqs()) { ret = true; - ct_state_inc(RCU_DYNTICKS_IDX); + ct_state_inc(CT_DYNTICKS_IDX); } return ret; @@ -151,7 +151,7 @@ static __always_inline bool warn_rcu_enter(void) static __always_inline void warn_rcu_exit(bool rcu) { if (rcu) - ct_state_inc(RCU_DYNTICKS_IDX); + ct_state_inc(CT_DYNTICKS_IDX); preempt_enable_notrace(); } diff --git a/include/linux/context_tracking_state.h b/include/linux/context_tracking_state.h index f1c53125edee2..73af5a13b4fc5 100644 --- a/include/linux/context_tracking_state.h +++ b/include/linux/context_tracking_state.h @@ -19,7 +19,7 @@ enum ctx_state { }; /* Even value for idle, else odd. */ -#define RCU_DYNTICKS_IDX CT_STATE_MAX +#define CT_DYNTICKS_IDX CT_STATE_MAX #define CT_STATE_MASK (CT_STATE_MAX - 1) #define CT_DYNTICKS_MASK (~CT_STATE_MASK) diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c index 21f2cf90ed0bf..586c17fef1327 100644 --- a/kernel/context_tracking.c +++ b/kernel/context_tracking.c @@ -31,7 +31,7 @@ DEFINE_PER_CPU(struct context_tracking, context_tracking) = { .dynticks_nesting = 1, .dynticks_nmi_nesting = DYNTICK_IRQ_NONIDLE, #endif - .state = ATOMIC_INIT(RCU_DYNTICKS_IDX), + .state = ATOMIC_INIT(CT_DYNTICKS_IDX), }; EXPORT_SYMBOL_GPL(context_tracking); @@ -90,7 +90,7 @@ static noinstr void ct_kernel_exit_state(int offset) rcu_dynticks_task_trace_enter(); // Before ->dynticks update! seq = ct_state_inc(offset); // RCU is no longer watching. Better be in extended quiescent state! - WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && (seq & RCU_DYNTICKS_IDX)); + WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && (seq & CT_DYNTICKS_IDX)); } /* @@ -110,7 +110,7 @@ static noinstr void ct_kernel_enter_state(int offset) seq = ct_state_inc(offset); // RCU is now watching. Better not be in an extended quiescent state! rcu_dynticks_task_trace_exit(); // After ->dynticks update! - WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && !(seq & RCU_DYNTICKS_IDX)); + WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && !(seq & CT_DYNTICKS_IDX)); } /* @@ -236,7 +236,7 @@ void noinstr ct_nmi_exit(void) instrumentation_end(); // RCU is watching here ... - ct_kernel_exit_state(RCU_DYNTICKS_IDX); + ct_kernel_exit_state(CT_DYNTICKS_IDX); // ... but is no longer watching here. if (!in_nmi()) @@ -277,7 +277,7 @@ void noinstr ct_nmi_enter(void) rcu_dynticks_task_exit(); // RCU is not watching here ... - ct_kernel_enter_state(RCU_DYNTICKS_IDX); + ct_kernel_enter_state(CT_DYNTICKS_IDX); // ... but is watching here. instrumentation_begin(); @@ -317,7 +317,7 @@ void noinstr ct_nmi_enter(void) void noinstr ct_idle_enter(void) { WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && !raw_irqs_disabled()); - ct_kernel_exit(false, RCU_DYNTICKS_IDX + CT_STATE_IDLE); + ct_kernel_exit(false, CT_DYNTICKS_IDX + CT_STATE_IDLE); } EXPORT_SYMBOL_GPL(ct_idle_enter); @@ -335,7 +335,7 @@ void noinstr ct_idle_exit(void) unsigned long flags; raw_local_irq_save(flags); - ct_kernel_enter(false, RCU_DYNTICKS_IDX - CT_STATE_IDLE); + ct_kernel_enter(false, CT_DYNTICKS_IDX - CT_STATE_IDLE); raw_local_irq_restore(flags); } EXPORT_SYMBOL_GPL(ct_idle_exit); @@ -504,7 +504,7 @@ void noinstr __ct_user_enter(enum ctx_state state) * CPU doesn't need to maintain the tick for RCU maintenance purposes * when the CPU runs in userspace. */ - ct_kernel_exit(true, RCU_DYNTICKS_IDX + state); + ct_kernel_exit(true, CT_DYNTICKS_IDX + state); /* * Special case if we only track user <-> kernel transitions for tickless @@ -534,7 +534,7 @@ void noinstr __ct_user_enter(enum ctx_state state) /* * Tracking for vtime and RCU EQS. Make sure we don't race * with NMIs. OTOH we don't care about ordering here since - * RCU only requires RCU_DYNTICKS_IDX increments to be fully + * RCU only requires CT_DYNTICKS_IDX increments to be fully * ordered. */ raw_atomic_add(state, &ct->state); @@ -620,7 +620,7 @@ void noinstr __ct_user_exit(enum ctx_state state) * Exit RCU idle mode while entering the kernel because it can * run a RCU read side critical section anytime. */ - ct_kernel_enter(true, RCU_DYNTICKS_IDX - state); + ct_kernel_enter(true, CT_DYNTICKS_IDX - state); if (state == CT_STATE_USER) { instrumentation_begin(); vtime_user_exit(current); @@ -644,7 +644,7 @@ void noinstr __ct_user_exit(enum ctx_state state) /* * Tracking for vtime and RCU EQS. Make sure we don't race * with NMIs. OTOH we don't care about ordering here since - * RCU only requires RCU_DYNTICKS_IDX increments to be fully + * RCU only requires CT_DYNTICKS_IDX increments to be fully * ordered. */ raw_atomic_sub(state, &ct->state); diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index d9642dd06c253..3dbdcd12b876e 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -259,9 +259,9 @@ void rcu_softirq_qs(void) */ static void rcu_dynticks_eqs_online(void) { - if (ct_dynticks() & RCU_DYNTICKS_IDX) + if (ct_dynticks() & CT_DYNTICKS_IDX) return; - ct_state_inc(RCU_DYNTICKS_IDX); + ct_state_inc(CT_DYNTICKS_IDX); } /* @@ -280,7 +280,7 @@ static int rcu_dynticks_snap(int cpu) */ static bool rcu_dynticks_in_eqs(int snap) { - return !(snap & RCU_DYNTICKS_IDX); + return !(snap & CT_DYNTICKS_IDX); } /* @@ -302,7 +302,7 @@ bool rcu_dynticks_zero_in_eqs(int cpu, int *vp) int snap; // If not quiescent, force back to earlier extended quiescent state. - snap = ct_dynticks_cpu(cpu) & ~RCU_DYNTICKS_IDX; + snap = ct_dynticks_cpu(cpu) & ~CT_DYNTICKS_IDX; smp_rmb(); // Order ->dynticks and *vp reads. if (READ_ONCE(*vp)) return false; // Non-zero, so report failure; @@ -328,9 +328,9 @@ notrace void rcu_momentary_dyntick_idle(void) int seq; raw_cpu_write(rcu_data.rcu_need_heavy_qs, false); - seq = ct_state_inc(2 * RCU_DYNTICKS_IDX); + seq = ct_state_inc(2 * CT_DYNTICKS_IDX); /* It is illegal to call this from idle state. */ - WARN_ON_ONCE(!(seq & RCU_DYNTICKS_IDX)); + WARN_ON_ONCE(!(seq & CT_DYNTICKS_IDX)); rcu_preempt_deferred_qs(current); } EXPORT_SYMBOL_GPL(rcu_momentary_dyntick_idle);
The symbols relating to the CT_STATE part of context_tracking.state are now all prefixed with CT_STATE. The RCU dynticks counter part of that atomic variable still involves symbols with different prefixes, align them all to be prefixed with CT_DYNTICKS, as CT_DYNTICKS_MASK already is. Signed-off-by: Valentin Schneider <vschneid@redhat.com> --- include/linux/context_tracking.h | 6 +++--- include/linux/context_tracking_state.h | 2 +- kernel/context_tracking.c | 22 +++++++++++----------- kernel/rcu/tree.c | 12 ++++++------ 4 files changed, 21 insertions(+), 21 deletions(-)