Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/11/1 5:59, Steven Rostedt wrote: On Mon, 30 Oct 2017 17:03:23 +0900 Masami Hiramatsu wrote: static LIST_HEAD(smp_alt_modules); -static DEFINE_MUTEX(smp_alt); -static bool uniproc_patched = false; /* protected by smp_alt */ +static bool uniproc_patched = false;

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/11/1 5:59, Steven Rostedt wrote: On Mon, 30 Oct 2017 17:03:23 +0900 Masami Hiramatsu wrote: static LIST_HEAD(smp_alt_modules); -static DEFINE_MUTEX(smp_alt); -static bool uniproc_patched = false; /* protected by smp_alt */ +static bool uniproc_patched = false; /* protected by

Re: [PATCH 2/4] x86/alternatives: Don't need text_mutex when text_poke() on UP

Oops, this is very wrong. Please ignore this patchset. Sorry for the noise... Thanks! On 2017/10/28 20:50, Zhou Chengming wrote: The alternatives_smp_lock/unlock only be used on UP, so we don't need to hold the text_mutex when text_poke(). Then in the next patch, we can remove the outside

Re: [PATCH 2/4] x86/alternatives: Don't need text_mutex when text_poke() on UP

Oops, this is very wrong. Please ignore this patchset. Sorry for the noise... Thanks! On 2017/10/28 20:50, Zhou Chengming wrote: The alternatives_smp_lock/unlock only be used on UP, so we don't need to hold the text_mutex when text_poke(). Then in the next patch, we can remove the outside

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/28 16:43, Masami Hiramatsu wrote: On Fri, 27 Oct 2017 21:30:24 +0800 zhouchengming<zhouchengmi...@huawei.com> wrote: On 2017/10/27 20:33, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: This is a real bug happened on one of our ma

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/28 16:43, Masami Hiramatsu wrote: On Fri, 27 Oct 2017 21:30:24 +0800 zhouchengming wrote: On 2017/10/27 20:33, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: This is a real bug happened on one of our machines, below is the calltrace. We can

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/27 22:15, Peter Zijlstra wrote: On Fri, Oct 27, 2017 at 02:33:48PM +0200, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: This is a real bug happened on one of our machines, below is the calltrace. We can see the trigger

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/27 22:15, Peter Zijlstra wrote: On Fri, Oct 27, 2017 at 02:33:48PM +0200, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: This is a real bug happened on one of our machines, below is the calltrace. We can see the trigger

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/27 20:33, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: This is a real bug happened on one of our machines, below is the calltrace. We can see the trigger is at alternatives_text_reserved+0x20/0x80, and encounter a deleted (poisoned) list_head

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/27 20:33, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 07:42:45PM +0800, zhouchengming wrote: This is a real bug happened on one of our machines, below is the calltrace. We can see the trigger is at alternatives_text_reserved+0x20/0x80, and encounter a deleted (poisoned) list_head

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/27 19:15, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 05:34:44PM +0800, Zhou Chengming wrote: Fixes: 2cfa197 "ftrace/alternatives: Introducing *_text_reserved functions" We use alternatives_text_reserved() to check if the address is in the fixed pieces of alternative reserved,

Re: [PATCH] kprobes, x86/alternatives: use text_mutex to protect smp_alt_modules

On 2017/10/27 19:15, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 05:34:44PM +0800, Zhou Chengming wrote: Fixes: 2cfa197 "ftrace/alternatives: Introducing *_text_reserved functions" We use alternatives_text_reserved() to check if the address is in the fixed pieces of alternative reserved,

Re: [PATCH] x86/alternatives: free smp_alt_modules when enable smp

On 2017/10/27 15:49, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 03:18:12PM +0800, Zhou Chengming wrote: In the current code, we don't free smp_alt_modules when enable smp, so have to wait module unload to call alternatives_smp_module_del() to free its smp_alt_module. This strategy has

Re: [PATCH] x86/alternatives: free smp_alt_modules when enable smp

On 2017/10/27 15:49, Borislav Petkov wrote: On Fri, Oct 27, 2017 at 03:18:12PM +0800, Zhou Chengming wrote: In the current code, we don't free smp_alt_modules when enable smp, so have to wait module unload to call alternatives_smp_module_del() to free its smp_alt_module. This strategy has

Re: [PATCH v2] kprobes: avoid the kprobe being re-registered

On 2017/10/27 13:57, Masami Hiramatsu wrote: On Fri, 27 Oct 2017 09:56:40 +0800 Zhou Chengming wrote: Changes from v1: - We should put the modifies of the kprobe after the re-reg check. - And then the address_safe check. - When check_kprobe_address_safe() return

Re: [PATCH v2] kprobes: avoid the kprobe being re-registered

On 2017/10/27 13:57, Masami Hiramatsu wrote: On Fri, 27 Oct 2017 09:56:40 +0800 Zhou Chengming wrote: Changes from v1: - We should put the modifies of the kprobe after the re-reg check. - And then the address_safe check. - When check_kprobe_address_safe() return fail, the *probed_mod

Re: [PATCH] kprobes: avoid the kprobe being re-registered

On 2017/10/26 22:39, Masami Hiramatsu wrote: On Thu, 26 Oct 2017 20:11:25 +0800 Zhou Chengming wrote: Old code use check_kprobe_rereg() to check if the kprobe has been registered already, but check_kprobe_rereg() will release the kprobe_mutex then, so maybe two

Re: [PATCH] kprobes: avoid the kprobe being re-registered

On 2017/10/26 22:39, Masami Hiramatsu wrote: On Thu, 26 Oct 2017 20:11:25 +0800 Zhou Chengming wrote: Old code use check_kprobe_rereg() to check if the kprobe has been registered already, but check_kprobe_rereg() will release the kprobe_mutex then, so maybe two paths will pass the check and

Re: [PATCH 2/4] perf/ftrace: Fix function trace events

On 2017/10/11 15:45, Peter Zijlstra wrote: The function-trace<-> perf interface is a tad messed up. Where all the other trace<-> perf interfaces use a single trace hook registration and use per-cpu RCU based hlist to iterate the events, function-trace actually needs multiple hook registrations

Re: [PATCH 2/4] perf/ftrace: Fix function trace events

On 2017/10/11 15:45, Peter Zijlstra wrote: The function-trace<-> perf interface is a tad messed up. Where all the other trace<-> perf interfaces use a single trace hook registration and use per-cpu RCU based hlist to iterate the events, function-trace actually needs multiple hook registrations

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

Hi Steven, Peter, On 2017/9/26 11:18, Steven Rostedt wrote: On Tue, 26 Sep 2017 09:23:20 +0800 zhouchengming<zhouchengmi...@huawei.com> wrote: On 2017/9/26 3:40, Steven Rostedt wrote: On Mon, 11 Sep 2017 14:51:49 +0800 Zhou Chengming<zhouchengmi...@huawei.com> wrote: push_rt

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

Hi Steven, Peter, On 2017/9/26 11:18, Steven Rostedt wrote: On Tue, 26 Sep 2017 09:23:20 +0800 zhouchengming wrote: On 2017/9/26 3:40, Steven Rostedt wrote: On Mon, 11 Sep 2017 14:51:49 +0800 Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

On 2017/9/26 3:40, Steven Rostedt wrote: On Mon, 11 Sep 2017 14:51:49 +0800 Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible lowest_rq, then double_lock_balance(rq, lowest_rq). So if double_lock_balance() unlock the rq (when

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

On 2017/9/26 3:40, Steven Rostedt wrote: On Mon, 11 Sep 2017 14:51:49 +0800 Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible lowest_rq, then double_lock_balance(rq, lowest_rq). So if double_lock_balance() unlock the rq (when double_lock_balance() return

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

ping... Or it isn't a real problem ? Thanks. On 2017/9/11 14:51, Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible lowest_rq, then double_lock_balance(rq, lowest_rq). So if double_lock_balance() unlock the rq (when double_lock_balance() return 1), we have

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

ping... Or it isn't a real problem ? Thanks. On 2017/9/11 14:51, Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible lowest_rq, then double_lock_balance(rq, lowest_rq). So if double_lock_balance() unlock the rq (when double_lock_balance() return 1), we have

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

polite ping and +cc, thanks! On 2017/9/11 14:51, Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible lowest_rq, then double_lock_balance(rq, lowest_rq). So if double_lock_balance() unlock the rq (when double_lock_balance() return 1), we have to check if this

Re: [PATCH] sched/rt.c: pick and check task if double_lock_balance() unlock the rq

polite ping and +cc, thanks! On 2017/9/11 14:51, Zhou Chengming wrote: push_rt_task() pick the first pushable task and find an eligible lowest_rq, then double_lock_balance(rq, lowest_rq). So if double_lock_balance() unlock the rq (when double_lock_balance() return 1), we have to check if this

Re: [PATCH] perf/core: fix group {cpu,task} validation

On 2017/6/22 22:41, Mark Rutland wrote: Regardless of which events form a group, it does not make sense for the events to target different tasks and/or CPUs, as this leaves the group inconsistent and impossible to schedule. The core perf code assumes that these are consistent across

Re: [PATCH] perf/core: fix group {cpu,task} validation

On 2017/6/22 22:41, Mark Rutland wrote: Regardless of which events form a group, it does not make sense for the events to target different tasks and/or CPUs, as this leaves the group inconsistent and impossible to schedule. The core perf code assumes that these are consistent across

Re: [PATCH] perf/core: make sure group events are for the same cpu

On 2017/6/20 21:08, Alexander Shishkin wrote: Zhou Chengming writes: The else branch are broken for taskctx: This is not a good way to open a commit message. two events can on the same taskctx, but on different cpu. How? fd1 = perf_open_event(attr, pid, 0, -1,

Re: [PATCH] perf/core: make sure group events are for the same cpu

On 2017/6/20 21:08, Alexander Shishkin wrote: Zhou Chengming writes: The else branch are broken for taskctx: This is not a good way to open a commit message. two events can on the same taskctx, but on different cpu. How? fd1 = perf_open_event(attr, pid, 0, -1, flags); fd2 =

Re: [PATCH] reduce the time of finding symbols for module

On 2017/3/28 19:16, Miroslav Benes wrote: On Tue, 28 Mar 2017, zhouchengming wrote: On 2017/3/28 17:00, Miroslav Benes wrote: Hi, On Tue, 28 Mar 2017, Zhou Chengming wrote: It's reported that the time of insmoding a klp.ko for one of our out-tree modules is too long. ~ time sudo insmod

Re: [PATCH] reduce the time of finding symbols for module

On 2017/3/28 19:16, Miroslav Benes wrote: On Tue, 28 Mar 2017, zhouchengming wrote: On 2017/3/28 17:00, Miroslav Benes wrote: Hi, On Tue, 28 Mar 2017, Zhou Chengming wrote: It's reported that the time of insmoding a klp.ko for one of our out-tree modules is too long. ~ time sudo insmod

Re: [PATCH] reduce the time of finding symbols for module

On 2017/3/28 17:00, Miroslav Benes wrote: Hi, On Tue, 28 Mar 2017, Zhou Chengming wrote: It's reported that the time of insmoding a klp.ko for one of our out-tree modules is too long. ~ time sudo insmod klp.ko real0m23.799s user0m0.036s sys 0m21.256s Is this stable through

Re: [PATCH] reduce the time of finding symbols for module

On 2017/3/28 17:00, Miroslav Benes wrote: Hi, On Tue, 28 Mar 2017, Zhou Chengming wrote: It's reported that the time of insmoding a klp.ko for one of our out-tree modules is too long. ~ time sudo insmod klp.ko real0m23.799s user0m0.036s sys 0m21.256s Is this stable through

Re: [PATCH v2] don't forget to call pd_online_fn when activate policy

On 2017/3/10 23:12, Jens Axboe wrote: On 03/08/2017 07:20 PM, Zhou Chengming wrote: When we activate policy on the request_queue, we will create policy_date for all the existing blkgs of the request_queue, so we should call pd_init_fn() and pd_online_fn() on these newly created policy_data.

Re: [PATCH v2] don't forget to call pd_online_fn when activate policy

On 2017/3/10 23:12, Jens Axboe wrote: On 03/08/2017 07:20 PM, Zhou Chengming wrote: When we activate policy on the request_queue, we will create policy_date for all the existing blkgs of the request_queue, so we should call pd_init_fn() and pd_online_fn() on these newly created policy_data.

Re: [PATCH] fix race caused by hyperthreads when online an offline cpu

On 2017/1/16 17:05, Thomas Gleixner wrote: On Mon, 16 Jan 2017, Zhou Chengming wrote: Can you please stop sending the same patch over and over every other day? Granted, things get forgotten, but sending a polite reminder after a week is definitely enough. Maintainers are not machines

Re: [PATCH] fix race caused by hyperthreads when online an offline cpu

On 2017/1/16 17:05, Thomas Gleixner wrote: On Mon, 16 Jan 2017, Zhou Chengming wrote: Can you please stop sending the same patch over and over every other day? Granted, things get forgotten, but sending a polite reminder after a week is definitely enough. Maintainers are not machines

Re: [PATCH] Drop reference added by grab_header

On 2017/1/5 19:56, Hanjun Guo wrote: On 2017/1/5 19:33, Zhou Chengming wrote: Fixes CVE-2016-9191. CVE-2016-9191 says that it's cgroup bug but turns out it's not, I think you need to add more commit message to explain it? For example, we got different calltrace stack but all of them point to

Re: [PATCH] Drop reference added by grab_header

On 2017/1/5 19:56, Hanjun Guo wrote: On 2017/1/5 19:33, Zhou Chengming wrote: Fixes CVE-2016-9191. CVE-2016-9191 says that it's cgroup bug but turns out it's not, I think you need to add more commit message to explain it? For example, we got different calltrace stack but all of them point to

Re: [PATCH 0/7] arm: Add livepatch support

On 2016/12/7 1:06, Abel Vesa wrote: This is just an idea I've been trying out for a while now. Just in case somebody wants to play with it, this applies to linux-arm/for-next. Also please note that this was only tested in qemu, but I will do some testing on some real hardware in the following

Re: [PATCH 0/7] arm: Add livepatch support

On 2016/12/7 1:06, Abel Vesa wrote: This is just an idea I've been trying out for a while now. Just in case somebody wants to play with it, this applies to linux-arm/for-next. Also please note that this was only tested in qemu, but I will do some testing on some real hardware in the following

Re: [PATCH] make __section_nr more efficient

On 2016/7/21 5:36, Dave Hansen wrote: On 07/19/2016 09:18 PM, Zhou Chengming wrote: When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Does this actually *do* anything? It was a long time ago, but if I remember correctly, the

Re: [PATCH] make __section_nr more efficient

On 2016/7/21 5:36, Dave Hansen wrote: On 07/19/2016 09:18 PM, Zhou Chengming wrote: When CONFIG_SPARSEMEM_EXTREME is disabled, __section_nr can get the section number with a subtraction directly. Does this actually *do* anything? It was a long time ago, but if I remember correctly, the

Re: [PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

, 2016 at 12:49:05PM +0800, zhouchengming wrote: atus: RO Content-Length: 4732 Lines: 181 The function compat_ptrace_request(used by ilp32) don't handle {GET,SET}SIGMASK request, so it will be handled by ptrace_request. But it's wrong because the compat_sigset_t of ilp32 differs from the sigset_t

Re: [PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

, 2016 at 12:49:05PM +0800, zhouchengming wrote: atus: RO Content-Length: 4732 Lines: 181 The function compat_ptrace_request(used by ilp32) don't handle {GET,SET}SIGMASK request, so it will be handled by ptrace_request. But it's wrong because the compat_sigset_t of ilp32 differs from the sigset_t

[PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

The function compat_ptrace_request(used by ilp32) don't handle {GET,SET}SIGMASK request, so it will be handled by ptrace_request. But it's wrong because the compat_sigset_t of ilp32 differs from the sigset_t of aarch64. The patch fixes it. Signed-off-by: Zhou Chengming

[PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace

The function compat_ptrace_request(used by ilp32) don't handle {GET,SET}SIGMASK request, so it will be handled by ptrace_request. But it's wrong because the compat_sigset_t of ilp32 differs from the sigset_t of aarch64. The patch fixes it. Signed-off-by: Zhou Chengming ---

Re: [PATCH 12/19] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

The {GET,SET}SIGMASK request of ptrace on ilp32 is wrong, it's handled by ptrace_request(like aarch64). So I write a patch to fix it(just for ilp32). I will send the patch next. Thanks! On 2016/6/18 7:54, Yury Norov wrote: Here new aarch32 ptrace syscall handler is introsuced to avoid run-time

Re: [PATCH 12/19] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

The {GET,SET}SIGMASK request of ptrace on ilp32 is wrong, it's handled by ptrace_request(like aarch64). So I write a patch to fix it(just for ilp32). I will send the patch next. Thanks! On 2016/6/18 7:54, Yury Norov wrote: Here new aarch32 ptrace syscall handler is introsuced to avoid run-time

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On 2016/6/25 22:15, Bamvor Zhang wrote: Hi, Chengming On Sat, Jun 25, 2016 at 5:36 PM, zhouchengming <zhouchengmi...@huawei.com> wrote: On 2016/6/9 1:00, Yury Norov wrote: On Wed, Jun 08, 2016 at 09:34:09AM +0800, zhouchengming wrote: On 2016/5/24 8:04, Yury Norov wrote: He

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On 2016/6/25 22:15, Bamvor Zhang wrote: Hi, Chengming On Sat, Jun 25, 2016 at 5:36 PM, zhouchengming wrote: On 2016/6/9 1:00, Yury Norov wrote: On Wed, Jun 08, 2016 at 09:34:09AM +0800, zhouchengming wrote: On 2016/5/24 8:04, Yury Norov wrote: Here new aarch32 ptrace syscall handler

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On 2016/6/9 1:00, Yury Norov wrote: On Wed, Jun 08, 2016 at 09:34:09AM +0800, zhouchengming wrote: On 2016/5/24 8:04, Yury Norov wrote: Here new aarch32 ptrace syscall handler is introsuced to avoid run-time detection of the task type. Signed-off-by: Yury Norov<yno...@caviumnetworks.

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On 2016/6/9 1:00, Yury Norov wrote: On Wed, Jun 08, 2016 at 09:34:09AM +0800, zhouchengming wrote: On 2016/5/24 8:04, Yury Norov wrote: Here new aarch32 ptrace syscall handler is introsuced to avoid run-time detection of the task type. Signed-off-by: Yury Norov [...] Hello, I found ilp32

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On 2016/5/24 8:04, Yury Norov wrote: Here new aarch32 ptrace syscall handler is introsuced to avoid run-time detection of the task type. Signed-off-by: Yury Norov --- arch/arm64/include/asm/unistd32.h | 2 +- arch/arm64/kernel/ptrace.c| 50

Re: [PATCH 17/23] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

On 2016/5/24 8:04, Yury Norov wrote: Here new aarch32 ptrace syscall handler is introsuced to avoid run-time detection of the task type. Signed-off-by: Yury Norov --- arch/arm64/include/asm/unistd32.h | 2 +- arch/arm64/kernel/ptrace.c| 50 ++-

Re: [PATCH v3] ksm: fix conflict between mmput and scan_get_next_rmap_item

Please ignore this patch v3. I forgot to change the function unmerge_and_remove_all_rmap_items(). Patch v4 will be the final version, I think.. Sorry for my carelessness. Thanks! On 2016/5/8 14:56, Zhou Chengming wrote: A concurrency issue about KSM in the function scan_get_next_rmap_item.

Re: [PATCH v3] ksm: fix conflict between mmput and scan_get_next_rmap_item

Please ignore this patch v3. I forgot to change the function unmerge_and_remove_all_rmap_items(). Patch v4 will be the final version, I think.. Sorry for my carelessness. Thanks! On 2016/5/8 14:56, Zhou Chengming wrote: A concurrency issue about KSM in the function scan_get_next_rmap_item.

Re: [PATCH] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/7 12:04, Hugh Dickins wrote: On Fri, 6 May 2016, zhouchengming wrote: On 2016/5/6 5:07, Andrew Morton wrote: On Thu, 5 May 2016 20:42:56 +0800 Zhou Chengming<zhouchengmi...@huawei.com> wrote: A concurrency issue about KSM in the function scan_get_next_rmap_item. task A

Re: [PATCH] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/7 12:04, Hugh Dickins wrote: On Fri, 6 May 2016, zhouchengming wrote: On 2016/5/6 5:07, Andrew Morton wrote: On Thu, 5 May 2016 20:42:56 +0800 Zhou Chengming wrote: A concurrency issue about KSM in the function scan_get_next_rmap_item. task A (ksmd): |task

Re: [PATCH v2] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/6 22:24, Andrea Arcangeli wrote: On Fri, May 06, 2016 at 11:27:36AM +0800, Zhou Chengming wrote: @@ -1650,16 +1647,22 @@ next_mm: */ hash_del(>link); list_del(>mm_list); - spin_unlock(_mmlist_lock);

