mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v14 07/12] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK
Date: Thu, 24 Jan 2019 17:18:15 +0000	[thread overview]
Message-ID: <20190124171814.GD5531@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <067ad3f669bdf5ad562186e9875b588f25732406.1548346225.git.christophe.leroy@c-s.fr>

On Thu, Jan 24, 2019 at 04:19:43PM +0000, Christophe Leroy wrote:
> This patch activates CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
> 
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of stack
> overflows.
> - Its address is harder to determine if stack addresses are
> leaked, making a number of attacks more difficult.
> 
> This has the following consequences:
> - thread_info is now located at the beginning of task_struct.
> - The 'cpu' field is now in task_struct, and only exists when
> CONFIG_SMP is active.
> - thread_info doesn't have anymore the 'task' field.
> 
> This patch:
> - Removes all recopy of thread_info struct when the stack changes.
> - Changes the CURRENT_THREAD_INFO() macro to point to current.
> - Selects CONFIG_THREAD_INFO_IN_TASK.
> - Modifies raw_smp_processor_id() to get ->cpu from current without
> including linux/sched.h to avoid circular inclusion and without
> including asm/asm-offsets.h to avoid symbol names duplication
> between ASM constants and C constants.
> - Modifies klp_init_thread_info() to take a task_struct pointer
> argument.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>

[...]

> +ifdef CONFIG_SMP
> +prepare: task_cpu_prepare
> +
> +task_cpu_prepare: prepare0
> +	$(eval KBUILD_CFLAGS += -D_TASK_CPU=$(shell awk '{if ($$2 == "TI_CPU") print $$3;}' include/generated/asm-offsets.h))
> +endif

[...]

> -#define raw_smp_processor_id()	(current_thread_info()->cpu)
> +/*
> + * This is particularly ugly: it appears we can't actually get the definition
> + * of task_struct here, but we need access to the CPU this task is running on.
> + * Instead of using task_struct we're using _TASK_CPU which is extracted from
> + * asm-offsets.h by kbuild to get the current processor ID.
> + *
> + * This also needs to be safeguarded when building asm-offsets.s because at
> + * that time _TASK_CPU is not defined yet. It could have been guarded by
> + * _TASK_CPU itself, but we want the build to fail if _TASK_CPU is missing
> + * when building something else than asm-offsets.s
> + */
> +#ifdef GENERATING_ASM_OFFSETS
> +#define raw_smp_processor_id()		(0)
> +#else
> +#define raw_smp_processor_id()		(*(unsigned int *)((void *)current + _TASK_CPU))
> +#endif
>  #define hard_smp_processor_id() 	(smp_hw_index[smp_processor_id()])

On arm64 we have the per-cpu offset in a CPU register (TPIDR_EL1), so we
can do:

DEFINE_PER_CPU_READ_MOSTLY(int, cpu_number);

#define raw_smp_processor_id() (*raw_cpu_ptr(&cpu_number))

... but I guess that's not possible on PPC for some reason?

I think I asked that before, but I couldn't find the thread.

Otherwise, this all looks sound to me, but I don't know much about PPC.

Thanks,
Mark.

  reply	other threads:[~2019-01-24 17:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 16:19 [PATCH v14 00/12] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 01/12] powerpc/32: Fix CONFIG_VIRT_CPU_ACCOUNTING_NATIVE for 40x/booke Christophe Leroy
2019-01-30  8:08   ` Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 02/12] powerpc/irq: use memblock functions returning virtual address Christophe Leroy
2019-01-24 16:51   ` Mark Rutland
2019-01-24 17:25     ` Mike Rapoport
2019-01-24 17:28       ` Mark Rutland
2019-01-24 16:19 ` [PATCH v14 03/12] book3s/64: avoid circular header inclusion in mmu-hash.h Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 04/12] powerpc: Only use task_struct 'cpu' field on SMP Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 05/12] powerpc: prep stack walkers for THREAD_INFO_IN_TASK Christophe Leroy
2019-01-24 17:04   ` Mark Rutland
2019-01-24 16:19 ` [PATCH v14 06/12] powerpc: Prepare for moving thread_info into task_struct Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 07/12] powerpc: Activate CONFIG_THREAD_INFO_IN_TASK Christophe Leroy
2019-01-24 17:18   ` Mark Rutland [this message]
2019-01-24 16:19 ` [PATCH v14 08/12] powerpc: regain entire stack space Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 09/12] powerpc: 'current_set' is now a table of task_struct pointers Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 10/12] powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 11/12] powerpc/64: Remove CURRENT_THREAD_INFO Christophe Leroy
2019-01-24 16:19 ` [PATCH v14 12/12] powerpc: clean stack pointers naming Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190124171814.GD5531@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=rppt@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®