[PATCH] mm: slub: re-initialize randomized freelist sequence in calculate_sizes

2020-08-08 Thread kpark3469
From: Sahara Slab cache flags are exported to sysfs and are allowed to get modified from userspace. Some of those may call calculate_sizes function because the changed flag can take an effect on slab object size and layout, which means kmem_cache may have different order and objects. The

[PATCH] tty: serial_core: recover uport->cons->cflag on uart_close

2019-06-16 Thread kpark3469
From: Sahara Since uart_close was converted to use tty_port_close, uart_shutdown also moved to uart_tty_port_shutdown, which means it does not backup tty's termios to uart_port.console.cflag when console is closed and uart_console is true. By losing this value, serial console was not set

[PATCH] tty: pty: Fix race condition between release_one_tty and pty_write

2019-02-10 Thread kpark3469
From: Sahara Especially when a linked tty is used such as pty, the linked tty port's buf works have not been cancelled while master tty port's buf work has been cancelled. Since release_one_tty and flush_to_ldisc run in workqueue threads separately, when pty_cleanup happens and link tty port is

[PATCH v2] mm: clean up page_is_poisoned in linux/mm.h

2018-06-04 Thread kpark3469
From: Sahara When bd33ef368135("mm: enable page poisoning early at boot") got rid of the PAGE_EXT_DEBUG_POISON, page_is_poisoned in the header left behind. This patch cleans up the leftovers under the table. Acked-by: Michal Hocko Signed-off-by: Sahara --- include/linux/mm.h | 2 -- 1 file

[PATCH v2] mm: clean up page_is_poisoned in linux/mm.h

2018-06-04 Thread kpark3469
From: Sahara When bd33ef368135("mm: enable page poisoning early at boot") got rid of the PAGE_EXT_DEBUG_POISON, page_is_poisoned in the header left behind. This patch cleans up the leftovers under the table. Acked-by: Michal Hocko Signed-off-by: Sahara --- include/linux/mm.h | 2 -- 1 file

[PATCH] mm: clean up page_is_poisoned in linux/mm.h

2018-06-03 Thread kpark3469
From: Sahara When bd33ef36("mm: enable page poisoning early at boot") got rid of the PAGE_EXT_DEBUG_POISON, page_is_poisoned in the header left behind. This patch cleans up the leftovers under the table. Signed-off-by: Sahara --- include/linux/mm.h | 2 -- 1 file changed, 2 deletions(-) diff

[PATCH] mm: clean up page_is_poisoned in linux/mm.h

2018-06-03 Thread kpark3469
From: Sahara When bd33ef36("mm: enable page poisoning early at boot") got rid of the PAGE_EXT_DEBUG_POISON, page_is_poisoned in the header left behind. This patch cleans up the leftovers under the table. Signed-off-by: Sahara --- include/linux/mm.h | 2 -- 1 file changed, 2 deletions(-) diff

[PATCH v4 3/3] x86: usercopy: reimplement arch_within_stack_frames with unwinder

2018-04-10 Thread kpark3469
From: Sahara The old arch_within_stack_frames which used the frame pointer is now reimplemented to use frame pointer unwinder apis. So the main functionality is same as before. Signed-off-by: Sahara --- arch/x86/include/asm/unwind.h | 5

[PATCH v4 3/3] x86: usercopy: reimplement arch_within_stack_frames with unwinder

2018-04-10 Thread kpark3469
From: Sahara The old arch_within_stack_frames which used the frame pointer is now reimplemented to use frame pointer unwinder apis. So the main functionality is same as before. Signed-off-by: Sahara --- arch/x86/include/asm/unwind.h | 5 arch/x86/kernel/stacktrace.c | 64

[PATCH v4 0/3] usercopy: reimplement arch_within_stack_frames

2018-04-10 Thread kpark3469
From: Sahara This series of patches introduce the arm64 arch_within_stack_frames implementation using stacktrace functions. Also the base code is moved from thread_info.h to stacktrace.h. x86 code is reimplemented to use frame pointer unwinder functions. Note: The

[PATCH v4 0/3] usercopy: reimplement arch_within_stack_frames

2018-04-10 Thread kpark3469
From: Sahara This series of patches introduce the arm64 arch_within_stack_frames implementation using stacktrace functions. Also the base code is moved from thread_info.h to stacktrace.h. x86 code is reimplemented to use frame pointer unwinder functions. Note: The code is still missing in case