Re: [PATCH v2] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/6 22:24, Andrea Arcangeli wrote: On Fri, May 06, 2016 at 11:27:36AM +0800, Zhou Chengming wrote: @@ -1650,16 +1647,22 @@ next_mm: */ hash_del(>link); list_del(>mm_list); - spin_unlock(_mmlist_lock);

Re: [PATCH] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/6 5:57, Andrea Arcangeli wrote: Hello Zhou, Great catch. On Thu, May 05, 2016 at 08:42:56PM +0800, Zhou Chengming wrote: remove_trailing_rmap_items(slot, ksm_scan.rmap_list); + up_read(>mmap_sem); spin_lock(_mmlist_lock); ksm_scan.mm_slot =

Re: [PATCH] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/6 5:57, Andrea Arcangeli wrote: Hello Zhou, Great catch. On Thu, May 05, 2016 at 08:42:56PM +0800, Zhou Chengming wrote: remove_trailing_rmap_items(slot, ksm_scan.rmap_list); + up_read(>mmap_sem); spin_lock(_mmlist_lock); ksm_scan.mm_slot =

Re: [PATCH] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/6 5:07, Andrew Morton wrote: On Thu, 5 May 2016 20:42:56 +0800 Zhou Chengming wrote: A concurrency issue about KSM in the function scan_get_next_rmap_item. task A (ksmd): |task B (the mm's task):

Re: [PATCH] ksm: fix conflict between mmput and scan_get_next_rmap_item

On 2016/5/6 5:07, Andrew Morton wrote: On Thu, 5 May 2016 20:42:56 +0800 Zhou Chengming wrote: A concurrency issue about KSM in the function scan_get_next_rmap_item. task A (ksmd): |task B (the mm's task): | mm = slot->mm;

Re: [PATCH] livepatch: x86: bugfix about kASLR

On 2015/11/4 17:44, Jiri Kosina wrote: On Wed, 4 Nov 2015, Zhou Chengming wrote: When enable KASLR, func->old_addr will be set to zero and livepatch will find the right old address. But for reloc, livepatch just verify it using reloc->val (old addr from user), so verify failed and report

Re: [PATCH] livepatch: x86: bugfix about kASLR

On 2015/11/4 17:44, Jiri Kosina wrote: On Wed, 4 Nov 2015, Zhou Chengming wrote: When enable KASLR, func->old_addr will be set to zero and livepatch will find the right old address. But for reloc, livepatch just verify it using reloc->val (old addr from user), so verify failed and report