* [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only [not found] <CGME20201211091546epcas5p24511325afff612d57306d733a3307648@epcas5p2.samsung.com> @ 2020-12-11 9:15 ` Maninder Singh 0 siblings, 0 replies; 8+ messages in thread From: Maninder Singh @ 2020-12-11 9:15 UTC (permalink / raw) To: catalin.marinas, will, mark.rutland, broonie, vincenzo.frascino, samitolvanen, ardb, maz Cc: linux-arm-kernel, linux-kernel, v.narang, a.sahrawat, Maninder Singh current code checks for sp bit flip in all exceptions, but only el1 exceptions requires this. el0 can not enter into stack overflow case directly. it will improve performance for el0 exceptions and interrupts. Signed-off-by: Maninder Singh <maninder1.s@samsung.com> Signed-off-by: Vaneet Narang <v.narang@samsung.com> --- arch/arm64/kernel/entry.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 2a93fa5..cad8faf 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -77,6 +77,7 @@ alternative_else_nop_endif sub sp, sp, #S_FRAME_SIZE #ifdef CONFIG_VMAP_STACK + .if \el == 1 /* * Test whether the SP has overflowed, without corrupting a GPR. * Task and IRQ stacks are aligned so that SP & (1 << THREAD_SHIFT) @@ -118,6 +119,7 @@ alternative_else_nop_endif /* We were already on the overflow stack. Restore sp/x0 and carry on. */ sub sp, sp, x0 mrs x0, tpidrro_el0 + .endif #endif b el\()\el\()_\label .endm -- 1.9.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only @ 2020-12-11 9:15 ` Maninder Singh 0 siblings, 0 replies; 8+ messages in thread From: Maninder Singh @ 2020-12-11 9:15 UTC (permalink / raw) To: catalin.marinas, will, mark.rutland, broonie, vincenzo.frascino, samitolvanen, ardb, maz Cc: v.narang, Maninder Singh, a.sahrawat, linux-kernel, linux-arm-kernel current code checks for sp bit flip in all exceptions, but only el1 exceptions requires this. el0 can not enter into stack overflow case directly. it will improve performance for el0 exceptions and interrupts. Signed-off-by: Maninder Singh <maninder1.s@samsung.com> Signed-off-by: Vaneet Narang <v.narang@samsung.com> --- arch/arm64/kernel/entry.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 2a93fa5..cad8faf 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -77,6 +77,7 @@ alternative_else_nop_endif sub sp, sp, #S_FRAME_SIZE #ifdef CONFIG_VMAP_STACK + .if \el == 1 /* * Test whether the SP has overflowed, without corrupting a GPR. * Task and IRQ stacks are aligned so that SP & (1 << THREAD_SHIFT) @@ -118,6 +119,7 @@ alternative_else_nop_endif /* We were already on the overflow stack. Restore sp/x0 and carry on. */ sub sp, sp, x0 mrs x0, tpidrro_el0 + .endif #endif b el\()\el\()_\label .endm -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only 2020-12-11 9:15 ` Maninder Singh @ 2021-01-07 11:29 ` Mark Rutland -1 siblings, 0 replies; 8+ messages in thread From: Mark Rutland @ 2021-01-07 11:29 UTC (permalink / raw) To: Maninder Singh Cc: catalin.marinas, will, broonie, vincenzo.frascino, samitolvanen, ardb, maz, linux-arm-kernel, linux-kernel, v.narang, a.sahrawat On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: > current code checks for sp bit flip in all exceptions, > but only el1 exceptions requires this. el0 can not enter > into stack overflow case directly. > > it will improve performance for el0 exceptions and interrupts. > > Signed-off-by: Maninder Singh <maninder1.s@samsung.com> > Signed-off-by: Vaneet Narang <v.narang@samsung.com> I did consider doing this at the time Ard and I wrote the overflow detection, but there was no measureable impact on the workloads that I tested, and it seemed worthwhile to have this as a sanity check in case the SP was somehow corrupted (and to avoid any surprizing differences between the EL0 and EL1 entry paths). When you say "it will improve performance for el0 exceptions and interrupts", do you have a workload where this has a measureable impact, or was this found by inspection? Unless this is causing a real issue, I'd prefer to leave it as-is for now. Thanks, Mark. > --- > arch/arm64/kernel/entry.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index 2a93fa5..cad8faf 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -77,6 +77,7 @@ alternative_else_nop_endif > > sub sp, sp, #S_FRAME_SIZE > #ifdef CONFIG_VMAP_STACK > + .if \el == 1 > /* > * Test whether the SP has overflowed, without corrupting a GPR. > * Task and IRQ stacks are aligned so that SP & (1 << THREAD_SHIFT) > @@ -118,6 +119,7 @@ alternative_else_nop_endif > /* We were already on the overflow stack. Restore sp/x0 and carry on. */ > sub sp, sp, x0 > mrs x0, tpidrro_el0 > + .endif > #endif > b el\()\el\()_\label > .endm > -- > 1.9.1 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only @ 2021-01-07 11:29 ` Mark Rutland 0 siblings, 0 replies; 8+ messages in thread From: Mark Rutland @ 2021-01-07 11:29 UTC (permalink / raw) To: Maninder Singh Cc: v.narang, a.sahrawat, catalin.marinas, linux-kernel, broonie, samitolvanen, maz, vincenzo.frascino, will, ardb, linux-arm-kernel On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: > current code checks for sp bit flip in all exceptions, > but only el1 exceptions requires this. el0 can not enter > into stack overflow case directly. > > it will improve performance for el0 exceptions and interrupts. > > Signed-off-by: Maninder Singh <maninder1.s@samsung.com> > Signed-off-by: Vaneet Narang <v.narang@samsung.com> I did consider doing this at the time Ard and I wrote the overflow detection, but there was no measureable impact on the workloads that I tested, and it seemed worthwhile to have this as a sanity check in case the SP was somehow corrupted (and to avoid any surprizing differences between the EL0 and EL1 entry paths). When you say "it will improve performance for el0 exceptions and interrupts", do you have a workload where this has a measureable impact, or was this found by inspection? Unless this is causing a real issue, I'd prefer to leave it as-is for now. Thanks, Mark. > --- > arch/arm64/kernel/entry.S | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > index 2a93fa5..cad8faf 100644 > --- a/arch/arm64/kernel/entry.S > +++ b/arch/arm64/kernel/entry.S > @@ -77,6 +77,7 @@ alternative_else_nop_endif > > sub sp, sp, #S_FRAME_SIZE > #ifdef CONFIG_VMAP_STACK > + .if \el == 1 > /* > * Test whether the SP has overflowed, without corrupting a GPR. > * Task and IRQ stacks are aligned so that SP & (1 << THREAD_SHIFT) > @@ -118,6 +119,7 @@ alternative_else_nop_endif > /* We were already on the overflow stack. Restore sp/x0 and carry on. */ > sub sp, sp, x0 > mrs x0, tpidrro_el0 > + .endif > #endif > b el\()\el\()_\label > .endm > -- > 1.9.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only 2021-01-07 11:29 ` Mark Rutland @ 2021-01-20 11:08 ` Will Deacon -1 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2021-01-20 11:08 UTC (permalink / raw) To: Mark Rutland Cc: Maninder Singh, catalin.marinas, broonie, vincenzo.frascino, samitolvanen, ardb, maz, linux-arm-kernel, linux-kernel, v.narang, a.sahrawat On Thu, Jan 07, 2021 at 11:29:03AM +0000, Mark Rutland wrote: > On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: > > current code checks for sp bit flip in all exceptions, > > but only el1 exceptions requires this. el0 can not enter > > into stack overflow case directly. > > > > it will improve performance for el0 exceptions and interrupts. > > > > Signed-off-by: Maninder Singh <maninder1.s@samsung.com> > > Signed-off-by: Vaneet Narang <v.narang@samsung.com> > > I did consider doing this at the time Ard and I wrote the overflow > detection, but there was no measureable impact on the workloads that I > tested, and it seemed worthwhile to have this as a sanity check in case > the SP was somehow corrupted (and to avoid any surprizing differences > between the EL0 and EL1 entry paths). > > When you say "it will improve performance for el0 exceptions and > interrupts", do you have a workload where this has a measureable impact, > or was this found by inspection? Unless this is causing a real issue, > I'd prefer to leave it as-is for now. Maninder -- please could you follow up on Mark's question? Will ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only @ 2021-01-20 11:08 ` Will Deacon 0 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2021-01-20 11:08 UTC (permalink / raw) To: Mark Rutland Cc: v.narang, a.sahrawat, catalin.marinas, linux-kernel, broonie, samitolvanen, maz, Maninder Singh, vincenzo.frascino, ardb, linux-arm-kernel On Thu, Jan 07, 2021 at 11:29:03AM +0000, Mark Rutland wrote: > On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: > > current code checks for sp bit flip in all exceptions, > > but only el1 exceptions requires this. el0 can not enter > > into stack overflow case directly. > > > > it will improve performance for el0 exceptions and interrupts. > > > > Signed-off-by: Maninder Singh <maninder1.s@samsung.com> > > Signed-off-by: Vaneet Narang <v.narang@samsung.com> > > I did consider doing this at the time Ard and I wrote the overflow > detection, but there was no measureable impact on the workloads that I > tested, and it seemed worthwhile to have this as a sanity check in case > the SP was somehow corrupted (and to avoid any surprizing differences > between the EL0 and EL1 entry paths). > > When you say "it will improve performance for el0 exceptions and > interrupts", do you have a workload where this has a measureable impact, > or was this found by inspection? Unless this is causing a real issue, > I'd prefer to leave it as-is for now. Maninder -- please could you follow up on Mark's question? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CGME20201211091546epcas5p24511325afff612d57306d733a3307648@epcms5p5>]
* RE: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only [not found] ` <CGME20201211091546epcas5p24511325afff612d57306d733a3307648@epcms5p5> @ 2021-01-20 11:22 ` Maninder Singh 0 siblings, 0 replies; 8+ messages in thread From: Maninder Singh @ 2021-01-20 11:22 UTC (permalink / raw) To: Will Deacon, Mark Rutland Cc: catalin.marinas, broonie, vincenzo.frascino, samitolvanen, ardb, maz, linux-arm-kernel, linux-kernel, Vaneet Narang, AMIT SAHRAWAT Hi Mark, Will On Thu, Jan 07, 2021 at 11:29:03AM +0000, Mark Rutland wrote: >> On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: >> > current code checks for sp bit flip in all exceptions, >> > but only el1 exceptions requires this. el0 can not enter >> > into stack overflow case directly. >> > >> > it will improve performance for el0 exceptions and interrupts. >> > >> > Signed-off-by: Maninder Singh <maninder1.s@samsung.com> >> > Signed-off-by: Vaneet Narang <v.narang@samsung.com> >> >> I did consider doing this at the time Ard and I wrote the overflow >> detection, but there was no measureable impact on the workloads that I >> tested, and it seemed worthwhile to have this as a sanity check in case >> the SP was somehow corrupted (and to avoid any surprizing differences >> between the EL0 and EL1 entry paths). >> > >> When you say "it will improve performance for el0 exceptions and >> interrupts", do you have a workload where this has a measureable impact, >> or was this found by inspection? Unless this is causing a real issue, >> I'd prefer to leave it as-is for now. > We have not measured performance with any tool because as you said its not measurable, but we think if we can remove some instructions then it will be better, thats why suggested this change. And in el0 there is no chance of overflow of sp so that 5 instructions can be avoided. We tried this on our setup because we were changing some design for VMAP_STACK in our kernel for some more enhancement, so that code was little much and we avoided that part in our local kernel for el0. Thanks, Maninder Singh ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only @ 2021-01-20 11:22 ` Maninder Singh 0 siblings, 0 replies; 8+ messages in thread From: Maninder Singh @ 2021-01-20 11:22 UTC (permalink / raw) To: Will Deacon, Mark Rutland Cc: Vaneet Narang, AMIT SAHRAWAT, catalin.marinas, linux-kernel, broonie, samitolvanen, maz, vincenzo.frascino, ardb, linux-arm-kernel Hi Mark, Will On Thu, Jan 07, 2021 at 11:29:03AM +0000, Mark Rutland wrote: >> On Fri, Dec 11, 2020 at 02:45:31PM +0530, Maninder Singh wrote: >> > current code checks for sp bit flip in all exceptions, >> > but only el1 exceptions requires this. el0 can not enter >> > into stack overflow case directly. >> > >> > it will improve performance for el0 exceptions and interrupts. >> > >> > Signed-off-by: Maninder Singh <maninder1.s@samsung.com> >> > Signed-off-by: Vaneet Narang <v.narang@samsung.com> >> >> I did consider doing this at the time Ard and I wrote the overflow >> detection, but there was no measureable impact on the workloads that I >> tested, and it seemed worthwhile to have this as a sanity check in case >> the SP was somehow corrupted (and to avoid any surprizing differences >> between the EL0 and EL1 entry paths). >> > >> When you say "it will improve performance for el0 exceptions and >> interrupts", do you have a workload where this has a measureable impact, >> or was this found by inspection? Unless this is causing a real issue, >> I'd prefer to leave it as-is for now. > We have not measured performance with any tool because as you said its not measurable, but we think if we can remove some instructions then it will be better, thats why suggested this change. And in el0 there is no chance of overflow of sp so that 5 instructions can be avoided. We tried this on our setup because we were changing some design for VMAP_STACK in our kernel for some more enhancement, so that code was little much and we avoided that part in our local kernel for el0. Thanks, Maninder Singh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-01-20 12:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20201211091546epcas5p24511325afff612d57306d733a3307648@epcas5p2.samsung.com>
2020-12-11 9:15 ` [PATCH 1/1] arm64/entry.S: check for stack overflow in el1 case only Maninder Singh
2020-12-11 9:15 ` Maninder Singh
2021-01-07 11:29 ` Mark Rutland
2021-01-07 11:29 ` Mark Rutland
2021-01-20 11:08 ` Will Deacon
2021-01-20 11:08 ` Will Deacon
[not found] ` <CGME20201211091546epcas5p24511325afff612d57306d733a3307648@epcms5p5>
2021-01-20 11:22 ` Maninder Singh
2021-01-20 11:22 ` Maninder Singh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.