[PATCH v4 2/3] arm64: usercopy: implement arch_within_stack_frames

2018-04-10 Thread kpark3469
From: James Morse This implements arch_within_stack_frames() for arm64 that should validate if a given object is contained by a kernel stack frame. Signed-off-by: James Morse Reviewed-by: Sahara Reviewed-by: Kees Cook

[PATCH v4 1/3] stacktrace: move arch_within_stack_frames from thread_info.h

2018-04-10 Thread kpark3469
From: Sahara Since the inlined arch_within_stack_frames function was placed within asm/thread_info.h, using stacktrace functions to unwind stack was restricted. Now in order to have this function use more abundant apis, it is moved to architecture's stacktrace.c. And,

[PATCH v4 2/3] arm64: usercopy: implement arch_within_stack_frames

2018-04-10 Thread kpark3469
From: James Morse This implements arch_within_stack_frames() for arm64 that should validate if a given object is contained by a kernel stack frame. Signed-off-by: James Morse Reviewed-by: Sahara Reviewed-by: Kees Cook --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/stacktrace.c

[PATCH v4 1/3] stacktrace: move arch_within_stack_frames from thread_info.h

2018-04-10 Thread kpark3469
From: Sahara Since the inlined arch_within_stack_frames function was placed within asm/thread_info.h, using stacktrace functions to unwind stack was restricted. Now in order to have this function use more abundant apis, it is moved to architecture's stacktrace.c. And, it is changed from inline

[PATCH v3 3/3] x86: usercopy: reimplement arch_within_stack_frames with unwinder

2018-04-09 Thread kpark3469
From: Sahara The old arch_within_stack_frames which used the frame pointer is now reimplemented to use frame pointer unwinder apis. So the main functionality is same as before. Signed-off-by: Sahara --- arch/x86/include/asm/unwind.h | 5

[PATCH v3 3/3] x86: usercopy: reimplement arch_within_stack_frames with unwinder

2018-04-09 Thread kpark3469
From: Sahara The old arch_within_stack_frames which used the frame pointer is now reimplemented to use frame pointer unwinder apis. So the main functionality is same as before. Signed-off-by: Sahara --- arch/x86/include/asm/unwind.h | 5 arch/x86/kernel/stacktrace.c | 64

[PATCH v3 2/3] arm64: usercopy: implement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: James Morse This implements arch_within_stack_frames() for arm64 that should validate if a given object is contained by a kernel stack frame. Signed-off-by: James Morse Reviewed-by: Sahara Reviewed-by: Kees Cook

[PATCH v3 2/3] arm64: usercopy: implement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: James Morse This implements arch_within_stack_frames() for arm64 that should validate if a given object is contained by a kernel stack frame. Signed-off-by: James Morse Reviewed-by: Sahara Reviewed-by: Kees Cook --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/stacktrace.c

[PATCH v3 1/3] stacktrace: move arch_within_stack_frames from thread_info.h

2018-04-09 Thread kpark3469
From: Sahara Since the inlined arch_within_stack_frames function was placed within asm/thread_info.h, using stacktrace functions to unwind stack was restricted. Now in order to have this function use more abundant apis, it is moved to architecture's stacktrace.c. And,

[PATCH v3 1/3] stacktrace: move arch_within_stack_frames from thread_info.h

2018-04-09 Thread kpark3469
From: Sahara Since the inlined arch_within_stack_frames function was placed within asm/thread_info.h, using stacktrace functions to unwind stack was restricted. Now in order to have this function use more abundant apis, it is moved to architecture's stacktrace.c. And, it is changed from inline

[PATCH v3 0/3] usercopy: reimplement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: Sahara This series of patches introduce the arm64 arch_within_stack_frames implementation using stacktrace functions. Also the base code is moved from thread_info.h to stacktrace.h. x86 code is reimplemented to use frame pointer unwinder functions. Note: The

[PATCH v3 0/3] usercopy: reimplement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: Sahara This series of patches introduce the arm64 arch_within_stack_frames implementation using stacktrace functions. Also the base code is moved from thread_info.h to stacktrace.h. x86 code is reimplemented to use frame pointer unwinder functions. Note: The code is still missing in case

[PATCH v2 2/3] arm64: usercopy: implement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: James Morse This implements arch_within_stack_frames() for arm64 that should validate if a given object is contained by a kernel stack frame. Signed-off-by: James Morse Reviewed-by: Sahara Reviewed-by: Kees Cook

