We currently set a TIF flag when scheduling out a task that is in
lazy MMU mode, in order to restore it when the task is scheduled
again.
The generic lazy_mmu layer now tracks whether a task is in lazy MMU
mode in task_struct::lazy_mmu_state. We can therefore check that
state when switching to the new task, instead of using a separate
TIF flag.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
arch/x86/include/asm/thread_info.h | 4 +---
arch/x86/xen/enlighten_pv.c | 3 +--
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index e71e0e8362ed..0067684afb5b 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -100,8 +100,7 @@ struct thread_info {
#define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
#define TIF_SINGLESTEP 25 /* reenable singlestep on user return*/
#define TIF_BLOCKSTEP 26 /* set when we want DEBUGCTLMSR_BTF */
-#define TIF_LAZY_MMU_UPDATES 27 /* task is updating the mmu lazily */
-#define TIF_ADDR32 28 /* 32-bit address space on 64 bits */
+#define TIF_ADDR32 27 /* 32-bit address space on 64 bits */
#define _TIF_SSBD BIT(TIF_SSBD)
#define _TIF_SPEC_IB BIT(TIF_SPEC_IB)
@@ -114,7 +113,6 @@ struct thread_info {
#define _TIF_FORCED_TF BIT(TIF_FORCED_TF)
#define _TIF_BLOCKSTEP BIT(TIF_BLOCKSTEP)
#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
-#define _TIF_LAZY_MMU_UPDATES BIT(TIF_LAZY_MMU_UPDATES)
#define _TIF_ADDR32 BIT(TIF_ADDR32)
/* flags to check in __switch_to() */
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4806cc28d7ca..f40f5999352e 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -426,7 +426,6 @@ static void xen_start_context_switch(struct task_struct *prev)
if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) {
arch_leave_lazy_mmu_mode();
- set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES);
}
enter_lazy(XEN_LAZY_CPU);
}
@@ -437,7 +436,7 @@ static void xen_end_context_switch(struct task_struct *next)
xen_mc_flush();
leave_lazy(XEN_LAZY_CPU);
- if (test_and_clear_ti_thread_flag(task_thread_info(next), TIF_LAZY_MMU_UPDATES))
+ if (next->lazy_mmu_state.active)
arch_enter_lazy_mmu_mode();
}
--
2.47.0On 29.10.25 11:09, Kevin Brodsky wrote:
> We currently set a TIF flag when scheduling out a task that is in
> lazy MMU mode, in order to restore it when the task is scheduled
> again.
>
> The generic lazy_mmu layer now tracks whether a task is in lazy MMU
> mode in task_struct::lazy_mmu_state. We can therefore check that
> state when switching to the new task, instead of using a separate
> TIF flag.
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
> arch/x86/include/asm/thread_info.h | 4 +---
> arch/x86/xen/enlighten_pv.c | 3 +--
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
> index e71e0e8362ed..0067684afb5b 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -100,8 +100,7 @@ struct thread_info {
> #define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
> #define TIF_SINGLESTEP 25 /* reenable singlestep on user return*/
> #define TIF_BLOCKSTEP 26 /* set when we want DEBUGCTLMSR_BTF */
> -#define TIF_LAZY_MMU_UPDATES 27 /* task is updating the mmu lazily */
> -#define TIF_ADDR32 28 /* 32-bit address space on 64 bits */
> +#define TIF_ADDR32 27 /* 32-bit address space on 64 bits */
>
> #define _TIF_SSBD BIT(TIF_SSBD)
> #define _TIF_SPEC_IB BIT(TIF_SPEC_IB)
> @@ -114,7 +113,6 @@ struct thread_info {
> #define _TIF_FORCED_TF BIT(TIF_FORCED_TF)
> #define _TIF_BLOCKSTEP BIT(TIF_BLOCKSTEP)
> #define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> -#define _TIF_LAZY_MMU_UPDATES BIT(TIF_LAZY_MMU_UPDATES)
> #define _TIF_ADDR32 BIT(TIF_ADDR32)
>
> /* flags to check in __switch_to() */
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 4806cc28d7ca..f40f5999352e 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -426,7 +426,6 @@ static void xen_start_context_switch(struct task_struct *prev)
>
> if (this_cpu_read(xen_lazy_mode) == XEN_LAZY_MMU) {
> arch_leave_lazy_mmu_mode();
> - set_ti_thread_flag(task_thread_info(prev), TIF_LAZY_MMU_UPDATES);
> }
> enter_lazy(XEN_LAZY_CPU);
> }
> @@ -437,7 +436,7 @@ static void xen_end_context_switch(struct task_struct *next)
>
> xen_mc_flush();
> leave_lazy(XEN_LAZY_CPU);
> - if (test_and_clear_ti_thread_flag(task_thread_info(next), TIF_LAZY_MMU_UPDATES))
> + if (next->lazy_mmu_state.active)
This is nasty. If in_lazy_mmu_mode() is not sufficient, we will want to
have a separate helper that makes it clear what the difference between
both variants is.
--
Cheers
David
On 03/11/2025 16:15, David Hildenbrand (Red Hat) wrote: > On 29.10.25 11:09, Kevin Brodsky wrote: >> [...] >> >> @@ -437,7 +436,7 @@ static void xen_end_context_switch(struct >> task_struct *next) >> xen_mc_flush(); >> leave_lazy(XEN_LAZY_CPU); >> - if (test_and_clear_ti_thread_flag(task_thread_info(next), >> TIF_LAZY_MMU_UPDATES)) >> + if (next->lazy_mmu_state.active) > > This is nasty. If in_lazy_mmu_mode() is not sufficient, we will want > to have a separate helper that makes it clear what the difference > between both variants is. in_lazy_mmu_mode() operates on current, but here we're operating on a different task. The difference is more fundamental than just passing a task_struct * or not: in_lazy_mmu_mode() is about whether we're currently in lazy MMU mode, i.e. not paused and not in interrupt context. A task that isn't scheduled is never in lazy MMU mode - lazy_mmu_state.active is just the saved state to be restored when scheduled again. My point here is that we could have a helper for this use-case, but it should not be used in other situations (at least not on current). Maybe __task_lazy_mmu_active(task)? I do wonder if accessing lazy_mmu_state directly isn't expressing the intention well enough though (checking the saved state). - Kevin
On 03.11.25 19:29, Kevin Brodsky wrote:
> On 03/11/2025 16:15, David Hildenbrand (Red Hat) wrote:
>> On 29.10.25 11:09, Kevin Brodsky wrote:
>>> [...]
>>>
>>> @@ -437,7 +436,7 @@ static void xen_end_context_switch(struct
>>> task_struct *next)
>>> xen_mc_flush();
>>> leave_lazy(XEN_LAZY_CPU);
>>> - if (test_and_clear_ti_thread_flag(task_thread_info(next),
>>> TIF_LAZY_MMU_UPDATES))
>>> + if (next->lazy_mmu_state.active)
>>
>> This is nasty. If in_lazy_mmu_mode() is not sufficient, we will want
>> to have a separate helper that makes it clear what the difference
>> between both variants is.
>
> in_lazy_mmu_mode() operates on current, but here we're operating on a
> different task. The difference is more fundamental than just passing a
> task_struct * or not: in_lazy_mmu_mode() is about whether we're
> currently in lazy MMU mode, i.e. not paused and not in interrupt
> context. A task that isn't scheduled is never in lazy MMU mode -
> lazy_mmu_state.active is just the saved state to be restored when
> scheduled again.
>
> My point here is that we could have a helper for this use-case, but it
> should not be used in other situations (at least not on current). Maybe
> __task_lazy_mmu_active(task)? I do wonder if accessing lazy_mmu_state
> directly isn't expressing the intention well enough though (checking the
> saved state).
Likely there should be a
/**
* task_lazy_mmu_active - test whether the lazy-mmu mode is active for a
* task
* @task: ...
*
* The lazy-mmu mode is active if a task has lazy-mmu mode enabled and
* currently not paused.
*/
static inline bool task_lazy_mmu_active(struct task_struct *task)
{
return task->lazy_mmu_state.active;
}
/**
* in_lazy_mmu_mode() - test whether current is in lazy-mmu mode
*
* Test whether the current task is in lazy-mmu mode: whether the
* interrupts are enabled and the lazy-mmu mode is active for the
* current task.
*/
static inline bool in_lazy_mmu_mode(void)
{
+ if (in_interrupt())
+ return false;
+
return task_lazy_mmu_active(current);
}
Something like that. Maybe we can find better terminology.
--
Cheers
David
On 03/11/2025 19:23, David Hildenbrand (Red Hat) wrote:
> On 03.11.25 19:29, Kevin Brodsky wrote:
>> On 03/11/2025 16:15, David Hildenbrand (Red Hat) wrote:
>>> On 29.10.25 11:09, Kevin Brodsky wrote:
>>>> [...]
>>>>
>>>> @@ -437,7 +436,7 @@ static void xen_end_context_switch(struct
>>>> task_struct *next)
>>>> xen_mc_flush();
>>>> leave_lazy(XEN_LAZY_CPU);
>>>> - if (test_and_clear_ti_thread_flag(task_thread_info(next),
>>>> TIF_LAZY_MMU_UPDATES))
>>>> + if (next->lazy_mmu_state.active)
>>>
>>> This is nasty. If in_lazy_mmu_mode() is not sufficient, we will want
>>> to have a separate helper that makes it clear what the difference
>>> between both variants is.
>>
>> in_lazy_mmu_mode() operates on current, but here we're operating on a
>> different task. The difference is more fundamental than just passing a
>> task_struct * or not: in_lazy_mmu_mode() is about whether we're
>> currently in lazy MMU mode, i.e. not paused and not in interrupt
>> context. A task that isn't scheduled is never in lazy MMU mode -
>> lazy_mmu_state.active is just the saved state to be restored when
>> scheduled again.
>>
>> My point here is that we could have a helper for this use-case, but it
>> should not be used in other situations (at least not on current). Maybe
>> __task_lazy_mmu_active(task)? I do wonder if accessing lazy_mmu_state
>> directly isn't expressing the intention well enough though (checking the
>> saved state).
>
>
> Likely there should be a
>
> /**
> * task_lazy_mmu_active - test whether the lazy-mmu mode is active for a
> * task
> * @task: ...
> *
> * The lazy-mmu mode is active if a task has lazy-mmu mode enabled and
> * currently not paused.
> */
> static inline bool task_lazy_mmu_active(struct task_struct *task)
> {
> return task->lazy_mmu_state.active;
> }
>
> /**
> * in_lazy_mmu_mode() - test whether current is in lazy-mmu mode
> *
> * Test whether the current task is in lazy-mmu mode: whether the
> * interrupts are enabled and the lazy-mmu mode is active for the
> * current task.
> */
> static inline bool in_lazy_mmu_mode(void)
> {
> + if (in_interrupt())
> + return false;
> +
> return task_lazy_mmu_active(current);
> }
>
>
> Something like that. Maybe we can find better terminology.
That's probably the clearest yes, will make the change. I can't think of
more self-documenting names, spelling out the difference in the comments
is likely the best we can do.
- Kevin
© 2016 - 2025 Red Hat, Inc.