| Message ID | 20210914121036.3975026-2-ardb@kernel.org (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | Move task_struct::cpu back into thread_info | expand |
On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel <ardb@kernel.org> wrote: > > The CPU field will be moved back into thread_info even when > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of > struct thread_info. The series looks sane to me, but it strikes me that it's inconsistent - here for arm64, you make it unconditional, but for the other architectures you end up putting it inside a #ifdef CONFIG_SMP. Was there some reason for this odd behavior? Linus
On Tue, 14 Sept 2021 at 17:41, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Tue, Sep 14, 2021 at 5:10 AM Ard Biesheuvel <ardb@kernel.org> wrote: > > > > The CPU field will be moved back into thread_info even when > > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of > > struct thread_info. > > The series looks sane to me, but it strikes me that it's inconsistent > - here for arm64, you make it unconditional, but for the other > architectures you end up putting it inside a #ifdef CONFIG_SMP. > > Was there some reason for this odd behavior? > Yes. CONFIG_SMP is a 'def_bool y' on arm64.
On Tue, Sep 14, 2021 at 02:10:29PM +0200, Ard Biesheuvel wrote: > The CPU field will be moved back into thread_info even when > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of > struct thread_info. > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
On Thu, 16 Sept 2021 at 16:41, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Tue, Sep 14, 2021 at 02:10:29PM +0200, Ard Biesheuvel wrote: > > The CPU field will be moved back into thread_info even when > > THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of > > struct thread_info. > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> Thanks. I take it this applies to patch #5 as well?
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 6623c99f0984..c02bc8c183c3 100644 --- a/arch/arm64/include/asm/thread_info.h +++ b/arch/arm64/include/asm/thread_info.h @@ -42,6 +42,7 @@ struct thread_info { void *scs_base; void *scs_sp; #endif + u32 cpu; }; #define thread_saved_pc(tsk) \ diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 551427ae8cc5..cee9f3e9f906 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -29,6 +29,7 @@ int main(void) DEFINE(TSK_ACTIVE_MM, offsetof(struct task_struct, active_mm)); DEFINE(TSK_CPU, offsetof(struct task_struct, cpu)); BLANK(); + DEFINE(TSK_TI_CPU, offsetof(struct task_struct, thread_info.cpu)); DEFINE(TSK_TI_FLAGS, offsetof(struct task_struct, thread_info.flags)); DEFINE(TSK_TI_PREEMPT, offsetof(struct task_struct, thread_info.preempt_count)); #ifdef CONFIG_ARM64_SW_TTBR0_PAN
The CPU field will be moved back into thread_info even when THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of struct thread_info. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/kernel/asm-offsets.c | 1 + 2 files changed, 2 insertions(+)