Re: [PATCH] Prefer kASLR over Hibernation

On 11/04/16 19:03, Kees Cook wrote: > On Mon, Apr 11, 2016 at 1:00 AM, James Morse <james.mo...@arm.com> wrote: >> On 06/04/16 20:44, Kees Cook wrote: >>> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, >>> one or the other must be chosen at

Re: [PATCH] Prefer kASLR over Hibernation

On 11/04/16 19:03, Kees Cook wrote: > On Mon, Apr 11, 2016 at 1:00 AM, James Morse wrote: >> On 06/04/16 20:44, Kees Cook wrote: >>> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, >>> one or the other must be chosen at boot-time. Until now, hibern

Re: [PATCH] Prefer kASLR over Hibernation

Hi Kees, On 06/04/16 20:44, Kees Cook wrote: > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, > one or the other must be chosen at boot-time. Until now, hibernation > was selected when no choice was made on the command line. > > To make the security benefits of kASLR more

Re: [PATCH] Prefer kASLR over Hibernation

Hi Kees, On 06/04/16 20:44, Kees Cook wrote: > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE, > one or the other must be chosen at boot-time. Until now, hibernation > was selected when no choice was made on the command line. > > To make the security benefits of kASLR more

Re: [PATCH 5/5] arm64: Fix behavior of maxcpus=N

Hi Suzuki, On 06/04/16 12:24, Suzuki K Poulose wrote: > maxcpu=n sets the number of CPUs activated at boot time to a max of n, > but allowing the remaining CPUs to be brought up later if the user > decides to do so. However, on arm64 due to various reasons, we disallowed > hotplugging CPUs beyond

Re: [PATCH 5/5] arm64: Fix behavior of maxcpus=N

Hi Suzuki, On 06/04/16 12:24, Suzuki K Poulose wrote: > maxcpu=n sets the number of CPUs activated at boot time to a max of n, > but allowing the remaining CPUs to be brought up later if the user > decides to do so. However, on arm64 due to various reasons, we disallowed > hotplugging CPUs beyond

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi Pratyush, On 18/03/16 13:29, Pratyush Anand wrote: > Probably, I can see why does not it work. So, when we are single stepping an > instruction and page fault occurs, we will come to el1_da in entry.S. Here, we > do enable_dbg. As soon as we will do this, we will start receiving single step >

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi Pratyush, On 18/03/16 13:29, Pratyush Anand wrote: > Probably, I can see why does not it work. So, when we are single stepping an > instruction and page fault occurs, we will come to el1_da in entry.S. Here, we > do enable_dbg. As soon as we will do this, we will start receiving single step >

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi Pratyush, On 18/03/16 14:43, Pratyush Anand wrote: > On 18/03/2016:02:02:49 PM, James Morse wrote: >> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the >> thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore >> the

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi Pratyush, On 18/03/16 14:43, Pratyush Anand wrote: > On 18/03/2016:02:02:49 PM, James Morse wrote: >> In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the >> thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore >> the

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi Pratyush, On 16/03/16 05:43, Pratyush Anand wrote: > On 15/03/2016:06:47:52 PM, James Morse wrote: >> If I understand this correctly - you can't kprobe these ldr/str instructions >> as the fault handler wouldn't find kprobe's out-of line version of the >> instruction i

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi Pratyush, On 16/03/16 05:43, Pratyush Anand wrote: > On 15/03/2016:06:47:52 PM, James Morse wrote: >> If I understand this correctly - you can't kprobe these ldr/str instructions >> as the fault handler wouldn't find kprobe's out-of line version of the >> instruction i

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi David, On 09/03/16 05:32, David Long wrote: > From: "David A. Long" > diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S > index 4699cd7..0ac2131 100644 > --- a/arch/arm64/lib/copy_from_user.S > +++ b/arch/arm64/lib/copy_from_user.S > @@ -66,6

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

