RE: [PATCH v2] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

+CC sergey.senozhatsky.w...@gmail.com pmla...@suse.com Please review this patch. > -Original Message- > From: Hoeun Ryu [mailto:hoeun@lge.com.com] > Sent: Tuesday, June 05, 2018 11:19 AM > To: Andrew Morton ; Kees Cook > ; Andi Kleen ; Borislav Petkov > ; Thomas

RE: [PATCH v2] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

+CC sergey.senozhatsky.w...@gmail.com pmla...@suse.com Please review this patch. > -Original Message- > From: Hoeun Ryu [mailto:hoeun@lge.com.com] > Sent: Tuesday, June 05, 2018 11:19 AM > To: Andrew Morton ; Kees Cook > ; Andi Kleen ; Borislav Petkov > ; Thomas

RE: [PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

I misunderstood the cause of a deadlock. I sent v2 fixing the commit message about the reason of the deadlock. Please ignore this and review v2. Thank you. > -Original Message- > From: Steven Rostedt [mailto:rost...@goodmis.org] > Sent: Tuesday, June 05, 2018 10:44 AM > T

RE: [PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

I misunderstood the cause of a deadlock. I sent v2 fixing the commit message about the reason of the deadlock. Please ignore this and review v2. Thank you. > -Original Message- > From: Steven Rostedt [mailto:rost...@goodmis.org] > Sent: Tuesday, June 05, 2018 10:44 AM > T

[PATCH v2] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

From: Hoeun Ryu Many console device drivers hold the uart_port->lock spinlock with irq disabled (using spin_lock_irqsave()) while the device drivers are writing characters to their devices, but the device drivers just try to hold the spin lock (using spin_trylock_irqsave()) inst

[PATCH v2] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

From: Hoeun Ryu Many console device drivers hold the uart_port->lock spinlock with irq disabled (using spin_lock_irqsave()) while the device drivers are writing characters to their devices, but the device drivers just try to hold the spin lock (using spin_trylock_irqsave()) inst

[PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

From: Hoeun Ryu Many console device drivers hold the uart_port->lock spinlock with irq enabled (using spin_lock()) while the device drivers are writing characters to their devices, but the device drivers just try to hold the spin lock (using spin_trylock()) if "oops_in_progress&q

[PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

From: Hoeun Ryu Many console device drivers hold the uart_port->lock spinlock with irq enabled (using spin_lock()) while the device drivers are writing characters to their devices, but the device drivers just try to hold the spin lock (using spin_trylock()) if "oops_in_progress&q

[PATCH v2] printk: make printk_safe_flush safe in NMI context by skipping flushing

From: Hoeun Ryu Make printk_safe_flush() safe in NMI context. nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the function is called in watchdog_overflow_callback() if the flag of hardlockup backtrace (sysctl_hardlockup_all_cpu_backtrace) is true

[PATCH v2] printk: make printk_safe_flush safe in NMI context by skipping flushing

From: Hoeun Ryu Make printk_safe_flush() safe in NMI context. nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the function is called in watchdog_overflow_callback() if the flag of hardlockup backtrace (sysctl_hardlockup_all_cpu_backtrace) is true

RE: [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

> -Original Message- > From: Petr Mladek [mailto:pmla...@suse.com] > Sent: Wednesday, May 30, 2018 5:32 PM > To: Sergey Senozhatsky > Cc: Hoeun Ryu ; Sergey Senozhatsky > ; Steven Rostedt ; > Hoeun Ryu ; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] printk

RE: [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

> -Original Message- > From: Petr Mladek [mailto:pmla...@suse.com] > Sent: Wednesday, May 30, 2018 5:32 PM > To: Sergey Senozhatsky > Cc: Hoeun Ryu ; Sergey Senozhatsky > ; Steven Rostedt ; > Hoeun Ryu ; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] printk

RE: [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

I appreciate the detailed correction. I will reflect the corrections in the next patch. plus, the explanation in the code will be fixed. > -Original Message- > From: Petr Mladek [mailto:pmla...@suse.com] > Sent: Wednesday, May 30, 2018 5:32 PM > To: Sergey Senozhatsky >

RE: [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

I appreciate the detailed correction. I will reflect the corrections in the next patch. plus, the explanation in the code will be fixed. > -Original Message- > From: Petr Mladek [mailto:pmla...@suse.com] > Sent: Wednesday, May 30, 2018 5:32 PM > To: Sergey Senozhatsky >

RE: [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

> -Original Message- > From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com] > Sent: Tuesday, May 29, 2018 9:13 PM > To: Hoeun Ryu > Cc: Petr Mladek ; Sergey Senozhatsky > ; Steven Rostedt ; > Hoeun Ryu ; linux-kernel@vger.kernel.org > Subject:

RE: [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

> -Original Message- > From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com] > Sent: Tuesday, May 29, 2018 9:13 PM > To: Hoeun Ryu > Cc: Petr Mladek ; Sergey Senozhatsky > ; Steven Rostedt ; > Hoeun Ryu ; linux-kernel@vger.kernel.org > Subject:

[PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

From: Hoeun Ryu Make printk_safe_flush() safe in NMI context. nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the function is called in watchdog_overflow_callback() if the flag of hardlockup backtrace (sysctl_hardlockup_all_cpu_backtrace) is true

[PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing

From: Hoeun Ryu Make printk_safe_flush() safe in NMI context. nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the function is called in watchdog_overflow_callback() if the flag of hardlockup backtrace (sysctl_hardlockup_all_cpu_backtrace) is true

[PATCH] printk: make printk_safe_flush safe in NMI context

From: Hoeun Ryu Make printk_safe_flush() safe in NMI context. And printk_safe_flush_on_panic() is folded into this function. The prototype of printk_safe_flush() is changed to "void printk_safe_flush(bool panic)". nmi_trigger_cpumask_backtrace() can be called in NMI context. F

[PATCH] printk: make printk_safe_flush safe in NMI context

From: Hoeun Ryu Make printk_safe_flush() safe in NMI context. And printk_safe_flush_on_panic() is folded into this function. The prototype of printk_safe_flush() is changed to "void printk_safe_flush(bool panic)". nmi_trigger_cpumask_backtrace() can be called in NMI context. F

[PATCH] nmi_backtrace: use printk_safe_flush_on_panic when triggering backtraces

From: Hoeun Ryu <hoeun@lge.com> Use printk_safe_flush_on_panic() in nmi_trigger_cpumask_backtrace(). nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the function is called in watchdog_overflow_callback() if the flag of hardlockup bac

[PATCH] nmi_backtrace: use printk_safe_flush_on_panic when triggering backtraces

From: Hoeun Ryu Use printk_safe_flush_on_panic() in nmi_trigger_cpumask_backtrace(). nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the function is called in watchdog_overflow_callback() if the flag of hardlockup backtrace (sysctl_hardlockup_all_cpu_backtrace) is true

[PATCHv2] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

From: Hoeun Ryu <hoeun@lge.com> On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system. On the systems, a CPU can be interrupted by overflow irq but it is possible that the overflow actually occurs on another CPU. This patch broadcasts the irq

RE: [PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

��ȣ�� <hoeun@lge.com> > Cc: 'Hoeun Ryu' <hoeun@lge.com.com>; 'Will Deacon' > <will.dea...@arm.com>; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core system > having one muxed SP

[PATCHv2] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

From: Hoeun Ryu On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system. On the systems, a CPU can be interrupted by overflow irq but it is possible that the overflow actually occurs on another CPU. This patch broadcasts the irq using smp_call_function_single_async() so

RE: [PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

rote: > > Thank you for the reply. > > > > > -Original Message- > > > From: Mark Rutland [mailto:mark.rutl...@arm.com] > > > Sent: Thursday, May 10, 2018 7:21 PM > > > To: Hoeun Ryu > > > Cc: Will Deacon ; Hoeun Ryu ; > > > l

RE: smp_call_function() friends and irq/bottom_half context

> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Thursday, May 10, 2018 7:17 PM > To: ��ȣ�� > Cc: mi...@kernel.org; aaron...@intel.com; adobri...@gmail.com; > frede...@kernel.org; ying.hu...@intel.com; linux-kernel@vger.kernel.org >

RE: smp_call_function() friends and irq/bottom_half context

> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Thursday, May 10, 2018 7:17 PM > To: ��ȣ�� > Cc: mi...@kernel.org; aaron...@intel.com; adobri...@gmail.com; > frede...@kernel.org; ying.hu...@intel.com; linux-kernel@vger.kernel.org > Subject: Re:

[PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

From: Hoeun Ryu <hoeun@lge.com> On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system. On the systems, a CPU can be interrupted by overflow irq but it is possible that the overflow actually occurs on another CPU. This patch broadcasts the irq using smp_call_fu

[PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

From: Hoeun Ryu On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system. On the systems, a CPU can be interrupted by overflow irq but it is possible that the overflow actually occurs on another CPU. This patch broadcasts the irq using smp_call_function() so that other CPUs

[RFC 3/3] sched: depend on 64BIT_ATOMIC_ACCESS to determine if to use min_vruntime_copy

or not. And align 'min_vruntime' by 8 if 64BIT_ATOMIC_ALIGNED_ACCESS is true because 64BIT_ATOMIC_ALIGNED_ACCESS enabled system can access the variable atomically only when it' aligned. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- kernel/sched/fair.c | 6 +++--- kernel/sched/sched.h | 6 +++

[RFC 3/3] sched: depend on 64BIT_ATOMIC_ACCESS to determine if to use min_vruntime_copy

or not. And align 'min_vruntime' by 8 if 64BIT_ATOMIC_ALIGNED_ACCESS is true because 64BIT_ATOMIC_ALIGNED_ACCESS enabled system can access the variable atomically only when it' aligned. Signed-off-by: Hoeun Ryu --- kernel/sched/fair.c | 6 +++--- kernel/sched/sched.h | 6 +- 2 files changed, 8

[RFC 0/3] add 64BIT_ATOMIC_ACCESS and 64BIT_ATOMIC_ALIGNED_ACCESS

es (mostly removing seqlock to access the 64bit variables on the machines) if this approach is accepted. Hoeun Ryu (3): arch: add 64BIT_ATOMIC_ACCESS to support 64bit atomic access on 32bit machines arm: enable 64BIT_ATOMIC(_ALIGNED)_ACCESS on LPAE enabled machines sched: depend on 64BIT_ATO

[RFC 1/3] arch: add 64BIT_ATOMIC_ACCESS to support 64bit atomic access on 32bit machines

in the way of #ifdef. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/Kconfig | 20 1 file changed, 20 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 21d0089..1def331 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -115,6 +115,26 @@ config U

[RFC 0/3] add 64BIT_ATOMIC_ACCESS and 64BIT_ATOMIC_ALIGNED_ACCESS

es (mostly removing seqlock to access the 64bit variables on the machines) if this approach is accepted. Hoeun Ryu (3): arch: add 64BIT_ATOMIC_ACCESS to support 64bit atomic access on 32bit machines arm: enable 64BIT_ATOMIC(_ALIGNED)_ACCESS on LPAE enabled machines sched: depend on 64BIT_ATO

[RFC 1/3] arch: add 64BIT_ATOMIC_ACCESS to support 64bit atomic access on 32bit machines

in the way of #ifdef. Signed-off-by: Hoeun Ryu --- arch/Kconfig | 20 1 file changed, 20 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 21d0089..1def331 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -115,6 +115,26 @@ config UPROBES managed

[RFC 2/3] arm: enable 64BIT_ATOMIC(_ALIGNED)_ACCESS on LPAE enabled machines

64BIT_ATOMIC_ACCESS true, some kernel codes to access 64bit variables can be optimized by omitting seqlock or the mimic of it. Also make 64BIT_ATOMIC_ALIGNED_ACCESS true, the 64bit atomic access is guarnteed only when the address is 64bit algined. Signed-off-by: Hoeun Ryu <hoeun@gmail.

[RFC 2/3] arm: enable 64BIT_ATOMIC(_ALIGNED)_ACCESS on LPAE enabled machines

64BIT_ATOMIC_ACCESS true, some kernel codes to access 64bit variables can be optimized by omitting seqlock or the mimic of it. Also make 64BIT_ATOMIC_ALIGNED_ACCESS true, the 64bit atomic access is guarnteed only when the address is 64bit algined. Signed-off-by: Hoeun Ryu --- arch/arm/mm

Re: [PATCHv3] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

Hello, All. Would you please review this patch ? I haven't had any respond to this patch. Thank you. On Tue, 2017-08-08 at 10:22 +0900, Hoeun Ryu wrote: >  Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > version in panic path) introduced crash_smp_send_stop()

Re: [PATCHv3] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

Hello, All. Would you please review this patch ? I haven't had any respond to this patch. Thank you. On Tue, 2017-08-08 at 10:22 +0900, Hoeun Ryu wrote: >  Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > version in panic path) introduced crash_smp_send_stop()

[PATCHv3] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

;= save crash dump for nonpanic cores * crash_kexec_post_notifiers : true panic() crash_smp_send_stop()<= save crash dump for nonpanic cores __crash_kexec() machine_crash_shutdown() crash_smp_send_stop()<= just return. Signed-off-by: Hoeun Ryu <hoeun..

[PATCHv3] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

;= save crash dump for nonpanic cores * crash_kexec_post_notifiers : true panic() crash_smp_send_stop()<= save crash dump for nonpanic cores __crash_kexec() machine_crash_shutdown() crash_smp_send_stop()<= just return. Signed-off-by: Hoeun Ryu Revie

Re: [PATCHv2] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

Hello, James. Thank you for the meticulous test and review. On Fri, 2017-08-11 at 18:02 +0100, James Morse wrote: > Hi Hoeun, > > On 07/08/17 06:09, Hoeun Ryu wrote: > > > >  Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > > versio

Re: [PATCHv2] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

Hello, James. Thank you for the meticulous test and review. On Fri, 2017-08-11 at 18:02 +0100, James Morse wrote: > Hi Hoeun, > > On 07/08/17 06:09, Hoeun Ryu wrote: > > > >  Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > > versio

[PATCHv3] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

t implement this function like that because of the lack of IPI slots. Please see the commit e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI) Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- v3: - remove 'WARN_ON(num_online_cpus() > 1)' in machine_crash_shut

[PATCHv3] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

t implement this function like that because of the lack of IPI slots. Please see the commit e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI) Signed-off-by: Hoeun Ryu --- v3: - remove 'WARN_ON(num_online_cpus() > 1)' in machine_crash_shutdown(). it's a false check f

[PATCHv2] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

ash_smp_send_stop()<= save crash dump for nonpanic cores * crash_kexec_post_notifiers : true panic() crash_smp_send_stop()<= save crash dump for nonpanic cores __crash_kexec() machine_crash_shutdown() crash_smp_send_stop()<= just return. Signed

[PATCHv2] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

ash_smp_send_stop()<= save crash dump for nonpanic cores * crash_kexec_post_notifiers : true panic() crash_smp_send_stop()<= save crash dump for nonpanic cores __crash_kexec() machine_crash_shutdown() crash_smp_send_stop()<= just return. Signed-o

Re: [PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

> On 4 Aug 2017, at 8:43 PM, AKASHI Takahiro <takahiro.aka...@linaro.org> wrote: > >> On Fri, Aug 04, 2017 at 11:38:16AM +0100, James Morse wrote: >> Hi Hoeun, >> >>> On 04/08/17 08:02, Hoeun Ryu wrote: >>> Commit 0ee5941 : (x86/panic: replace

Re: [PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

> On 4 Aug 2017, at 8:43 PM, AKASHI Takahiro wrote: > >> On Fri, Aug 04, 2017 at 11:38:16AM +0100, James Morse wrote: >> Hi Hoeun, >> >>> On 04/08/17 08:02, Hoeun Ryu wrote: >>> Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump frie

Re: [PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

> On 4 Aug 2017, at 7:38 PM, James Morse <james.mo...@arm.com> wrote: > > Hi Hoeun, > >> On 04/08/17 08:02, Hoeun Ryu wrote: >> Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly >> version in panic path) introduced crash_smp_send_stop()

Re: [PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

> On 4 Aug 2017, at 7:38 PM, James Morse wrote: > > Hi Hoeun, > >> On 04/08/17 08:02, Hoeun Ryu wrote: >> Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly >> version in panic path) introduced crash_smp_send_stop() which is a weak &g

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

2017. 8. 4. 오후 7:04 Robin Murphy <robin.mur...@arm.com> 작성: >> On 04/08/17 07:07, Hoeun Ryu wrote: >> Hello, Russell King. >> >> The following patch has not merged yet. >> Do you have a plan to accept and merge this patch ? > > This should probably

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

2017. 8. 4. 오후 7:04 Robin Murphy 작성: >> On 04/08/17 07:07, Hoeun Ryu wrote: >> Hello, Russell King. >> >> The following patch has not merged yet. >> Do you have a plan to accept and merge this patch ? > > This should probably go through the ARM tree, so p

[PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

crash_shutdown() tries to save crash information for nonpanic CPUs only when crash_kexec_post_notifiers kernel option is disabled. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/arm64/kernel/machine_kexec.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletio

[PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

crash_shutdown() tries to save crash information for nonpanic CPUs only when crash_kexec_post_notifiers kernel option is disabled. Signed-off-by: Hoeun Ryu --- arch/arm64/kernel/machine_kexec.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel

[PATCHv2] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

t implement this function like that because of the lack of IPI slots. Please see the commit e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI) Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- v2: - calling crash_smp_send_stop() in machine_crash_shutdown() for the case

[PATCHv2] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

t implement this function like that because of the lack of IPI slots. Please see the commit e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI) Signed-off-by: Hoeun Ryu --- v2: - calling crash_smp_send_stop() in machine_crash_shutdown() for the case when crash_kexec_post_noti

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Hello, Russell King. The following patch has not merged yet. Do you have a plan to accept and merge this patch ? Thank you. On Mon, 2017-06-12 at 10:47 +0900, Hoeun Ryu wrote: >  Reading TTBCR in early boot stage might return the value of the previous > kernel's configuration, espe

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Hello, Russell King. The following patch has not merged yet. Do you have a plan to accept and merge this patch ? Thank you. On Mon, 2017-06-12 at 10:47 +0900, Hoeun Ryu wrote: >  Reading TTBCR in early boot stage might return the value of the previous > kernel's configuration, espe

[PATCH] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

see the commit e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI) Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/arm/kernel/machine_kexec.c | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/arc

[PATCH] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

see the commit e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI) Signed-off-by: Hoeun Ryu --- arch/arm/kernel/machine_kexec.c | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/arch/arm/kernel/machine_kexec.c

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Hello, Russell King. Do you have a plan to include this patch in your tree ? Thank you. On Mon, 2017-06-12 at 10:47 +0900, Hoeun Ryu wrote: >  Reading TTBCR in early boot stage might return the value of the > previous > kernel's configuration, especially in case of kexec. Fo

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Hello, Russell King. Do you have a plan to include this patch in your tree ? Thank you. On Mon, 2017-06-12 at 10:47 +0900, Hoeun Ryu wrote: >  Reading TTBCR in early boot stage might return the value of the > previous > kernel's configuration, especially in case of kexec. Fo

Re: [RESEND PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

On Tue, 2017-06-13 at 22:27 -0700, Tony Lindgren wrote: > Hi, > > * Hoeun Ryu <hoeun@gmail.com> [170612 18:18]: > > > > --- a/arch/arm/include/debug/omap2plus.S > > +++ b/arch/arm/include/debug/omap2plus.S > > @@ -58,11 +58,22 @@ > >   > &g

Re: [RESEND PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

On Tue, 2017-06-13 at 22:27 -0700, Tony Lindgren wrote: > Hi, > > * Hoeun Ryu [170612 18:18]: > > > > --- a/arch/arm/include/debug/omap2plus.S > > +++ b/arch/arm/include/debug/omap2plus.S > > @@ -58,11 +58,22 @@ > >   > >  #d

[RESEND PATCH 2/2] arm:omap2+: drop dependence on DEBUG_OMAP2PLUS_UART for DEBUG_UNCOMPRESS

when it's included in the decompressor. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- * mail to relevant recipients, no response yet from them. - add TO=Tony Lindgren <t...@atomide.com> - add CC=linux-o...@vger.kernel.org * indentical to previous patch arch/arm/Kconfig.debug |

[RESEND PATCH 2/2] arm:omap2+: drop dependence on DEBUG_OMAP2PLUS_UART for DEBUG_UNCOMPRESS

when it's included in the decompressor. Signed-off-by: Hoeun Ryu --- * mail to relevant recipients, no response yet from them. - add TO=Tony Lindgren - add CC=linux-o...@vger.kernel.org * indentical to previous patch arch/arm/Kconfig.debug | 3 +-- 1 file changed, 1 insertion(+), 2 deletion

[RESEND PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

is included in the other kernel parts like arch/arm/kernel/* Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- * to mail to relevant recipients, no respond yet from them - TO=Tony Lindgren <t...@atomide.com> - CC=linux-o...@vger.kernel.org * indentical to previous patch arch/arm/i

[RESEND PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

is included in the other kernel parts like arch/arm/kernel/* Signed-off-by: Hoeun Ryu --- * to mail to relevant recipients, no respond yet from them - TO=Tony Lindgren - CC=linux-o...@vger.kernel.org * indentical to previous patch arch/arm/include/debug/omap2plus.S | 11 +++ 1 file

[PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Robin Murphy <robin.mur...@arm.com> Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- * add Acked-by: Russell King <rmk+ker...@armlinux.org.uk> * v1: amended based on - "[PATCHv2] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET&

[PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

ion PHYS_OFFSET > PAGE_OFFSET, which can happen because it depends on the reserved area for crash kernel, reading TTBCR and using the value to OR other bit fields might be risky because it doesn't have a reset value for TTBCR. Acked-by: Russell King Suggested-by: Robin Murphy Signed-off-by: Hoe

Re: [PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

Hello, Russell. Would you please review this patch ? Than you > On Jun 8, 2017, at 11:16 AM, Hoeun Ryu <hoeun@gmail.com> wrote: > > omap_uart_phys, omap_uart_virt and omap_uart_lsr reside in .data section > and it's right implementation. But because of this

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Hello, Russell and Robin. Would you please review this patch ? Than you > On Jun 7, 2017, at 11:39 AM, Hoeun Ryu <hoeun@gmail.com> wrote: > > Reading TTBCR in early boot stage might return the value of the previous > kernel's configuration, especially in case of

Re: [PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

Hello, Russell. Would you please review this patch ? Than you > On Jun 8, 2017, at 11:16 AM, Hoeun Ryu wrote: > > omap_uart_phys, omap_uart_virt and omap_uart_lsr reside in .data section > and it's right implementation. But because of this, we cannot enable > CONFIG_DEBUG_UNCOM

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

Hello, Russell and Robin. Would you please review this patch ? Than you > On Jun 7, 2017, at 11:39 AM, Hoeun Ryu wrote: > > Reading TTBCR in early boot stage might return the value of the previous > kernel's configuration, especially in case of kexec. For example, if > norma

[PATCH 2/2] arm:omap2+: drop dependence on DEBUG_OMAP2PLUS_UART for DEBUG_UNCOMPRESS

when it's included in the decompressor. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/arm/Kconfig.debug | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index ba2cb63..52eb0bf 100644 --- a/arch/arm/Kconfig.debu

[PATCH 2/2] arm:omap2+: drop dependence on DEBUG_OMAP2PLUS_UART for DEBUG_UNCOMPRESS

when it's included in the decompressor. Signed-off-by: Hoeun Ryu --- arch/arm/Kconfig.debug | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index ba2cb63..52eb0bf 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug

[PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

is included in the other kernel parts like arch/arm/kernel/* Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/arm/include/debug/omap2plus.S | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..6

[PATCH 1/2] arm:omap2+: put omap_uart_phys/virt/lsr in .text section when ZIMAGE is true

is included in the other kernel parts like arch/arm/kernel/* Signed-off-by: Hoeun Ryu --- arch/arm/include/debug/omap2plus.S | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..6ce6ef9 100644 --- a/arch/arm

[PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

ion PHYS_OFFSET > PAGE_OFFSET, which can happen because it depends on the reserved area for crash kernel, reading TTBCR and using the value to OR other bit fields might be risky because it doesn't have a reset value for TTBCR. Suggested-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Hoeu

[PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

ion PHYS_OFFSET > PAGE_OFFSET, which can happen because it depends on the reserved area for crash kernel, reading TTBCR and using the value to OR other bit fields might be risky because it doesn't have a reset value for TTBCR. Suggested-by: Robin Murphy Signed-off-by: Hoeun Ryu --- * v1: amended

Re: [PATCHv2] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

>> On Jun 5, 2017, at 7:30 PM, Robin Murphy <robin.mur...@arm.com> wrote: >> >> On 05/06/17 11:06, Hoeun Ryu wrote: >> Clearing TTBCR.T1SZ explicitly when kernel runs on a configuration of >> PHYS_OFFSET > PAGE_OFFSET. >> Reading TTBC

Re: [PATCHv2] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

>> On Jun 5, 2017, at 7:30 PM, Robin Murphy wrote: >> >> On 05/06/17 11:06, Hoeun Ryu wrote: >> Clearing TTBCR.T1SZ explicitly when kernel runs on a configuration of >> PHYS_OFFSET > PAGE_OFFSET. >> Reading TTBCR in early boot stage might return

[PATCHv2] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

sn't have a reset value for TTBCR.T1SZ. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/arm/mm/proc-v7-3level.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S index 5e5720e..81404b8 100644 --- a/arch/arm/mm/proc-v7-3lev

[PATCHv2] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

sn't have a reset value for TTBCR.T1SZ. Signed-off-by: Hoeun Ryu --- arch/arm/mm/proc-v7-3level.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S index 5e5720e..81404b8 100644 --- a/arch/arm/mm/proc-v7-3level.S +++ b/arch/arm/m

Re: [PATCH] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

On Mon, Jun 5, 2017 at 6:34 PM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Mon, Jun 05, 2017 at 06:22:20PM +0900, Hoeun Ryu wrote: >> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S >> index 5e5720e..9ac2bec 100644 >> --- a/a

Re: [PATCH] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

On Mon, Jun 5, 2017 at 6:34 PM, Russell King - ARM Linux wrote: > On Mon, Jun 05, 2017 at 06:22:20PM +0900, Hoeun Ryu wrote: >> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S >> index 5e5720e..9ac2bec 100644 >> --- a/arch/arm/mm/proc-v7-3level.S >

[PATCH] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

sn't have a reset value for TTBCR.T1SZ. Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- arch/arm/mm/proc-v7-3level.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S index 5e5720e..9ac2bec 100644 --- a/arch/arm/mm/proc-v7-3lev

[PATCH] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when PHYS_OFFSET > PAGE_OFFSET

sn't have a reset value for TTBCR.T1SZ. Signed-off-by: Hoeun Ryu --- arch/arm/mm/proc-v7-3level.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S index 5e5720e..9ac2bec 100644 --- a/arch/arm/mm/proc-v7-3level.S +++ b/arch/arm/m

Re: [PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 18, 2017, at 3:59 PM, Michal Hocko <mho...@kernel.org> wrote: > >> On Tue 18-04-17 14:48:39, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mapped areas are never

Re: [PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 18, 2017, at 3:59 PM, Michal Hocko wrote: > >> On Tue 18-04-17 14:48:39, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mapped areas are never unmapped. >> So `O

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

the rbtree by accident. This flags can be also used by other vmalloc APIs to specify that the area will never go away. This makes remove_vm_area() more robust against other kind of errors (eg. programming errors). Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- v2: - update changelog

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

the rbtree by accident. This flags can be also used by other vmalloc APIs to specify that the area will never go away. This makes remove_vm_area() more robust against other kind of errors (eg. programming errors). Signed-off-by: Hoeun Ryu --- v2: - update changelog - add description to VM_STATIC

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

the rbtree by accident. This flags can be also used by other vmalloc APIs to specify that the area will never go away. This makes remove_vm_area() more robust against other kind of errors (eg. programming errors). Signed-off-by: Hoeun Ryu <hoeun@gmail.com> --- v2: - update changelog

[PATCH v2] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

the rbtree by accident. This flags can be also used by other vmalloc APIs to specify that the area will never go away. This makes remove_vm_area() more robust against other kind of errors (eg. programming errors). Signed-off-by: Hoeun Ryu --- v2: - update changelog - add description to VM_STATIC

Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 13, 2017, at 1:17 PM, Anshuman Khandual <khand...@linux.vnet.ibm.com> > wrote: > >> On 04/12/2017 10:31 AM, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mappe

Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 13, 2017, at 1:17 PM, Anshuman Khandual > wrote: > >> On 04/12/2017 10:31 AM, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mapped areas are never unmapped

Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 12, 2017, at 3:02 PM, Christoph Hellwig <h...@infradead.org> wrote: > >> On Wed, Apr 12, 2017 at 02:01:59PM +0900, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually m

Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas

> On Apr 12, 2017, at 3:02 PM, Christoph Hellwig wrote: > >> On Wed, Apr 12, 2017 at 02:01:59PM +0900, Hoeun Ryu wrote: >> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area >> during boot process and those virtually mapped areas are never unmapp

  1   2   >