[PATCH v2 3/3] x86: usercopy: reimplement arch_within_stack_frames with unwinder

2018-04-09 Thread kpark3469
From: Sahara The old arch_within_stack_frames which used the frame pointer is now reimplemented to use frame pointer unwinder apis. So the main functionality is same as before. Signed-off-by: Sahara --- arch/x86/include/asm/unwind.h | 5

[PATCH v2 2/3] arm64: usercopy: implement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: James Morse This implements arch_within_stack_frames() for arm64 that should validate if a given object is contained by a kernel stack frame. Signed-off-by: James Morse Reviewed-by: Sahara Reviewed-by: Kees Cook --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/stacktrace.c

[PATCH v2 3/3] x86: usercopy: reimplement arch_within_stack_frames with unwinder

2018-04-09 Thread kpark3469
From: Sahara The old arch_within_stack_frames which used the frame pointer is now reimplemented to use frame pointer unwinder apis. So the main functionality is same as before. Signed-off-by: Sahara --- arch/x86/include/asm/unwind.h | 5 arch/x86/kernel/stacktrace.c | 64

[PATCH v2 1/3] stacktrace: move arch_within_stack_frames from thread_info.h

2018-04-09 Thread kpark3469
From: Sahara Since the inlined arch_within_stack_frames function was placed within asm/thread_info.h, using stacktrace functions to unwind stack was restricted. Now in order to have this function use more abundant apis, it is moved to architecture's stacktrace.c. And,

[PATCH v2 1/3] stacktrace: move arch_within_stack_frames from thread_info.h

2018-04-09 Thread kpark3469
From: Sahara Since the inlined arch_within_stack_frames function was placed within asm/thread_info.h, using stacktrace functions to unwind stack was restricted. Now in order to have this function use more abundant apis, it is moved to architecture's stacktrace.c. And, it is changed from inline

[PATCH v2 0/3] usercopy: reimplement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: Sahara This series of patches introduce the arm64 arch_within_stack_frames implementation using stacktrace functions. Also the base code is moved from thread_info.h to stacktrace.h. x86 code is reimplemented to use frame pointer unwinder functions. Note: The

[PATCH v2 0/3] usercopy: reimplement arch_within_stack_frames

2018-04-09 Thread kpark3469
From: Sahara This series of patches introduce the arm64 arch_within_stack_frames implementation using stacktrace functions. Also the base code is moved from thread_info.h to stacktrace.h. x86 code is reimplemented to use frame pointer unwinder functions. Note: The code is still missing in case

[PATCH] pty: cancel pty slave port buf's work in tty_release

2017-12-12 Thread kpark3469
From: Sahara In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with

[PATCH] pty: cancel pty slave port buf's work in tty_release

2017-12-12 Thread kpark3469
From: Sahara In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with POISON_FREE value. So far

[PATCH] ARM: compressed/head.S: use addruart properly

2014-08-26 Thread kpark3469
From: Sahara This patch fixes compile error in compressed/head.S, when DEBUG is defined. Since addruart macro accepts 3 params, rp, rv, and tmp, loadsp macro also needs to be fixed. Or you will meet the following error messages: Error: ARM register expected -- `mov ,#(5<<1)' Error: shift

[PATCHv2] ARM: debug: uncompress debug support for omap2plus

2014-08-26 Thread kpark3469
From: Sahara Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system. Signed-off-by: Sahara

[PATCHv2] ARM: debug: uncompress debug support for omap2plus

2014-08-26 Thread kpark3469
From: Sahara Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system. Signed-off-by: Sahara

[PATCHv2] ARM: debug: uncompress debug support for omap2plus

2014-08-26 Thread kpark3469
From: Sahara keun-o.p...@windriver.com Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system.

[PATCHv2] ARM: debug: uncompress debug support for omap2plus

2014-08-26 Thread kpark3469
From: Sahara keun-o.p...@windriver.com Since OMAP low-level debug code places data in the .data section, The symbol DEBUG_UNCOMPRESS was defined with !DEBUG_OMAP2PLUS_UART. This patch removes the part using data section in debug/omap2plus.S, so DEBUG_UNCOMPRESS is now available on OMAP system.

[PATCH] ARM: compressed/head.S: use addruart properly

2014-08-26 Thread kpark3469
From: Sahara keun-o.p...@windriver.com This patch fixes compile error in compressed/head.S, when DEBUG is defined. Since addruart macro accepts 3 params, rp, rv, and tmp, loadsp macro also needs to be fixed. Or you will meet the following error messages: Error: ARM register expected -- `mov