Hi David, On 09/03/16 05:32, David Long wrote: > From: "David A. Long" > diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S > index 4699cd7..0ac2131 100644 > --- a/arch/arm64/lib/copy_from_user.S > +++ b/arch/arm64/lib/copy_from_user.S > @@ -66,6 +66,7 @@ >

Re: linux-next: Tree for Mar 14

Hi Guenter, On 14/03/16 14:37, Guenter Roeck wrote: > To give people an idea what to expect in the merge window, here are my current > build and runtime test results. Some of the runtime failures are due to the > newly introduced i2c bug, but many (including the arm64 boot failures) have > been

Re: linux-next: Tree for Mar 14

Hi Guenter, On 14/03/16 14:37, Guenter Roeck wrote: > To give people an idea what to expect in the merge window, here are my current > build and runtime test results. Some of the runtime failures are due to the > newly introduced i2c bug, but many (including the arm64 boot failures) have > been

Re: [PATCH v11 1/9] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

Hi David, On 09/03/16 05:32, David Long wrote: > From: "David A. Long" > > Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64. > > Signed-off-by: David A. Long > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c > index

Re: [PATCH v11 1/9] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

Hi David, On 09/03/16 05:32, David Long wrote: > From: "David A. Long" > > Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64. > > Signed-off-by: David A. Long > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c > index ff7f132..efebf0f 100644 > ---

Re: [RFC][PATCH 07/12] perf: Simplify/fix perf_event_enable() event scheduling

On 08/03/16 10:26, Peter Zijlstra wrote: > In any case, please try -rc6, which includes: Bother, I should have thought to test with the later rcs, I foolishly stopped with rc5. > a096309bc467 perf: Fix scaling vs. perf_install_in_context() > bd2afa49d194 perf: Fix scaling vs.

Re: [RFC][PATCH 07/12] perf: Simplify/fix perf_event_enable() event scheduling

On 08/03/16 10:26, Peter Zijlstra wrote: > In any case, please try -rc6, which includes: Bother, I should have thought to test with the later rcs, I foolishly stopped with rc5. > a096309bc467 perf: Fix scaling vs. perf_install_in_context() > bd2afa49d194 perf: Fix scaling vs.

Re: [RFC][PATCH 07/12] perf: Simplify/fix perf_event_enable() event scheduling

Hi Peter! On 11/01/16 16:25, Peter Zijlstra wrote: > Like enable_on_exec, perf_event_enable() event scheduling has problems > respecting the context hierarchy when trying to schedule events (for > example, it will try and add a pinned event without first removing > existing flexible events). > >

Re: [RFC][PATCH 07/12] perf: Simplify/fix perf_event_enable() event scheduling

Hi Peter! On 11/01/16 16:25, Peter Zijlstra wrote: > Like enable_on_exec, perf_event_enable() event scheduling has problems > respecting the context hierarchy when trying to schedule events (for > example, it will try and add a pinned event without first removing > existing flexible events). > >

Re: [PATCH] arm64: make irq_stack_ptr more robust

