Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1348081 > unrolled thread

[PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel Mark Rutland <mark.rutland@arm.com> - 2016-03-02 15:30 +0100
    [PATCH 3/3] arm64: kasan: clear stale stack poison Mark Rutland <mark.rutland@arm.com> - 2016-03-02 15:30 +0100
      Re: [PATCH 3/3] arm64: kasan: clear stale stack poison Mark Rutland <mark.rutland@arm.com> - 2016-03-03 15:20 +0100
        Re: [PATCH 3/3] arm64: kasan: clear stale stack poison Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-03-03 15:40 +0100
    Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Ingo Molnar <mingo@kernel.org> - 2016-03-03 13:10 +0100
      Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Mark Rutland <mark.rutland@arm.com> - 2016-03-03 13:40 +0100
        Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Ingo Molnar <mingo@kernel.org> - 2016-03-03 13:50 +0100
        Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-03-03 15:40 +0100
          Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Mark Rutland <mark.rutland@arm.com> - 2016-03-03 15:50 +0100
            Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-03-03 16:00 +0100
        Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to  kernel Catalin Marinas <catalin.marinas@arm.com> - 2016-03-03 17:20 +0100

#1348081 — [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

Functions which the compiler has instrumented for ASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.

In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
of levels deep in C code. If there are any instrumented functions on
this critical path, these will leave portions of the idle thread stack
shadow poisoned.

If a CPU returns to the kernel via a different path (e.g. a cold entry),
then depending on stack frame layout subsequent calls to instrumented
functions may use regions of the stack with stale poison, resulting in
(spurious) KASAN splats to the console.

Contemporary GCCs always add stack shadow poisoning when ASAN is
enabled, even when asked to not instrument a function [1], so we can't
simply annotate functions on the critical path to avoid poisoning.

Instead, this series explicitly removes any stale poison before it can
be hit. In the common hotplug case we clear the entire stack shadow in
common code, before a CPU is brought online.

On architectures which perform a cold return as part of cpu idle may
retain an architecture-specific amount of stack contents. To retain the
poison for this retained context, the arch code must call the core KASAN
code, passing a "watermark" stack pointer value beyond which shadow will
be cleared. Architectures which don't perform a cold return as part of
idle do not need any additional code.

This is a combination of previous approaches [2,3], attempting to keep
as much as possible generic.

Thanks,
Mark.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409466.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411850.html

Mark Rutland (3):
  kasan: add functions to clear stack poison
  sched/kasan: remove stale KASAN poison after hotplug
  arm64: kasan: clear stale stack poison

 arch/arm64/kernel/sleep.S |  4 ++++
 include/linux/kasan.h     |  6 +++++-
 kernel/sched/core.c       |  3 +++
 mm/kasan/kasan.c          | 20 ++++++++++++++++++++
 4 files changed, 32 insertions(+), 1 deletion(-)

-- 
1.9.1

[toc] | [next] | [standalone]

#1348084 — [PATCH 3/3] arm64: kasan: clear stale stack poison

Functions which the compiler has instrumented for ASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.

In the case of cpuidle, CPUs exit the kernel a number of levels deep
in C code. Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.

If CPUs lose context and return to the kernel via a cold path, we
restore a prior context saved in __cpu_suspend_enter are forgotten, and
we never remove the poison they placed in the stack shadow area by
functions calls between this and the actual exit of the kernel.

Thus, (depending on stackframe layout) subsequent calls to instrumented
functions may hit this stale poison, resulting in (spurious) KASAN
splats to the console.

To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
 arch/arm64/kernel/sleep.S | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index e33fe33..fd10eb6 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -145,6 +145,10 @@ ENTRY(cpu_resume_mmu)
 ENDPROC(cpu_resume_mmu)
 	.popsection
 cpu_resume_after_mmu:
+#ifdef CONFIG_KASAN
+	mov	x0, sp
+	bl	kasan_unpoison_remaining_stack
+#endif
 	mov	x0, #0			// return zero on success
 	ldp	x19, x20, [sp, #16]
 	ldp	x21, x22, [sp, #32]
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1349204 — Re: [PATCH 3/3] arm64: kasan: clear stale stack poison

On Wed, Mar 02, 2016 at 02:26:18PM +0000, Mark Rutland wrote:
> Functions which the compiler has instrumented for ASAN place poison on
> the stack shadow upon entry and remove this poison prior to returning.
> 
> In the case of cpuidle, CPUs exit the kernel a number of levels deep
> in C code. Any instrumented functions on this critical path will leave
> portions of the stack shadow poisoned.
> 
> If CPUs lose context and return to the kernel via a cold path, we
> restore a prior context saved in __cpu_suspend_enter are forgotten, and
> we never remove the poison they placed in the stack shadow area by
> functions calls between this and the actual exit of the kernel.
> 
> Thus, (depending on stackframe layout) subsequent calls to instrumented
> functions may hit this stale poison, resulting in (spurious) KASAN
> splats to the console.
> 
> To avoid this, clear any stale poison from the idle thread for a CPU
> prior to bringing a CPU online.
> 
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm64/kernel/sleep.S | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index e33fe33..fd10eb6 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -145,6 +145,10 @@ ENTRY(cpu_resume_mmu)
>  ENDPROC(cpu_resume_mmu)
>  	.popsection
>  cpu_resume_after_mmu:
> +#ifdef CONFIG_KASAN
> +	mov	x0, sp
> +	bl	kasan_unpoison_remaining_stack
> +#endif

Lorenzo, as this was following your suggestion [1], I hope that this
patch looks ok to you?

Are you happy to provide an Ack / Reviewed-by?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413061.html

[toc] | [prev] | [next] | [standalone]

#1349231 — Re: [PATCH 3/3] arm64: kasan: clear stale stack poison

On Thu, Mar 03, 2016 at 02:14:29PM +0000, Mark Rutland wrote:
> On Wed, Mar 02, 2016 at 02:26:18PM +0000, Mark Rutland wrote:
> > Functions which the compiler has instrumented for ASAN place poison on
> > the stack shadow upon entry and remove this poison prior to returning.
> > 
> > In the case of cpuidle, CPUs exit the kernel a number of levels deep
> > in C code. Any instrumented functions on this critical path will leave
> > portions of the stack shadow poisoned.
> > 
> > If CPUs lose context and return to the kernel via a cold path, we
> > restore a prior context saved in __cpu_suspend_enter are forgotten, and
> > we never remove the poison they placed in the stack shadow area by
> > functions calls between this and the actual exit of the kernel.
> > 
> > Thus, (depending on stackframe layout) subsequent calls to instrumented
> > functions may hit this stale poison, resulting in (spurious) KASAN
> > splats to the console.
> > 
> > To avoid this, clear any stale poison from the idle thread for a CPU
> > prior to bringing a CPU online.
> > 
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/arm64/kernel/sleep.S | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> > index e33fe33..fd10eb6 100644
> > --- a/arch/arm64/kernel/sleep.S
> > +++ b/arch/arm64/kernel/sleep.S
> > @@ -145,6 +145,10 @@ ENTRY(cpu_resume_mmu)
> >  ENDPROC(cpu_resume_mmu)
> >  	.popsection
> >  cpu_resume_after_mmu:
> > +#ifdef CONFIG_KASAN
> > +	mov	x0, sp
> > +	bl	kasan_unpoison_remaining_stack
> > +#endif
> 
> Lorenzo, as this was following your suggestion [1], I hope that this
> patch looks ok to you?
> 
> Are you happy to provide an Ack / Reviewed-by?

Yes sure, thanks for putting it together:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

[toc] | [prev] | [next] | [standalone]

#1349078 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

* Mark Rutland <mark.rutland@arm.com> wrote:

> Functions which the compiler has instrumented for ASAN place poison on
> the stack shadow upon entry and remove this poison prior to returning.
> 
> In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
> of levels deep in C code. If there are any instrumented functions on
> this critical path, these will leave portions of the idle thread stack
> shadow poisoned.
> 
> If a CPU returns to the kernel via a different path (e.g. a cold entry),
> then depending on stack frame layout subsequent calls to instrumented
> functions may use regions of the stack with stale poison, resulting in
> (spurious) KASAN splats to the console.
> 
> Contemporary GCCs always add stack shadow poisoning when ASAN is
> enabled, even when asked to not instrument a function [1], so we can't
> simply annotate functions on the critical path to avoid poisoning.
> 
> Instead, this series explicitly removes any stale poison before it can
> be hit. In the common hotplug case we clear the entire stack shadow in
> common code, before a CPU is brought online.
> 
> On architectures which perform a cold return as part of cpu idle may
> retain an architecture-specific amount of stack contents. To retain the
> poison for this retained context, the arch code must call the core KASAN
> code, passing a "watermark" stack pointer value beyond which shadow will
> be cleared. Architectures which don't perform a cold return as part of
> idle do not need any additional code.
> 
> This is a combination of previous approaches [2,3], attempting to keep
> as much as possible generic.
> 
> Thanks,
> Mark.
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409466.html
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411850.html
> 
> Mark Rutland (3):
>   kasan: add functions to clear stack poison
>   sched/kasan: remove stale KASAN poison after hotplug
>   arm64: kasan: clear stale stack poison
> 
>  arch/arm64/kernel/sleep.S |  4 ++++
>  include/linux/kasan.h     |  6 +++++-
>  kernel/sched/core.c       |  3 +++
>  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
>  4 files changed, 32 insertions(+), 1 deletion(-)

Looks good to me - via which tree would you like to see this merged upstream?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1349105 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
> 
> * Mark Rutland <mark.rutland@arm.com> wrote:
> 
> > Functions which the compiler has instrumented for ASAN place poison on
> > the stack shadow upon entry and remove this poison prior to returning.
> > 
> > In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
> > of levels deep in C code. If there are any instrumented functions on
> > this critical path, these will leave portions of the idle thread stack
> > shadow poisoned.
> > 
> > If a CPU returns to the kernel via a different path (e.g. a cold entry),
> > then depending on stack frame layout subsequent calls to instrumented
> > functions may use regions of the stack with stale poison, resulting in
> > (spurious) KASAN splats to the console.
> > 
> > Contemporary GCCs always add stack shadow poisoning when ASAN is
> > enabled, even when asked to not instrument a function [1], so we can't
> > simply annotate functions on the critical path to avoid poisoning.
> > 
> > Instead, this series explicitly removes any stale poison before it can
> > be hit. In the common hotplug case we clear the entire stack shadow in
> > common code, before a CPU is brought online.
> > 
> > On architectures which perform a cold return as part of cpu idle may
> > retain an architecture-specific amount of stack contents. To retain the
> > poison for this retained context, the arch code must call the core KASAN
> > code, passing a "watermark" stack pointer value beyond which shadow will
> > be cleared. Architectures which don't perform a cold return as part of
> > idle do not need any additional code.
> > 
> > This is a combination of previous approaches [2,3], attempting to keep
> > as much as possible generic.
> > 
> > Thanks,
> > Mark.
> > 
> > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
> > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409466.html
> > [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411850.html
> > 
> > Mark Rutland (3):
> >   kasan: add functions to clear stack poison
> >   sched/kasan: remove stale KASAN poison after hotplug
> >   arm64: kasan: clear stale stack poison
> > 
> >  arch/arm64/kernel/sleep.S |  4 ++++
> >  include/linux/kasan.h     |  6 +++++-
> >  kernel/sched/core.c       |  3 +++
> >  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
> >  4 files changed, 32 insertions(+), 1 deletion(-)
> 
> Looks good to me - via which tree would you like to see this merged upstream?

I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
in practice.

I'm happy for this to go via another tree if that's simpler; I'm not
aware of anything that's likely to conflict in the arm64 tree.

Catalin, Andrey, Andrew, any preference?

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1349112 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

* Mark Rutland <mark.rutland@arm.com> wrote:

> On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
> > 
> > * Mark Rutland <mark.rutland@arm.com> wrote:
> > 
> > > Functions which the compiler has instrumented for ASAN place poison on
> > > the stack shadow upon entry and remove this poison prior to returning.
> > > 
> > > In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
> > > of levels deep in C code. If there are any instrumented functions on
> > > this critical path, these will leave portions of the idle thread stack
> > > shadow poisoned.
> > > 
> > > If a CPU returns to the kernel via a different path (e.g. a cold entry),
> > > then depending on stack frame layout subsequent calls to instrumented
> > > functions may use regions of the stack with stale poison, resulting in
> > > (spurious) KASAN splats to the console.
> > > 
> > > Contemporary GCCs always add stack shadow poisoning when ASAN is
> > > enabled, even when asked to not instrument a function [1], so we can't
> > > simply annotate functions on the critical path to avoid poisoning.
> > > 
> > > Instead, this series explicitly removes any stale poison before it can
> > > be hit. In the common hotplug case we clear the entire stack shadow in
> > > common code, before a CPU is brought online.
> > > 
> > > On architectures which perform a cold return as part of cpu idle may
> > > retain an architecture-specific amount of stack contents. To retain the
> > > poison for this retained context, the arch code must call the core KASAN
> > > code, passing a "watermark" stack pointer value beyond which shadow will
> > > be cleared. Architectures which don't perform a cold return as part of
> > > idle do not need any additional code.
> > > 
> > > This is a combination of previous approaches [2,3], attempting to keep
> > > as much as possible generic.
> > > 
> > > Thanks,
> > > Mark.
> > > 
> > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
> > > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409466.html
> > > [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411850.html
> > > 
> > > Mark Rutland (3):
> > >   kasan: add functions to clear stack poison
> > >   sched/kasan: remove stale KASAN poison after hotplug
> > >   arm64: kasan: clear stale stack poison
> > > 
> > >  arch/arm64/kernel/sleep.S |  4 ++++
> > >  include/linux/kasan.h     |  6 +++++-
> > >  kernel/sched/core.c       |  3 +++
> > >  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
> > >  4 files changed, 32 insertions(+), 1 deletion(-)
> > 
> > Looks good to me - via which tree would you like to see this merged upstream?
> 
> I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
> in practice.
> 
> I'm happy for this to go via another tree if that's simpler; I'm not
> aware of anything that's likely to conflict in the arm64 tree.
> 
> Catalin, Andrey, Andrew, any preference?

Ok, for the scheduler bits:

  Reviewed-by: Ingo Molnar <mingo@kernel.org>

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1349232 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On 03/03/2016 03:38 PM, Mark Rutland wrote:
> On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
>>>
>>> Mark Rutland (3):
>>>   kasan: add functions to clear stack poison
>>>   sched/kasan: remove stale KASAN poison after hotplug
>>>   arm64: kasan: clear stale stack poison
>>>
>>>  arch/arm64/kernel/sleep.S |  4 ++++
>>>  include/linux/kasan.h     |  6 +++++-
>>>  kernel/sched/core.c       |  3 +++
>>>  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
>>>  4 files changed, 32 insertions(+), 1 deletion(-)
>>
>> Looks good to me - via which tree would you like to see this merged upstream?
> 
> I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
> in practice.
> 
> I'm happy for this to go via another tree if that's simpler; I'm not
> aware of anything that's likely to conflict in the arm64 tree.
> 
> Catalin, Andrey, Andrew, any preference?
> 

I don't have any. arm64 tree is fine by me.

For the patchset:

	Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>

[toc] | [prev] | [next] | [standalone]

#1349244 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On Thu, Mar 03, 2016 at 05:30:17PM +0300, Andrey Ryabinin wrote:
> On 03/03/2016 03:38 PM, Mark Rutland wrote:
> > On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
> >>>
> >>> Mark Rutland (3):
> >>>   kasan: add functions to clear stack poison
> >>>   sched/kasan: remove stale KASAN poison after hotplug
> >>>   arm64: kasan: clear stale stack poison
> >>>
> >>>  arch/arm64/kernel/sleep.S |  4 ++++
> >>>  include/linux/kasan.h     |  6 +++++-
> >>>  kernel/sched/core.c       |  3 +++
> >>>  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
> >>>  4 files changed, 32 insertions(+), 1 deletion(-)
> >>
> >> Looks good to me - via which tree would you like to see this merged upstream?
> > 
> > I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
> > in practice.
> > 
> > I'm happy for this to go via another tree if that's simpler; I'm not
> > aware of anything that's likely to conflict in the arm64 tree.
> > 
> > Catalin, Andrey, Andrew, any preference?
> > 
> 
> I don't have any. arm64 tree is fine by me.
> 
> For the patchset:
> 
> 	Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> 

Cheers!

Following [1], I intend to change patch 1 to start at task_stack_page(t)
rather than task_thread_info(task) + 1, to keep things simple.

I assume that your Reviewed-by would still apply in that case?

Thanks,
Mark.

[1] https://lkml.org/lkml/2016/3/2/428

[toc] | [prev] | [next] | [standalone]

#1349259 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On 03/03/2016 05:49 PM, Mark Rutland wrote:
> On Thu, Mar 03, 2016 at 05:30:17PM +0300, Andrey Ryabinin wrote:
>> On 03/03/2016 03:38 PM, Mark Rutland wrote:
>>> On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
>>>>>
>>>>> Mark Rutland (3):
>>>>>   kasan: add functions to clear stack poison
>>>>>   sched/kasan: remove stale KASAN poison after hotplug
>>>>>   arm64: kasan: clear stale stack poison
>>>>>
>>>>>  arch/arm64/kernel/sleep.S |  4 ++++
>>>>>  include/linux/kasan.h     |  6 +++++-
>>>>>  kernel/sched/core.c       |  3 +++
>>>>>  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
>>>>>  4 files changed, 32 insertions(+), 1 deletion(-)
>>>>
>>>> Looks good to me - via which tree would you like to see this merged upstream?
>>>
>>> I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
>>> in practice.
>>>
>>> I'm happy for this to go via another tree if that's simpler; I'm not
>>> aware of anything that's likely to conflict in the arm64 tree.
>>>
>>> Catalin, Andrey, Andrew, any preference?
>>>
>>
>> I don't have any. arm64 tree is fine by me.
>>
>> For the patchset:
>>
>> 	Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>>
> 
> Cheers!
> 
> Following [1], I intend to change patch 1 to start at task_stack_page(t)
> rather than task_thread_info(task) + 1, to keep things simple.
> 
> I assume that your Reviewed-by would still apply in that case?
> 

Sure.

> Thanks,
> Mark.
> 
> [1] https://lkml.org/lkml/2016/3/2/428
> 

[toc] | [prev] | [next] | [standalone]

#1349331 — Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

On Thu, Mar 03, 2016 at 12:38:09PM +0000, Mark Rutland wrote:
> On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > > Mark Rutland (3):
> > >   kasan: add functions to clear stack poison
> > >   sched/kasan: remove stale KASAN poison after hotplug
> > >   arm64: kasan: clear stale stack poison
> > > 
> > >  arch/arm64/kernel/sleep.S |  4 ++++
> > >  include/linux/kasan.h     |  6 +++++-
> > >  kernel/sched/core.c       |  3 +++
> > >  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
> > >  4 files changed, 32 insertions(+), 1 deletion(-)
> > 
> > Looks good to me - via which tree would you like to see this merged upstream?
> 
> I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
> in practice.
> 
> I'm happy for this to go via another tree if that's simpler; I'm not
> aware of anything that's likely to conflict in the arm64 tree.
> 
> Catalin, Andrey, Andrew, any preference?

I'm happy for this to go via the Andrew's -mm tree. For the series:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

Please report the series to linux-mm@kvack.org with the corresponding
acks in place and the fix-up on patch 1.

Thanks.

-- 
Catalin

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web