[PATCH] earlyprintk: re-enable earlyprintk calling early_param

2014-08-14 Thread kpark3469
From: Sahara Although there are many obs_kernel_param and its names are earlyprintk and also EARLY_PRINTK is also enabled, we could not see the early_printk output properly until now. This patch considers earlycon as well as earlyprintk. Signed-off-by: Sahara --- init/main.c |3 ++- 1

[PATCH] earlyprintk: re-enable earlyprintk calling early_param

2014-08-14 Thread kpark3469
From: Sahara keun-o.p...@windriver.com Although there are many obs_kernel_param and its names are earlyprintk and also EARLY_PRINTK is also enabled, we could not see the early_printk output properly until now. This patch considers earlycon as well as earlyprintk. Signed-off-by: Sahara

[PATCH] ARM: compressed/head.S: use addruart properly

2014-08-13 Thread kpark3469
From: Sahara This patch fixes compile error in compressed/head.S, when DEBUG is defined. Since addruart macro accepts 3 params, rp, rv, and tmp, loadsp macro also needs to be fixed. Or you will meet the following error messages: Error: ARM register expected -- `mov ,#(5<<1)' Error: shift

[PATCH] ARM: compressed/head.S: use addruart properly

2014-08-13 Thread kpark3469
From: Sahara keun-o.p...@windriver.com This patch fixes compile error in compressed/head.S, when DEBUG is defined. Since addruart macro accepts 3 params, rp, rv, and tmp, loadsp macro also needs to be fixed. Or you will meet the following error messages: Error: ARM register expected -- `mov

[PATCH 2/2] xen/trace: replace old code with __print_symbolic

2013-08-05 Thread kpark3469
From: Sahara The advantage of using __print_symbolic() is that it allows both perf and trace-cmd to read this event properly. Their parsers are not full C parsers, and when you open code the the processing, they both will fail to parse how to read the output, and will just default to printing

[PATCH 1/2] PM / QoS: use __print_symbolic with more convenient way

2013-08-05 Thread kpark3469
From: Sahara This patch is to prevent the same __print_symbolic functions from being used repeatedly. Signed-off-by: Sahara --- include/trace/events/power.h | 43 + 1 files changed, 22 insertions(+), 21 deletions(-) diff --git

[PATCH 1/2] PM / QoS: use __print_symbolic with more convenient way

2013-08-05 Thread kpark3469
From: Sahara keun-o.p...@windriver.com This patch is to prevent the same __print_symbolic functions from being used repeatedly. Signed-off-by: Sahara keun-o.p...@windriver.com --- include/trace/events/power.h | 43 + 1 files changed, 22 insertions(+),

[PATCH 2/2] xen/trace: replace old code with __print_symbolic

2013-08-05 Thread kpark3469
From: Sahara keun-o.p...@windriver.com The advantage of using __print_symbolic() is that it allows both perf and trace-cmd to read this event properly. Their parsers are not full C parsers, and when you open code the the processing, they both will fail to parse how to read the output, and will

[PATCH v3] tracepoints: prevents null probe from being added

2013-04-14 Thread kpark3469
From: Sahara Somehow tracepoint_entry_add_probe function allows a null probe function. And, this may lead to unexpected result since the number of probe functions in an entry can be counted by checking whether probe is null or not in for-loop. This patch prevents the null probe from being added.

[PATCH v3] tracepoints: prevents null probe from being added

2013-04-14 Thread kpark3469
From: Sahara keun-o.p...@windriver.com Somehow tracepoint_entry_add_probe function allows a null probe function. And, this may lead to unexpected result since the number of probe functions in an entry can be counted by checking whether probe is null or not in for-loop. This patch prevents the

[PATCH] ptp_pch: eliminate a number of sparse warnings

2013-03-25 Thread kpark3469
From: Sahara This fixes a number of sparse warnings like: warning: incorrect type in argument 2 (different address spaces) expected void volatile [noderef] *addr got unsigned int * warning: Using plain integer as NULL pointer Additionally this fixes a warning from checkpatch.pl

[PATCH] ptp_pch: eliminate a number of sparse warnings

2013-03-25 Thread kpark3469
From: Sahara keun-o.p...@windriver.com This fixes a number of sparse warnings like: warning: incorrect type in argument 2 (different address spaces) expected void volatile [noderef] asn:2*addr got unsigned int *noident warning: Using plain integer as NULL pointer Additionally this