= IRQ_STACK_PTR(smp_processor_id()); > + else > + irq_stack_ptr = 0; > + > pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk); > > if (!tsk) > Neither file includes 'linux/preempt.h' for the definition of preemptible(). (I can't talk: I should have included smp.h for smp_processor_id()) Acked-by: James Morse Tested-by: James Morse Thanks! James

Re: [PATCH] arm64: make irq_stack_ptr more robust

> + irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id()); > + else > + irq_stack_ptr = 0; > + > pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk); > > if (!tsk) > Neither file includes 'linux/preempt.h' for the definition of preemptible(). (I can't talk: I should have included smp.h for smp_processor_id()) Acked-by: James Morse <james.mo...@arm.com> Tested-by: James Morse <james.mo...@arm.com> Thanks! James

Re: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump

Hi! On 10/02/16 18:12, Shi, Yang wrote: > On 2/10/2016 4:10 AM, Will Deacon wrote: >> On Wed, Feb 10, 2016 at 11:52:31AM +0000, James Morse wrote: >>> On 10/02/16 10:29, Will Deacon wrote: >>>> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote: >>>>

Re: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump

Hi! On 10/02/16 18:12, Shi, Yang wrote: > On 2/10/2016 4:10 AM, Will Deacon wrote: >> On Wed, Feb 10, 2016 at 11:52:31AM +0000, James Morse wrote: >>> On 10/02/16 10:29, Will Deacon wrote: >>>> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote: >>>>

Re: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump

On 10/02/16 10:29, Will Deacon wrote: > On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote: >> dump_backtrace may be called in kthread context, which is not bound to a >> single >> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug >> report: > > If we're

Re: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump

On 10/02/16 10:29, Will Deacon wrote: > On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote: >> dump_backtrace may be called in kthread context, which is not bound to a >> single >> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug >> report: > > If we're

Re: [PATCH v2 04/13] arm64: decouple early fixmap init from linear mapping

Hi Ard! On 30/12/15 15:26, Ard Biesheuvel wrote: > Since the early fixmap page tables are populated using pages that are > part of the static footprint of the kernel, they are covered by the > initial kernel mapping, and we can refer to them without using __va/__pa > translations, which are tied

Re: [PATCH v2 04/13] arm64: decouple early fixmap init from linear mapping

Hi Ard! On 30/12/15 15:26, Ard Biesheuvel wrote: > Since the early fixmap page tables are populated using pages that are > part of the static footprint of the kernel, they are covered by the > initial kernel mapping, and we can refer to them without using __va/__pa > translations, which are tied

Re: [PATCH 1/2] arm64: Improve error reporting on set_pte_at() checks

Hi Andrew, On 16/12/15 03:01, Andrew Pinski wrote: > On Tue, Dec 9, 2015 at 17:26:56, Catalin Marinas > wrote: >> >> Currently the BUG_ON() checks do not give enough information about the PTEs >> being set. This patch changes BUG_ON to WARN_ONCE and dumps the values of >> the old and new PTEs.

Re: [PATCH 1/2] arm64: Improve error reporting on set_pte_at() checks

Hi Andrew, On 16/12/15 03:01, Andrew Pinski wrote: > On Tue, Dec 9, 2015 at 17:26:56, Catalin Marinas > wrote: >> >> Currently the BUG_ON() checks do not give enough information about the PTEs >> being set. This patch changes BUG_ON to WARN_ONCE and dumps the values of

Re: [PATCH] arm64: Add missing linux/bug.h include in asm/pgtable.h

On 14/12/15 17:07, Catalin Marinas wrote: > If they take the mmdebug.h patch, it's even better. Please let us know > how that goes. Andrew Morton's Robot wrote: > The patch titled > Subject: include/linux/mmdebug.h: should include linux/bug.h > has been added to the -mm tree. Its filename

Re: [PATCH] arm64: Add missing linux/bug.h include in asm/pgtable.h

On 14/12/15 17:07, Catalin Marinas wrote: > If they take the mmdebug.h patch, it's even better. Please let us know > how that goes. Andrew Morton's Robot wrote: > The patch titled > Subject: include/linux/mmdebug.h: should include linux/bug.h > has been added to the -mm tree. Its filename

Re: [PATCH] arm64: Add missing linux/bug.h include in asm/pgtable.h

On 14/12/15 16:38, Catalin Marinas wrote: > On Mon, Dec 14, 2015 at 04:26:48PM +, Julien Grall wrote: >> On 14/12/15 16:22, Catalin Marinas wrote: >>> On Mon, Dec 14, 2015 at 04:07:24PM +, Julien Grall wrote: Linux 4.4-rc5 doesn't build for arm64 with CONFIG_XEN=y enabled:

Re: [PATCH] arm64: Add missing linux/bug.h include in asm/pgtable.h

On 14/12/15 16:38, Catalin Marinas wrote: > On Mon, Dec 14, 2015 at 04:26:48PM +, Julien Grall wrote: >> On 14/12/15 16:22, Catalin Marinas wrote: >>> On Mon, Dec 14, 2015 at 04:07:24PM +, Julien Grall wrote: Linux 4.4-rc5 doesn't build for arm64 with CONFIG_XEN=y enabled:

Re: [PATCH v6 2/3] percpu: add PERCPU_ATOM_SIZE for a generic percpu area setup

Hi Jungseok, On 03/11/15 13:49, Jungseok Lee wrote: > Additionally, I've been thinking of do_softirq_own_stack() which is your > another comment [3]. Recently, I've realized there is possibility that > I misunderstood your intention. Did you mean that irq_handler hook is not > enough? Should

Re: [PATCH v6 2/3] percpu: add PERCPU_ATOM_SIZE for a generic percpu area setup

Hi Jungseok, On 03/11/15 13:49, Jungseok Lee wrote: > Additionally, I've been thinking of do_softirq_own_stack() which is your > another comment [3]. Recently, I've realized there is possibility that > I misunderstood your intention. Did you mean that irq_handler hook is not > enough? Should

Re: [PATCH v5] arm64: Introduce IRQ stack

On 20/10/15 16:05, Jungseok Lee wrote: > On Oct 20, 2015, at 7:05 PM, James Morse wrote: >> On 17/10/15 15:27, Jungseok Lee wrote: >>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c >>> index 9f17ec0..13fe8f4 100644 >>> --- a/arch/arm64/kern

Re: [PATCH v5] arm64: Introduce IRQ stack

--- > I've used Cc', not Tested-by tag, from James, since there is a gap > between v4 and v5. Re-tested, with both 4K and 64K pages. Tested-By: James Morse I also need to test this on top of Akashi Takahiros's series - in isolation this patch only lets perf/dump_stack() unwind as far as el1_ir

Re: [PATCH v5] arm64: Introduce IRQ stack

--- > I've used Cc', not Tested-by tag, from James, since there is a gap > between v4 and v5. Re-tested, with both 4K and 64K pages. Tested-By: James Morse <james.mo...@arm.com> I also need to test this on top of Akashi Takahiros's series - in isolation this patch only lets pe

Re: [PATCH v5] arm64: Introduce IRQ stack

On 20/10/15 16:05, Jungseok Lee wrote: > On Oct 20, 2015, at 7:05 PM, James Morse wrote: >> On 17/10/15 15:27, Jungseok Lee wrote: >>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c >>> index 9f17ec0..13fe8f4 100644 >>> --- a/arch/arm64/kern

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

On 15/10/15 15:24, Jungseok Lee wrote: > On Oct 9, 2015, at 11:24 PM, James Morse wrote: >> I think unwind_frame() needs to walk the irq stack too. [2] is an example >> of perf tracing back to userspace, (and there are patches on the list to >> do/fix this), so we need to w

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

On 14/10/15 13:12, Jungseok Lee wrote: > On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote: >> On Oct 13, 2015, at 8:00 PM, James Morse wrote: >>> On 12/10/15 23:13, Jungseok Lee wrote: >>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote: >>>>> Having

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

On 15/10/15 15:24, Jungseok Lee wrote: > On Oct 9, 2015, at 11:24 PM, James Morse wrote: >> I think unwind_frame() needs to walk the irq stack too. [2] is an example >> of perf tracing back to userspace, (and there are patches on the list to >> do/fix this), so we need to w

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

On 14/10/15 13:12, Jungseok Lee wrote: > On Oct 14, 2015, at 12:00 AM, Jungseok Lee wrote: >> On Oct 13, 2015, at 8:00 PM, James Morse wrote: >>> On 12/10/15 23:13, Jungseok Lee wrote: >>>> On Oct 13, 2015, at 1:34 AM, James Morse wrote: >>>>> Having

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

Hi Jungseok, On 12/10/15 23:13, Jungseok Lee wrote: > On Oct 13, 2015, at 1:34 AM, James Morse wrote: >> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful >> (especially for systems with few cpus)… > > This would be a single concern. To addre

Re: [PATCH v5 1/2] arm64: kvm: allows kvm cpu hotplug

Hi, On 13/10/15 06:38, AKASHI Takahiro wrote: > On 10/12/2015 10:28 PM, James Morse wrote: >> On 29/05/15 06:38, AKASHI Takahiro wrote: >>> The current kvm implementation on arm64 does cpu-specific initialization >>> at system boot, and has no way to gracefully shutdown

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

Hi Jungseok, On 12/10/15 23:13, Jungseok Lee wrote: > On Oct 13, 2015, at 1:34 AM, James Morse wrote: >> Having two kmem_caches for 16K stacks on a 64K page system may be wasteful >> (especially for systems with few cpus)… > > This would be a single concern. To addre

Re: [PATCH v5 1/2] arm64: kvm: allows kvm cpu hotplug

Hi, On 13/10/15 06:38, AKASHI Takahiro wrote: > On 10/12/2015 10:28 PM, James Morse wrote: >> On 29/05/15 06:38, AKASHI Takahiro wrote: >>> The current kvm implementation on arm64 does cpu-specific initialization >>> at system boot, and has no way to gracefully shutdown

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

Hi Jungseok, On 12/10/15 15:53, Jungseok Lee wrote: > On Oct 9, 2015, at 11:24 PM, James Morse wrote: >> I think unwind_frame() needs to walk the irq stack too. [2] is an example >> of perf tracing back to userspace, (and there are patches on the list to >> do/fix this), so

Re: [PATCH v5 1/2] arm64: kvm: allows kvm cpu hotplug

On 29/05/15 06:38, AKASHI Takahiro wrote: > The current kvm implementation on arm64 does cpu-specific initialization > at system boot, and has no way to gracefully shutdown a core in terms of > kvm. This prevents, especially, kexec from rebooting the system on a boot > core in EL2. > > This patch

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

Hi Jungseok, On 12/10/15 15:53, Jungseok Lee wrote: > On Oct 9, 2015, at 11:24 PM, James Morse wrote: >> I think unwind_frame() needs to walk the irq stack too. [2] is an example >> of perf tracing back to userspace, (and there are patches on the list to >> do/fix this), so

Re: [PATCH v5 1/2] arm64: kvm: allows kvm cpu hotplug

On 29/05/15 06:38, AKASHI Takahiro wrote: > The current kvm implementation on arm64 does cpu-specific initialization > at system boot, and has no way to gracefully shutdown a core in terms of > kvm. This prevents, especially, kexec from rebooting the system on a boot > core in EL2. > > This patch

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

Hi Jungseok, On 07/10/15 16:28, Jungseok Lee wrote: > Currently, a call trace drops a process stack walk when a separate IRQ > stack is used. It makes a call trace information much less useful when > a system gets paniked in interrupt context. panicked > This patch addresses the issue with the

Re: [PATCH v4 2/2] arm64: Expand the stack trace feature to support IRQ stack

Hi Jungseok, On 07/10/15 16:28, Jungseok Lee wrote: > Currently, a call trace drops a process stack walk when a separate IRQ > stack is used. It makes a call trace information much less useful when > a system gets paniked in interrupt context. panicked > This patch addresses the issue with the

Re: [PATCH v3] arm64: Introduce IRQ stack

On 05/10/15 07:37, AKASHI Takahiro wrote: > On 10/04/2015 11:32 PM, Jungseok Lee wrote: >> On Oct 3, 2015, at 1:23 AM, James Morse wrote: >>> One observed change in behaviour: >>> Any stack-unwinding now stops at el1_irq(), which is the bottom of the irq >>> s

Re: [PATCH v3] arm64: Introduce IRQ stack

On 05/10/15 07:37, AKASHI Takahiro wrote: > On 10/04/2015 11:32 PM, Jungseok Lee wrote: >> On Oct 3, 2015, at 1:23 AM, James Morse wrote: >>> One observed change in behaviour: >>> Any stack-unwinding now stops at el1_irq(), which is the bottom of the irq >>> s

Re: [PATCH v3] arm64: Introduce IRQ stack

Hi, On 22/09/15 13:11, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1. This forces a system to use 16KB > stack, not 8KB one. This restriction makes low memory platforms suffer > from memory pressure accompanied by

Re: [PATCH v3] arm64: Introduce IRQ stack

Hi, On 22/09/15 13:11, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1. This forces a system to use 16KB > stack, not 8KB one. This restriction makes low memory platforms suffer > from memory pressure accompanied by

Re: [PATCH 00/22] arm64: Consolidate CPU feature handling

> > The series is also available here : > > git://linux-arm.org/linux-skp.git cpu-ftr/v1-4.3-rc1 Hi Suzuki, I gave your branch a spin on some insane combinations with a fast-model - testing PAN only got enabled when all cores supported it. Tested-by: James Morse Thanks, James -- T

Re: [PATCH 00/22] arm64: Consolidate CPU feature handling

[1], which does much more. > > > The series is also available here : > > git://linux-arm.org/linux-skp.git cpu-ftr/v1-4.3-rc1 Hi Suzuki, I gave your branch a spin on some insane combinations with a fast-model - testing PAN only got enabled when all cores supported it. Tested-by: James

Re: [PATCH v2] arm64: Introduce IRQ stack

Hi Jungseok Lee, I gave this a go on a Juno board, while generating usb/network interrupts: Tested-by: James Morse On 13/09/15 15:42, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1. This forces many systems

Re: [PATCH v2] arm64: Introduce IRQ stack

On 18/09/15 13:57, Jungseok Lee wrote: > On Sep 18, 2015, at 1:21 AM, Catalin Marinas wrote: >> in more detail. BTW, I don't think we need the any count for the irq >> stack as we don't re-enter the same IRQ stack. > > Another interrupt could come in since IRQ is enabled when handling softirq >

Re: [PATCH v2] arm64: Introduce IRQ stack

Hi Jungseok Lee, I gave this a go on a Juno board, while generating usb/network interrupts: Tested-by: James Morse <james.mo...@arm.com> On 13/09/15 15:42, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1.

Re: [PATCH v2] arm64: Introduce IRQ stack

On 18/09/15 13:57, Jungseok Lee wrote: > On Sep 18, 2015, at 1:21 AM, Catalin Marinas wrote: >> in more detail. BTW, I don't think we need the any count for the irq >> stack as we don't re-enter the same IRQ stack. > > Another interrupt could come in since IRQ is enabled when handling softirq >

Re: [PATCH v2] arm64: Introduce IRQ stack

Hi Will, On 16/09/15 12:25, Will Deacon wrote: > On Sun, Sep 13, 2015 at 03:42:17PM +0100, Jungseok Lee wrote: >> diff --git a/arch/arm64/include/asm/thread_info.h >> b/arch/arm64/include/asm/thread_info.h >> index dcd06d1..44839c0 100644 >> --- a/arch/arm64/include/asm/thread_info.h >> +++

Re: [PATCH v2] arm64: Introduce IRQ stack

Hi Will, On 16/09/15 12:25, Will Deacon wrote: > On Sun, Sep 13, 2015 at 03:42:17PM +0100, Jungseok Lee wrote: >> diff --git a/arch/arm64/include/asm/thread_info.h >> b/arch/arm64/include/asm/thread_info.h >> index dcd06d1..44839c0 100644 >> --- a/arch/arm64/include/asm/thread_info.h >> +++

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

On 09/09/15 14:22, Jungseok Lee wrote: > On Sep 9, 2015, at 1:47 AM, James Morse wrote: >> On 08/09/15 15:54, Jungseok Lee wrote: >>> On Sep 7, 2015, at 11:36 PM, James Morse wrote: >>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c >>>&g

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

On 09/09/15 14:22, Jungseok Lee wrote: > On Sep 9, 2015, at 1:47 AM, James Morse wrote: >> On 08/09/15 15:54, Jungseok Lee wrote: >>> On Sep 7, 2015, at 11:36 PM, James Morse wrote: >>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c >>>&g

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

On 08/09/15 15:54, Jungseok Lee wrote: > On Sep 7, 2015, at 11:36 PM, James Morse wrote: > > Hi James, > >> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S >> index e16351819fed..d42371f3f5a1 100644 >> --- a/arch/arm64/kernel/entry.S >

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

On 08/09/15 15:54, Jungseok Lee wrote: > On Sep 7, 2015, at 11:36 PM, James Morse wrote: > > Hi James, > >> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S >> index e16351819fed..d42371f3f5a1 100644 >> --- a/arch/arm64/kernel/entry.S >

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

On 07/09/15 16:48, Jungseok Lee wrote: > On Sep 7, 2015, at 11:36 PM, James Morse wrote: > > Hi James, > >> Having to handle interrupts on top of an existing kernel stack means the >> kernel stack must be large enough to accomodate both the maximum kernel >> usag

Re: [RFC PATCH 1/3] arm64: entry: Remove unnecessary calculation for S_SP in EL1h

On 04/09/15 15:23, Jungseok Lee wrote: > Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation > is not needed in kernel_entry. Currently, S_SP information is vaild only > when sp_el0 is used. > > Signed-off-by: Jungseok Lee > diff --git a/arch/arm64/kernel/entry.S

Re: [RFC PATCH 2/3] arm64: Introduce IRQ stack

On 04/09/15 15:23, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1. This forces many systems to use > 16KB stack, not 8KB one. Low memory platforms naturally suffer from > both memory pressure and performance degradation

[PATCH] arm64: kernel: Use a separate stack for irq interrupts.

stack usage (running ltp and generating usb+ethernet interrupts) was 7256 bytes. With this patch, the same workload gives a maximum stack usage of 5816 bytes. Signed-off-by: James Morse --- arch/arm64/include/asm/irq.h | 12 + arch/arm64/include/asm/thread_info.h | 8 -- arch

Re: [RFC PATCH 0/3] Implement IRQ stack on ARM64

y of the stack-pointer to find struct thread_info, whereas I was copying it between stacks (ends up as 2x ldp/stps), which keeps the change restricted to irq_stack setup code. We should get some feedback as to which approach is preferred. Thanks, James Morse -- To unsubscribe from this list: se

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

On 07/09/15 16:48, Jungseok Lee wrote: > On Sep 7, 2015, at 11:36 PM, James Morse wrote: > > Hi James, > >> Having to handle interrupts on top of an existing kernel stack means the >> kernel stack must be large enough to accomodate both the maximum kernel >> usag

[PATCH] arm64: kernel: Use a separate stack for irq interrupts.

stack usage (running ltp and generating usb+ethernet interrupts) was 7256 bytes. With this patch, the same workload gives a maximum stack usage of 5816 bytes. Signed-off-by: James Morse <james.mo...@arm.com> --- arch/arm64/include/asm/irq.h | 12 + arch/arm64/inclu

Re: [RFC PATCH 0/3] Implement IRQ stack on ARM64

y of the stack-pointer to find struct thread_info, whereas I was copying it between stacks (ends up as 2x ldp/stps), which keeps the change restricted to irq_stack setup code. We should get some feedback as to which approach is preferred. Thanks, James Morse -- To unsubscribe from this list: se

Re: [RFC PATCH 2/3] arm64: Introduce IRQ stack

On 04/09/15 15:23, Jungseok Lee wrote: > Currently, kernel context and interrupts are handled using a single > kernel stack navigated by sp_el1. This forces many systems to use > 16KB stack, not 8KB one. Low memory platforms naturally suffer from > both memory pressure and performance degradation

Re: [RFC PATCH 1/3] arm64: entry: Remove unnecessary calculation for S_SP in EL1h

On 04/09/15 15:23, Jungseok Lee wrote: > Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation > is not needed in kernel_entry. Currently, S_SP information is vaild only > when sp_el0 is used. > > Signed-off-by: Jungseok Lee > diff --git

<    6   7   8   9   10   11