[PATCH v2] tracepoints: prevents null probe from being added

2013-03-20 Thread kpark3469
From: Sahara Somehow tracepoint_entry_add_probe function allows a null probe function. And, this may lead to unexpected result since the number of probe functions in an entry can be counted by checking whether probe is null or not in for-loop. This patch prevents the null probe from being added.

[PATCH v2] tracepoints: prevents null probe from being added

2013-03-20 Thread kpark3469
From: Sahara keun-o.p...@windriver.com Somehow tracepoint_entry_add_probe function allows a null probe function. And, this may lead to unexpected result since the number of probe functions in an entry can be counted by checking whether probe is null or not in for-loop. This patch prevents the

[PATCH] tracepoints: prevents null probe from being added

2013-03-19 Thread kpark3469
From: Sahara Somehow tracepoint_entry_add/remove_probe functions allow a null probe function. Especially on getting a null probe in remove function, it seems to be used to remove all probe functions in the entry. But, the code is not handled as expected. Since the tracepoint_entry maintains

[PATCH] tracepoints: prevents null probe from being added

2013-03-19 Thread kpark3469
From: Sahara keun-o.p...@windriver.com Somehow tracepoint_entry_add/remove_probe functions allow a null probe function. Especially on getting a null probe in remove function, it seems to be used to remove all probe functions in the entry. But, the code is not handled as expected. Since the

[PATCH v3] arm: fix a wrong value returned from CALLER_ADDRn

2013-03-13 Thread kpark3469
From: Sahara This makes return_address() return a correct value for CALLER_ADDRn. To have a correct value from CALLER_ADDRn, we need to fix three points. * The unwind_frame() does not update frame->lr but frame->pc for backtrace. So frame->pc is meaningful for backtrace. * data.level should be

[PATCH v3] arm: fix a wrong value returned from CALLER_ADDRn

2013-03-13 Thread kpark3469
From: Sahara keun-o.p...@windriver.com This makes return_address() return a correct value for CALLER_ADDRn. To have a correct value from CALLER_ADDRn, we need to fix three points. * The unwind_frame() does not update frame-lr but frame-pc for backtrace. So frame-pc is meaningful for backtrace.

[PATCH v2] arm: fix returning wrong CALLER_ADDRx

2013-01-29 Thread kpark3469
From: sahara This makes return_address return correct value for ftrace feature. unwind_frame does not update frame->lr but frame->pc for backtrace. And, the initialization for data.addr was missing so that wrong value returned when unwind_frame failed. Signed-off-by: Sahara Reviewed-by: Dave

[PATCH v2] arm: fix returning wrong CALLER_ADDRx

2013-01-29 Thread kpark3469
From: sahara keun-o.p...@windriver.com This makes return_address return correct value for ftrace feature. unwind_frame does not update frame-lr but frame-pc for backtrace. And, the initialization for data.addr was missing so that wrong value returned when unwind_frame failed. Signed-off-by:

[PATCH 1/2] arm: fix returning wrong CALLER_ADDRx

2013-01-03 Thread kpark3469
From: sahara This makes return_address return correct value for ftrace feature. unwind_frame does not update frame->lr but frame->pc for backtrace. And, the initialization for data.addr was missing so that wrong value returned when unwind_frame failed. Signed-off-by: sahara ---

[PATCH 2/2] arm: make return_address available for ARM_UNWIND

2013-01-03 Thread kpark3469
From: sahara This fixes a warning saying: warning: #warning "TODO: return_address should use unwind tables" And, this enables return_address using unwind information. If ARM_UNWIND is selected, unwind_frame in unwind.c will be called in walk_stackframe. Signed-off-by: sahara ---

[PATCH 2/2] arm: make return_address available for ARM_UNWIND

2013-01-03 Thread kpark3469
From: sahara keun-o.p...@windriver.com This fixes a warning saying: warning: #warning TODO: return_address should use unwind tables And, this enables return_address using unwind information. If ARM_UNWIND is selected, unwind_frame in unwind.c will be called in walk_stackframe.

[PATCH 1/2] arm: fix returning wrong CALLER_ADDRx

2013-01-03 Thread kpark3469
From: sahara keun-o.p...@windriver.com This makes return_address return correct value for ftrace feature. unwind_frame does not update frame-lr but frame-pc for backtrace. And, the initialization for data.addr was missing so that wrong value returned when unwind_frame failed. Signed-off-by: