* [PATCH] sched: numa: ksm: fix oops in task_numa_placment()
@ 2012-12-20 1:42 ` Hugh Dickins
0 siblings, 0 replies; 22+ messages in thread
From: Hugh Dickins @ 2012-12-20 1:42 UTC (permalink / raw)
To: Mel Gorman
Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin,
Petr Holasek, linux-kernel, linux-mm
task_numa_placement() oopsed on NULL p->mm when task_numa_fault()
got called in the handling of break_ksm() for ksmd. That might be a
peculiar case, which perhaps KSM could takes steps to avoid? but it's
more robust if task_numa_placement() allows for such a possibility.
Signed-off-by: Hugh Dickins <hughd@google.com>
---
kernel/sched/fair.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- 3.7+git/kernel/sched/fair.c 2012-12-16 16:35:08.724441527 -0800
+++ linux/kernel/sched/fair.c 2012-12-18 21:37:24.727964195 -0800
@@ -793,8 +793,11 @@ unsigned int sysctl_numa_balancing_scan_
static void task_numa_placement(struct task_struct *p)
{
- int seq = ACCESS_ONCE(p->mm->numa_scan_seq);
+ int seq;
+ if (!p->mm) /* for example, ksmd faulting in a user's mm */
+ return;
+ seq = ACCESS_ONCE(p->mm->numa_scan_seq);
if (p->numa_scan_seq == seq)
return;
p->numa_scan_seq = seq;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH] sched: numa: ksm: fix oops in task_numa_placment() @ 2012-12-20 1:42 ` Hugh Dickins 0 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 1:42 UTC (permalink / raw) To: Mel Gorman Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm task_numa_placement() oopsed on NULL p->mm when task_numa_fault() got called in the handling of break_ksm() for ksmd. That might be a peculiar case, which perhaps KSM could takes steps to avoid? but it's more robust if task_numa_placement() allows for such a possibility. Signed-off-by: Hugh Dickins <hughd@google.com> --- kernel/sched/fair.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- 3.7+git/kernel/sched/fair.c 2012-12-16 16:35:08.724441527 -0800 +++ linux/kernel/sched/fair.c 2012-12-18 21:37:24.727964195 -0800 @@ -793,8 +793,11 @@ unsigned int sysctl_numa_balancing_scan_ static void task_numa_placement(struct task_struct *p) { - int seq = ACCESS_ONCE(p->mm->numa_scan_seq); + int seq; + if (!p->mm) /* for example, ksmd faulting in a user's mm */ + return; + seq = ACCESS_ONCE(p->mm->numa_scan_seq); if (p->numa_scan_seq == seq) return; p->numa_scan_seq = seq; ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] ksm: make rmap walks more scalable 2012-12-20 1:42 ` Hugh Dickins @ 2012-12-20 1:44 ` Hugh Dickins -1 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 1:44 UTC (permalink / raw) To: Mel Gorman Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm The rmap walks in ksm.c are like those in rmap.c: they can safely be done with anon_vma_lock_read(). Signed-off-by: Hugh Dickins <hughd@google.com> --- mm/ksm.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- 3.7+git/mm/ksm.c 2012-12-16 16:35:08.752441527 -0800 +++ linux/mm/ksm.c 2012-12-19 16:58:05.292145790 -0800 @@ -1624,7 +1624,7 @@ again: struct anon_vma_chain *vmac; struct vm_area_struct *vma; - anon_vma_lock_write(anon_vma); + anon_vma_lock_read(anon_vma); anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, 0, ULONG_MAX) { vma = vmac->vma; @@ -1648,7 +1648,7 @@ again: if (!search_new_forks || !mapcount) break; } - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); if (!mapcount) goto out; } @@ -1678,7 +1678,7 @@ again: struct anon_vma_chain *vmac; struct vm_area_struct *vma; - anon_vma_lock_write(anon_vma); + anon_vma_lock_read(anon_vma); anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, 0, ULONG_MAX) { vma = vmac->vma; @@ -1697,11 +1697,11 @@ again: ret = try_to_unmap_one(page, vma, rmap_item->address, flags); if (ret != SWAP_AGAIN || !page_mapped(page)) { - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); goto out; } } - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); } if (!search_new_forks++) goto again; @@ -1731,7 +1731,7 @@ again: struct anon_vma_chain *vmac; struct vm_area_struct *vma; - anon_vma_lock_write(anon_vma); + anon_vma_lock_read(anon_vma); anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, 0, ULONG_MAX) { vma = vmac->vma; @@ -1749,11 +1749,11 @@ again: ret = rmap_one(page, vma, rmap_item->address, arg); if (ret != SWAP_AGAIN) { - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); goto out; } } - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); } if (!search_new_forks++) goto again; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 1:44 ` Hugh Dickins 0 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 1:44 UTC (permalink / raw) To: Mel Gorman Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm The rmap walks in ksm.c are like those in rmap.c: they can safely be done with anon_vma_lock_read(). Signed-off-by: Hugh Dickins <hughd@google.com> --- mm/ksm.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- 3.7+git/mm/ksm.c 2012-12-16 16:35:08.752441527 -0800 +++ linux/mm/ksm.c 2012-12-19 16:58:05.292145790 -0800 @@ -1624,7 +1624,7 @@ again: struct anon_vma_chain *vmac; struct vm_area_struct *vma; - anon_vma_lock_write(anon_vma); + anon_vma_lock_read(anon_vma); anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, 0, ULONG_MAX) { vma = vmac->vma; @@ -1648,7 +1648,7 @@ again: if (!search_new_forks || !mapcount) break; } - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); if (!mapcount) goto out; } @@ -1678,7 +1678,7 @@ again: struct anon_vma_chain *vmac; struct vm_area_struct *vma; - anon_vma_lock_write(anon_vma); + anon_vma_lock_read(anon_vma); anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, 0, ULONG_MAX) { vma = vmac->vma; @@ -1697,11 +1697,11 @@ again: ret = try_to_unmap_one(page, vma, rmap_item->address, flags); if (ret != SWAP_AGAIN || !page_mapped(page)) { - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); goto out; } } - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); } if (!search_new_forks++) goto again; @@ -1731,7 +1731,7 @@ again: struct anon_vma_chain *vmac; struct vm_area_struct *vma; - anon_vma_lock_write(anon_vma); + anon_vma_lock_read(anon_vma); anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root, 0, ULONG_MAX) { vma = vmac->vma; @@ -1749,11 +1749,11 @@ again: ret = rmap_one(page, vma, rmap_item->address, arg); if (ret != SWAP_AGAIN) { - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); goto out; } } - anon_vma_unlock(anon_vma); + anon_vma_unlock_read(anon_vma); } if (!search_new_forks++) goto again; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 1:44 ` Hugh Dickins @ 2012-12-20 11:17 ` Mel Gorman -1 siblings, 0 replies; 22+ messages in thread From: Mel Gorman @ 2012-12-20 11:17 UTC (permalink / raw) To: Hugh Dickins Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm On Wed, Dec 19, 2012 at 05:44:29PM -0800, Hugh Dickins wrote: > The rmap walks in ksm.c are like those in rmap.c: > they can safely be done with anon_vma_lock_read(). > > Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Mel Gorman <mgorman@suse.de> I'm assuming these are going to go through Andrew's tree as normal for -mm patches. Andrew? -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 11:17 ` Mel Gorman 0 siblings, 0 replies; 22+ messages in thread From: Mel Gorman @ 2012-12-20 11:17 UTC (permalink / raw) To: Hugh Dickins Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm On Wed, Dec 19, 2012 at 05:44:29PM -0800, Hugh Dickins wrote: > The rmap walks in ksm.c are like those in rmap.c: > they can safely be done with anon_vma_lock_read(). > > Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Mel Gorman <mgorman@suse.de> I'm assuming these are going to go through Andrew's tree as normal for -mm patches. Andrew? -- Mel Gorman SUSE Labs ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 1:44 ` Hugh Dickins @ 2012-12-20 21:49 ` Sasha Levin -1 siblings, 0 replies; 22+ messages in thread From: Sasha Levin @ 2012-12-20 21:49 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, Petr Holasek, linux-kernel, linux-mm On 12/19/2012 08:44 PM, Hugh Dickins wrote: > The rmap walks in ksm.c are like those in rmap.c: > they can safely be done with anon_vma_lock_read(). > > Signed-off-by: Hugh Dickins <hughd@google.com> > --- Hi Hugh, This patch didn't fix the ksm oopses I'm seeing. This is with both patches applied: [ 191.221082] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 [ 191.226749] IP: [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 [ 191.228437] PGD 1469f067 PUD 1466a067 PMD 0 [ 191.229185] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 191.230031] Dumping ftrace buffer: [ 191.230031] (ftrace buffer empty) [ 191.230031] CPU 3 [ 191.230031] Pid: 3174, comm: ksmd Tainted: G W 3.7.0-next-20121220-sasha-00015-g5dc79b2-dirty #223 [ 191.230031] RIP: 0010:[<ffffffff81185bf0>] [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 [ 191.230031] RSP: 0018:ffff8800be933b78 EFLAGS: 00010046 [ 191.230031] RAX: 0000000000000086 RBX: 0000000000000110 RCX: 0000000000000001 [ 191.230031] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000110 [ 191.230031] RBP: ffff8800be933c18 R08: 0000000000000002 R09: 0000000000000000 [ 191.230031] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 [ 191.230031] R13: 0000000000000002 R14: ffff8800be940000 R15: 0000000000000000 [ 191.230031] FS: 0000000000000000(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 [ 191.230031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 191.230031] CR2: 0000000000000110 CR3: 000000001469e000 CR4: 00000000000406e0 [ 191.230031] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 191.230031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 191.230031] Process ksmd (pid: 3174, threadinfo ffff8800be932000, task ffff8800be940000) [ 191.230031] Stack: [ 191.230031] ffff8800be933fd8 0000000000000000 ffff8800be933bb8 ffffffff810a4ec8 [ 191.230031] ffff8800be933bc8 ffffffff811572a8 ffff88000fdd78c0 ffff88000fdd78d0 [ 191.230031] ffff8800be933bc8 ffffffff81077ce5 ffff8800be933bf8 ffffffff81157075 [ 191.230031] Call Trace: [ 191.230031] [<ffffffff810a4ec8>] ? kvm_clock_read+0x38/0x70 [ 191.230031] [<ffffffff811572a8>] ? sched_clock_cpu+0x108/0x120 [ 191.230031] [<ffffffff81077ce5>] ? sched_clock+0x15/0x20 [ 191.230031] [<ffffffff81157075>] ? sched_clock_local+0x25/0x90 [ 191.230031] [<ffffffff81188a3a>] lock_acquire+0x1ca/0x270 [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 [ 191.230031] [<ffffffff83cd7f27>] down_read+0x47/0x90 [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 [ 191.230031] [<ffffffff812599cf>] unstable_tree_search_insert+0x9f/0x260 [ 191.230031] [<ffffffff8125afc7>] cmp_and_merge_page+0xe7/0x1e0 [ 191.230031] [<ffffffff8125b125>] ksm_do_scan+0x65/0xa0 [ 191.230031] [<ffffffff8125b1cf>] ksm_scan_thread+0x6f/0x2d0 [ 191.230031] [<ffffffff8113deb0>] ? abort_exclusive_wait+0xb0/0xb0 [ 191.230031] [<ffffffff8125b160>] ? ksm_do_scan+0xa0/0xa0 [ 191.230031] [<ffffffff8113cc43>] kthread+0xe3/0xf0 [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 [ 191.230031] [<ffffffff83cdba7c>] ret_from_fork+0x7c/0xb0 [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 [ 191.230031] Code: 00 83 3d 33 2b b0 05 00 0f 85 d5 09 00 00 be f9 0b 00 00 48 c7 c7 24 d1 b2 84 89 55 88 e8 09 80 f8 ff 8b 55 88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 83 fc 01 77 [ 191.230031] RIP [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 [ 191.230031] RSP <ffff8800be933b78> [ 191.230031] CR2: 0000000000000110 [ 191.230031] ---[ end trace 55f664bfe0f01693 ]--- Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 21:49 ` Sasha Levin 0 siblings, 0 replies; 22+ messages in thread From: Sasha Levin @ 2012-12-20 21:49 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, Petr Holasek, linux-kernel, linux-mm On 12/19/2012 08:44 PM, Hugh Dickins wrote: > The rmap walks in ksm.c are like those in rmap.c: > they can safely be done with anon_vma_lock_read(). > > Signed-off-by: Hugh Dickins <hughd@google.com> > --- Hi Hugh, This patch didn't fix the ksm oopses I'm seeing. This is with both patches applied: [ 191.221082] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 [ 191.226749] IP: [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 [ 191.228437] PGD 1469f067 PUD 1466a067 PMD 0 [ 191.229185] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 191.230031] Dumping ftrace buffer: [ 191.230031] (ftrace buffer empty) [ 191.230031] CPU 3 [ 191.230031] Pid: 3174, comm: ksmd Tainted: G W 3.7.0-next-20121220-sasha-00015-g5dc79b2-dirty #223 [ 191.230031] RIP: 0010:[<ffffffff81185bf0>] [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 [ 191.230031] RSP: 0018:ffff8800be933b78 EFLAGS: 00010046 [ 191.230031] RAX: 0000000000000086 RBX: 0000000000000110 RCX: 0000000000000001 [ 191.230031] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000110 [ 191.230031] RBP: ffff8800be933c18 R08: 0000000000000002 R09: 0000000000000000 [ 191.230031] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 [ 191.230031] R13: 0000000000000002 R14: ffff8800be940000 R15: 0000000000000000 [ 191.230031] FS: 0000000000000000(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 [ 191.230031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 191.230031] CR2: 0000000000000110 CR3: 000000001469e000 CR4: 00000000000406e0 [ 191.230031] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 191.230031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 191.230031] Process ksmd (pid: 3174, threadinfo ffff8800be932000, task ffff8800be940000) [ 191.230031] Stack: [ 191.230031] ffff8800be933fd8 0000000000000000 ffff8800be933bb8 ffffffff810a4ec8 [ 191.230031] ffff8800be933bc8 ffffffff811572a8 ffff88000fdd78c0 ffff88000fdd78d0 [ 191.230031] ffff8800be933bc8 ffffffff81077ce5 ffff8800be933bf8 ffffffff81157075 [ 191.230031] Call Trace: [ 191.230031] [<ffffffff810a4ec8>] ? kvm_clock_read+0x38/0x70 [ 191.230031] [<ffffffff811572a8>] ? sched_clock_cpu+0x108/0x120 [ 191.230031] [<ffffffff81077ce5>] ? sched_clock+0x15/0x20 [ 191.230031] [<ffffffff81157075>] ? sched_clock_local+0x25/0x90 [ 191.230031] [<ffffffff81188a3a>] lock_acquire+0x1ca/0x270 [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 [ 191.230031] [<ffffffff83cd7f27>] down_read+0x47/0x90 [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 [ 191.230031] [<ffffffff812599cf>] unstable_tree_search_insert+0x9f/0x260 [ 191.230031] [<ffffffff8125afc7>] cmp_and_merge_page+0xe7/0x1e0 [ 191.230031] [<ffffffff8125b125>] ksm_do_scan+0x65/0xa0 [ 191.230031] [<ffffffff8125b1cf>] ksm_scan_thread+0x6f/0x2d0 [ 191.230031] [<ffffffff8113deb0>] ? abort_exclusive_wait+0xb0/0xb0 [ 191.230031] [<ffffffff8125b160>] ? ksm_do_scan+0xa0/0xa0 [ 191.230031] [<ffffffff8113cc43>] kthread+0xe3/0xf0 [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 [ 191.230031] [<ffffffff83cdba7c>] ret_from_fork+0x7c/0xb0 [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 [ 191.230031] Code: 00 83 3d 33 2b b0 05 00 0f 85 d5 09 00 00 be f9 0b 00 00 48 c7 c7 24 d1 b2 84 89 55 88 e8 09 80 f8 ff 8b 55 88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 83 fc 01 77 [ 191.230031] RIP [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 [ 191.230031] RSP <ffff8800be933b78> [ 191.230031] CR2: 0000000000000110 [ 191.230031] ---[ end trace 55f664bfe0f01693 ]--- Thanks, Sasha ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 21:49 ` Sasha Levin @ 2012-12-20 22:26 ` Linus Torvalds -1 siblings, 0 replies; 22+ messages in thread From: Linus Torvalds @ 2012-12-20 22:26 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, Andrew Morton, Ingo Molnar, Petr Holasek, Linux Kernel Mailing List, linux-mm On Thu, Dec 20, 2012 at 1:49 PM, Sasha Levin <sasha.levin@oracle.com> wrote: > On 12/19/2012 08:44 PM, Hugh Dickins wrote: >> The rmap walks in ksm.c are like those in rmap.c: >> they can safely be done with anon_vma_lock_read(). >> >> Signed-off-by: Hugh Dickins <hughd@google.com> >> --- > > Hi Hugh, > > This patch didn't fix the ksm oopses I'm seeing. > > This is with both patches applied: Looks like another NULL mm pointer in ksmd.. Hugh fixed one in 2832bc19f666 ("sched: numa: ksm: fix oops in task_numa_placment()"), this looks like more of the same. At a guess, it looks like get_mergeable_page() has a rmap_item with no mm. No idea how that happened. Hugh? Some race due to something that depended on the mmap_sem being exclusive, rather than for read-ownership? Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 22:26 ` Linus Torvalds 0 siblings, 0 replies; 22+ messages in thread From: Linus Torvalds @ 2012-12-20 22:26 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, Andrew Morton, Ingo Molnar, Petr Holasek, Linux Kernel Mailing List, linux-mm On Thu, Dec 20, 2012 at 1:49 PM, Sasha Levin <sasha.levin@oracle.com> wrote: > On 12/19/2012 08:44 PM, Hugh Dickins wrote: >> The rmap walks in ksm.c are like those in rmap.c: >> they can safely be done with anon_vma_lock_read(). >> >> Signed-off-by: Hugh Dickins <hughd@google.com> >> --- > > Hi Hugh, > > This patch didn't fix the ksm oopses I'm seeing. > > This is with both patches applied: Looks like another NULL mm pointer in ksmd.. Hugh fixed one in 2832bc19f666 ("sched: numa: ksm: fix oops in task_numa_placment()"), this looks like more of the same. At a guess, it looks like get_mergeable_page() has a rmap_item with no mm. No idea how that happened. Hugh? Some race due to something that depended on the mmap_sem being exclusive, rather than for read-ownership? Linus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 22:26 ` Linus Torvalds @ 2012-12-20 22:40 ` Hugh Dickins -1 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 22:40 UTC (permalink / raw) To: Linus Torvalds Cc: Sasha Levin, Mel Gorman, Andrew Morton, Ingo Molnar, Petr Holasek, Linux Kernel Mailing List, linux-mm On Thu, 20 Dec 2012, Linus Torvalds wrote: > On Thu, Dec 20, 2012 at 1:49 PM, Sasha Levin <sasha.levin@oracle.com> wrote: > > On 12/19/2012 08:44 PM, Hugh Dickins wrote: > >> The rmap walks in ksm.c are like those in rmap.c: > >> they can safely be done with anon_vma_lock_read(). > >> > >> Signed-off-by: Hugh Dickins <hughd@google.com> > >> --- > > > > Hi Hugh, > > > > This patch didn't fix the ksm oopses I'm seeing. > > > > This is with both patches applied: > > Looks like another NULL mm pointer in ksmd.. Hugh fixed one in > 2832bc19f666 ("sched: numa: ksm: fix oops in task_numa_placment()"), > this looks like more of the same. > > At a guess, it looks like get_mergeable_page() has a rmap_item with no > mm. No idea how that happened. Hugh? Some race due to something that > depended on the mmap_sem being exclusive, rather than for > read-ownership? No, it's just a misunderstanding: Sasha's problem is with a linux-next that has Petr's NUMA KSM patch in, and we're still ironing known issues out of that one. Not a problem for 3.8-rc1. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 22:40 ` Hugh Dickins 0 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 22:40 UTC (permalink / raw) To: Linus Torvalds Cc: Sasha Levin, Mel Gorman, Andrew Morton, Ingo Molnar, Petr Holasek, Linux Kernel Mailing List, linux-mm On Thu, 20 Dec 2012, Linus Torvalds wrote: > On Thu, Dec 20, 2012 at 1:49 PM, Sasha Levin <sasha.levin@oracle.com> wrote: > > On 12/19/2012 08:44 PM, Hugh Dickins wrote: > >> The rmap walks in ksm.c are like those in rmap.c: > >> they can safely be done with anon_vma_lock_read(). > >> > >> Signed-off-by: Hugh Dickins <hughd@google.com> > >> --- > > > > Hi Hugh, > > > > This patch didn't fix the ksm oopses I'm seeing. > > > > This is with both patches applied: > > Looks like another NULL mm pointer in ksmd.. Hugh fixed one in > 2832bc19f666 ("sched: numa: ksm: fix oops in task_numa_placment()"), > this looks like more of the same. > > At a guess, it looks like get_mergeable_page() has a rmap_item with no > mm. No idea how that happened. Hugh? Some race due to something that > depended on the mmap_sem being exclusive, rather than for > read-ownership? No, it's just a misunderstanding: Sasha's problem is with a linux-next that has Petr's NUMA KSM patch in, and we're still ironing known issues out of that one. Not a problem for 3.8-rc1. Hugh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 21:49 ` Sasha Levin @ 2012-12-20 22:37 ` Hugh Dickins -1 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 22:37 UTC (permalink / raw) To: Sasha Levin Cc: Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, Petr Holasek, linux-kernel, linux-mm On Thu, 20 Dec 2012, Sasha Levin wrote: > On 12/19/2012 08:44 PM, Hugh Dickins wrote: > > The rmap walks in ksm.c are like those in rmap.c: > > they can safely be done with anon_vma_lock_read(). > > > > Signed-off-by: Hugh Dickins <hughd@google.com> > > --- > > Hi Hugh, > > This patch didn't fix the ksm oopses I'm seeing. I wouldn't expect it to (and should certainly have mentioned oopses in the commit message if I'd intended): this patch was merely an optimization/clarification of a commit gone in for 3.8-rc1. Understandable misunderstanding: you took my Cc too seriously, I just thought I'd better keep Petr in the loop on current changes to ksm.c, and foolishly kept you in too ;) Your oopses are on linux-next, which as of 20121220 still had Petr's nice but buggy NUMA KSM patch in: it should go away when Stephen gets a fresh mm update from Andrew, then reappear once his v6 goes into mm. To stop these oopses in get_mergeable_page (inlined in unstable_tree_search_insert) you need the patch I showed on Tuesday, which I hope he'll merge in for his v6. That doesn't fix all of the problems, but hopefully all that you'll encounter before I've devised a fix for the separate stale stable_nodes issue. Hugh > > This is with both patches applied: > > > [ 191.221082] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 > [ 191.226749] IP: [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 > [ 191.228437] PGD 1469f067 PUD 1466a067 PMD 0 > [ 191.229185] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 191.230031] Dumping ftrace buffer: > [ 191.230031] (ftrace buffer empty) > [ 191.230031] CPU 3 > [ 191.230031] Pid: 3174, comm: ksmd Tainted: G W 3.7.0-next-20121220-sasha-00015-g5dc79b2-dirty #223 > [ 191.230031] RIP: 0010:[<ffffffff81185bf0>] [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 > [ 191.230031] RSP: 0018:ffff8800be933b78 EFLAGS: 00010046 > [ 191.230031] RAX: 0000000000000086 RBX: 0000000000000110 RCX: 0000000000000001 > [ 191.230031] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000110 > [ 191.230031] RBP: ffff8800be933c18 R08: 0000000000000002 R09: 0000000000000000 > [ 191.230031] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 > [ 191.230031] R13: 0000000000000002 R14: ffff8800be940000 R15: 0000000000000000 > [ 191.230031] FS: 0000000000000000(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 > [ 191.230031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 191.230031] CR2: 0000000000000110 CR3: 000000001469e000 CR4: 00000000000406e0 > [ 191.230031] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 191.230031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 191.230031] Process ksmd (pid: 3174, threadinfo ffff8800be932000, task ffff8800be940000) > [ 191.230031] Stack: > [ 191.230031] ffff8800be933fd8 0000000000000000 ffff8800be933bb8 ffffffff810a4ec8 > [ 191.230031] ffff8800be933bc8 ffffffff811572a8 ffff88000fdd78c0 ffff88000fdd78d0 > [ 191.230031] ffff8800be933bc8 ffffffff81077ce5 ffff8800be933bf8 ffffffff81157075 > [ 191.230031] Call Trace: > [ 191.230031] [<ffffffff810a4ec8>] ? kvm_clock_read+0x38/0x70 > [ 191.230031] [<ffffffff811572a8>] ? sched_clock_cpu+0x108/0x120 > [ 191.230031] [<ffffffff81077ce5>] ? sched_clock+0x15/0x20 > [ 191.230031] [<ffffffff81157075>] ? sched_clock_local+0x25/0x90 > [ 191.230031] [<ffffffff81188a3a>] lock_acquire+0x1ca/0x270 > [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 > [ 191.230031] [<ffffffff83cd7f27>] down_read+0x47/0x90 > [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 > [ 191.230031] [<ffffffff812599cf>] unstable_tree_search_insert+0x9f/0x260 > [ 191.230031] [<ffffffff8125afc7>] cmp_and_merge_page+0xe7/0x1e0 > [ 191.230031] [<ffffffff8125b125>] ksm_do_scan+0x65/0xa0 > [ 191.230031] [<ffffffff8125b1cf>] ksm_scan_thread+0x6f/0x2d0 > [ 191.230031] [<ffffffff8113deb0>] ? abort_exclusive_wait+0xb0/0xb0 > [ 191.230031] [<ffffffff8125b160>] ? ksm_do_scan+0xa0/0xa0 > [ 191.230031] [<ffffffff8113cc43>] kthread+0xe3/0xf0 > [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 > [ 191.230031] [<ffffffff83cdba7c>] ret_from_fork+0x7c/0xb0 > [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 > [ 191.230031] Code: 00 83 3d 33 2b b0 05 00 0f 85 d5 09 00 00 be f9 0b 00 00 48 c7 c7 24 d1 b2 84 89 55 88 e8 09 80 f8 ff 8b 55 > 88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 83 fc 01 77 > [ 191.230031] RIP [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 > [ 191.230031] RSP <ffff8800be933b78> > [ 191.230031] CR2: 0000000000000110 > [ 191.230031] ---[ end trace 55f664bfe0f01693 ]--- > > > Thanks, > Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 22:37 ` Hugh Dickins 0 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-20 22:37 UTC (permalink / raw) To: Sasha Levin Cc: Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, Petr Holasek, linux-kernel, linux-mm On Thu, 20 Dec 2012, Sasha Levin wrote: > On 12/19/2012 08:44 PM, Hugh Dickins wrote: > > The rmap walks in ksm.c are like those in rmap.c: > > they can safely be done with anon_vma_lock_read(). > > > > Signed-off-by: Hugh Dickins <hughd@google.com> > > --- > > Hi Hugh, > > This patch didn't fix the ksm oopses I'm seeing. I wouldn't expect it to (and should certainly have mentioned oopses in the commit message if I'd intended): this patch was merely an optimization/clarification of a commit gone in for 3.8-rc1. Understandable misunderstanding: you took my Cc too seriously, I just thought I'd better keep Petr in the loop on current changes to ksm.c, and foolishly kept you in too ;) Your oopses are on linux-next, which as of 20121220 still had Petr's nice but buggy NUMA KSM patch in: it should go away when Stephen gets a fresh mm update from Andrew, then reappear once his v6 goes into mm. To stop these oopses in get_mergeable_page (inlined in unstable_tree_search_insert) you need the patch I showed on Tuesday, which I hope he'll merge in for his v6. That doesn't fix all of the problems, but hopefully all that you'll encounter before I've devised a fix for the separate stale stable_nodes issue. Hugh > > This is with both patches applied: > > > [ 191.221082] BUG: unable to handle kernel NULL pointer dereference at 0000000000000110 > [ 191.226749] IP: [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 > [ 191.228437] PGD 1469f067 PUD 1466a067 PMD 0 > [ 191.229185] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 191.230031] Dumping ftrace buffer: > [ 191.230031] (ftrace buffer empty) > [ 191.230031] CPU 3 > [ 191.230031] Pid: 3174, comm: ksmd Tainted: G W 3.7.0-next-20121220-sasha-00015-g5dc79b2-dirty #223 > [ 191.230031] RIP: 0010:[<ffffffff81185bf0>] [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 > [ 191.230031] RSP: 0018:ffff8800be933b78 EFLAGS: 00010046 > [ 191.230031] RAX: 0000000000000086 RBX: 0000000000000110 RCX: 0000000000000001 > [ 191.230031] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000110 > [ 191.230031] RBP: ffff8800be933c18 R08: 0000000000000002 R09: 0000000000000000 > [ 191.230031] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 > [ 191.230031] R13: 0000000000000002 R14: ffff8800be940000 R15: 0000000000000000 > [ 191.230031] FS: 0000000000000000(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 > [ 191.230031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 191.230031] CR2: 0000000000000110 CR3: 000000001469e000 CR4: 00000000000406e0 > [ 191.230031] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 191.230031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 191.230031] Process ksmd (pid: 3174, threadinfo ffff8800be932000, task ffff8800be940000) > [ 191.230031] Stack: > [ 191.230031] ffff8800be933fd8 0000000000000000 ffff8800be933bb8 ffffffff810a4ec8 > [ 191.230031] ffff8800be933bc8 ffffffff811572a8 ffff88000fdd78c0 ffff88000fdd78d0 > [ 191.230031] ffff8800be933bc8 ffffffff81077ce5 ffff8800be933bf8 ffffffff81157075 > [ 191.230031] Call Trace: > [ 191.230031] [<ffffffff810a4ec8>] ? kvm_clock_read+0x38/0x70 > [ 191.230031] [<ffffffff811572a8>] ? sched_clock_cpu+0x108/0x120 > [ 191.230031] [<ffffffff81077ce5>] ? sched_clock+0x15/0x20 > [ 191.230031] [<ffffffff81157075>] ? sched_clock_local+0x25/0x90 > [ 191.230031] [<ffffffff81188a3a>] lock_acquire+0x1ca/0x270 > [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 > [ 191.230031] [<ffffffff83cd7f27>] down_read+0x47/0x90 > [ 191.230031] [<ffffffff812599cf>] ? unstable_tree_search_insert+0x9f/0x260 > [ 191.230031] [<ffffffff812599cf>] unstable_tree_search_insert+0x9f/0x260 > [ 191.230031] [<ffffffff8125afc7>] cmp_and_merge_page+0xe7/0x1e0 > [ 191.230031] [<ffffffff8125b125>] ksm_do_scan+0x65/0xa0 > [ 191.230031] [<ffffffff8125b1cf>] ksm_scan_thread+0x6f/0x2d0 > [ 191.230031] [<ffffffff8113deb0>] ? abort_exclusive_wait+0xb0/0xb0 > [ 191.230031] [<ffffffff8125b160>] ? ksm_do_scan+0xa0/0xa0 > [ 191.230031] [<ffffffff8113cc43>] kthread+0xe3/0xf0 > [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 > [ 191.230031] [<ffffffff83cdba7c>] ret_from_fork+0x7c/0xb0 > [ 191.230031] [<ffffffff8113cb60>] ? __kthread_bind+0x40/0x40 > [ 191.230031] Code: 00 83 3d 33 2b b0 05 00 0f 85 d5 09 00 00 be f9 0b 00 00 48 c7 c7 24 d1 b2 84 89 55 88 e8 09 80 f8 ff 8b 55 > 88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 83 fc 01 77 > [ 191.230031] RIP [<ffffffff81185bf0>] __lock_acquire+0xb0/0xa90 > [ 191.230031] RSP <ffff8800be933b78> > [ 191.230031] CR2: 0000000000000110 > [ 191.230031] ---[ end trace 55f664bfe0f01693 ]--- > > > Thanks, > Sasha ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 22:37 ` Hugh Dickins @ 2012-12-20 22:43 ` Sasha Levin -1 siblings, 0 replies; 22+ messages in thread From: Sasha Levin @ 2012-12-20 22:43 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, Petr Holasek, linux-kernel, linux-mm On 12/20/2012 05:37 PM, Hugh Dickins wrote: > On Thu, 20 Dec 2012, Sasha Levin wrote: >> On 12/19/2012 08:44 PM, Hugh Dickins wrote: >>> The rmap walks in ksm.c are like those in rmap.c: >>> they can safely be done with anon_vma_lock_read(). >>> >>> Signed-off-by: Hugh Dickins <hughd@google.com> >>> --- >> >> Hi Hugh, >> >> This patch didn't fix the ksm oopses I'm seeing. > > I wouldn't expect it to (and should certainly have mentioned oopses > in the commit message if I'd intended): this patch was merely an > optimization/clarification of a commit gone in for 3.8-rc1. > > Understandable misunderstanding: you took my Cc too seriously, > I just thought I'd better keep Petr in the loop on current changes > to ksm.c, and foolishly kept you in too ;) > > Your oopses are on linux-next, which as of 20121220 still had Petr's > nice but buggy NUMA KSM patch in: it should go away when Stephen gets > a fresh mm update from Andrew, then reappear once his v6 goes into mm. > > To stop these oopses in get_mergeable_page (inlined in > unstable_tree_search_insert) you need the patch I showed on > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > all of the problems, but hopefully all that you'll encounter before > I've devised a fix for the separate stale stable_nodes issue. My bad! I thought that this is the finalized version of the patch from Tuesday and was surprised when the oops was still there :) fwiw I'll use this to report that I'm not seeing any unexpected behaviour with this patch applied. Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-20 22:43 ` Sasha Levin 0 siblings, 0 replies; 22+ messages in thread From: Sasha Levin @ 2012-12-20 22:43 UTC (permalink / raw) To: Hugh Dickins Cc: Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, Petr Holasek, linux-kernel, linux-mm On 12/20/2012 05:37 PM, Hugh Dickins wrote: > On Thu, 20 Dec 2012, Sasha Levin wrote: >> On 12/19/2012 08:44 PM, Hugh Dickins wrote: >>> The rmap walks in ksm.c are like those in rmap.c: >>> they can safely be done with anon_vma_lock_read(). >>> >>> Signed-off-by: Hugh Dickins <hughd@google.com> >>> --- >> >> Hi Hugh, >> >> This patch didn't fix the ksm oopses I'm seeing. > > I wouldn't expect it to (and should certainly have mentioned oopses > in the commit message if I'd intended): this patch was merely an > optimization/clarification of a commit gone in for 3.8-rc1. > > Understandable misunderstanding: you took my Cc too seriously, > I just thought I'd better keep Petr in the loop on current changes > to ksm.c, and foolishly kept you in too ;) > > Your oopses are on linux-next, which as of 20121220 still had Petr's > nice but buggy NUMA KSM patch in: it should go away when Stephen gets > a fresh mm update from Andrew, then reappear once his v6 goes into mm. > > To stop these oopses in get_mergeable_page (inlined in > unstable_tree_search_insert) you need the patch I showed on > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > all of the problems, but hopefully all that you'll encounter before > I've devised a fix for the separate stale stable_nodes issue. My bad! I thought that this is the finalized version of the patch from Tuesday and was surprised when the oops was still there :) fwiw I'll use this to report that I'm not seeing any unexpected behaviour with this patch applied. Thanks, Sasha ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-20 22:43 ` Sasha Levin @ 2012-12-21 0:36 ` Petr Holasek -1 siblings, 0 replies; 22+ messages in thread From: Petr Holasek @ 2012-12-21 0:36 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, linux-kernel, linux-mm On Thu, 20 Dec 2012, Sasha Levin wrote: > On 12/20/2012 05:37 PM, Hugh Dickins wrote: > > On Thu, 20 Dec 2012, Sasha Levin wrote: > >> On 12/19/2012 08:44 PM, Hugh Dickins wrote: > >>> The rmap walks in ksm.c are like those in rmap.c: > >>> they can safely be done with anon_vma_lock_read(). > >>> > >>> Signed-off-by: Hugh Dickins <hughd@google.com> > >>> --- > >> > >> Hi Hugh, > >> > >> This patch didn't fix the ksm oopses I'm seeing. > > > > I wouldn't expect it to (and should certainly have mentioned oopses > > in the commit message if I'd intended): this patch was merely an > > optimization/clarification of a commit gone in for 3.8-rc1. > > > > Understandable misunderstanding: you took my Cc too seriously, > > I just thought I'd better keep Petr in the loop on current changes > > to ksm.c, and foolishly kept you in too ;) > > > > Your oopses are on linux-next, which as of 20121220 still had Petr's > > nice but buggy NUMA KSM patch in: it should go away when Stephen gets > > a fresh mm update from Andrew, then reappear once his v6 goes into mm. > > > > To stop these oopses in get_mergeable_page (inlined in > > unstable_tree_search_insert) you need the patch I showed on > > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > > all of the problems, but hopefully all that you'll encounter before > > I've devised a fix for the separate stale stable_nodes issue. > > My bad! I thought that this is the finalized version of the patch from > Tuesday and was surprised when the oops was still there :) > > fwiw I'll use this to report that I'm not seeing any unexpected behaviour > with this patch applied. > > > Thanks, > Sasha > Hugh, big thanks for your Tuesday fix, I am not able to reproduce reported oops any more. I will continue with testing overnight and submit v6 version tomorrow if there won't be any problem. Should I also add [PATCH] ksm: make rmap walks more scalable into v6 or can I rely on it? thanks, Petr H -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-21 0:36 ` Petr Holasek 0 siblings, 0 replies; 22+ messages in thread From: Petr Holasek @ 2012-12-21 0:36 UTC (permalink / raw) To: Sasha Levin Cc: Hugh Dickins, Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, linux-kernel, linux-mm On Thu, 20 Dec 2012, Sasha Levin wrote: > On 12/20/2012 05:37 PM, Hugh Dickins wrote: > > On Thu, 20 Dec 2012, Sasha Levin wrote: > >> On 12/19/2012 08:44 PM, Hugh Dickins wrote: > >>> The rmap walks in ksm.c are like those in rmap.c: > >>> they can safely be done with anon_vma_lock_read(). > >>> > >>> Signed-off-by: Hugh Dickins <hughd@google.com> > >>> --- > >> > >> Hi Hugh, > >> > >> This patch didn't fix the ksm oopses I'm seeing. > > > > I wouldn't expect it to (and should certainly have mentioned oopses > > in the commit message if I'd intended): this patch was merely an > > optimization/clarification of a commit gone in for 3.8-rc1. > > > > Understandable misunderstanding: you took my Cc too seriously, > > I just thought I'd better keep Petr in the loop on current changes > > to ksm.c, and foolishly kept you in too ;) > > > > Your oopses are on linux-next, which as of 20121220 still had Petr's > > nice but buggy NUMA KSM patch in: it should go away when Stephen gets > > a fresh mm update from Andrew, then reappear once his v6 goes into mm. > > > > To stop these oopses in get_mergeable_page (inlined in > > unstable_tree_search_insert) you need the patch I showed on > > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > > all of the problems, but hopefully all that you'll encounter before > > I've devised a fix for the separate stale stable_nodes issue. > > My bad! I thought that this is the finalized version of the patch from > Tuesday and was surprised when the oops was still there :) > > fwiw I'll use this to report that I'm not seeing any unexpected behaviour > with this patch applied. > > > Thanks, > Sasha > Hugh, big thanks for your Tuesday fix, I am not able to reproduce reported oops any more. I will continue with testing overnight and submit v6 version tomorrow if there won't be any problem. Should I also add [PATCH] ksm: make rmap walks more scalable into v6 or can I rely on it? thanks, Petr H ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable 2012-12-21 0:36 ` Petr Holasek @ 2012-12-21 2:35 ` Hugh Dickins -1 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-21 2:35 UTC (permalink / raw) To: Petr Holasek Cc: Sasha Levin, Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, linux-kernel, linux-mm On Fri, 21 Dec 2012, Petr Holasek wrote: > On Thu, 20 Dec 2012, Sasha Levin wrote: > > On 12/20/2012 05:37 PM, Hugh Dickins wrote: > > > > > > To stop these oopses in get_mergeable_page (inlined in > > > unstable_tree_search_insert) you need the patch I showed on > > > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > > > all of the problems, but hopefully all that you'll encounter before > > > I've devised a fix for the separate stale stable_nodes issue. > > > > My bad! I thought that this is the finalized version of the patch from > > Tuesday and was surprised when the oops was still there :) > > > > fwiw I'll use this to report that I'm not seeing any unexpected behaviour > > with this patch applied. Thanks, Sasha. > > Hugh, big thanks for your Tuesday fix, I am not able to reproduce reported > oops any more. I will continue with testing overnight and submit v6 version > tomorrow if there won't be any problem. Great, thank you Petr. > > Should I also add [PATCH] ksm: make rmap walks more scalable into v6 or > can I rely on it? No, this rmap walks patch is entirely independent of your changes, and already picked up by Linus into his tree for rc1. By all means test with it in, or out, but don't fold it into your v6: Andrew's mmotm posted just now has it already in too. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] ksm: make rmap walks more scalable @ 2012-12-21 2:35 ` Hugh Dickins 0 siblings, 0 replies; 22+ messages in thread From: Hugh Dickins @ 2012-12-21 2:35 UTC (permalink / raw) To: Petr Holasek Cc: Sasha Levin, Mel Gorman, Linus Torvalds, Andrew Morton, Ingo Molnar, linux-kernel, linux-mm On Fri, 21 Dec 2012, Petr Holasek wrote: > On Thu, 20 Dec 2012, Sasha Levin wrote: > > On 12/20/2012 05:37 PM, Hugh Dickins wrote: > > > > > > To stop these oopses in get_mergeable_page (inlined in > > > unstable_tree_search_insert) you need the patch I showed on > > > Tuesday, which I hope he'll merge in for his v6. That doesn't fix > > > all of the problems, but hopefully all that you'll encounter before > > > I've devised a fix for the separate stale stable_nodes issue. > > > > My bad! I thought that this is the finalized version of the patch from > > Tuesday and was surprised when the oops was still there :) > > > > fwiw I'll use this to report that I'm not seeing any unexpected behaviour > > with this patch applied. Thanks, Sasha. > > Hugh, big thanks for your Tuesday fix, I am not able to reproduce reported > oops any more. I will continue with testing overnight and submit v6 version > tomorrow if there won't be any problem. Great, thank you Petr. > > Should I also add [PATCH] ksm: make rmap walks more scalable into v6 or > can I rely on it? No, this rmap walks patch is entirely independent of your changes, and already picked up by Linus into his tree for rc1. By all means test with it in, or out, but don't fold it into your v6: Andrew's mmotm posted just now has it already in too. Hugh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] sched: numa: ksm: fix oops in task_numa_placment() 2012-12-20 1:42 ` Hugh Dickins @ 2012-12-20 11:14 ` Mel Gorman -1 siblings, 0 replies; 22+ messages in thread From: Mel Gorman @ 2012-12-20 11:14 UTC (permalink / raw) To: Hugh Dickins Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm On Wed, Dec 19, 2012 at 05:42:16PM -0800, Hugh Dickins wrote: > task_numa_placement() oopsed on NULL p->mm when task_numa_fault() > got called in the handling of break_ksm() for ksmd. That might be a > peculiar case, which perhaps KSM could takes steps to avoid? but it's > more robust if task_numa_placement() allows for such a possibility. > > Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Mel Gorman <mgorman@suse.de> -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] sched: numa: ksm: fix oops in task_numa_placment() @ 2012-12-20 11:14 ` Mel Gorman 0 siblings, 0 replies; 22+ messages in thread From: Mel Gorman @ 2012-12-20 11:14 UTC (permalink / raw) To: Hugh Dickins Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Sasha Levin, Petr Holasek, linux-kernel, linux-mm On Wed, Dec 19, 2012 at 05:42:16PM -0800, Hugh Dickins wrote: > task_numa_placement() oopsed on NULL p->mm when task_numa_fault() > got called in the handling of break_ksm() for ksmd. That might be a > peculiar case, which perhaps KSM could takes steps to avoid? but it's > more robust if task_numa_placement() allows for such a possibility. > > Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Mel Gorman <mgorman@suse.de> -- Mel Gorman SUSE Labs ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2012-12-21 2:35 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-20 1:42 [PATCH] sched: numa: ksm: fix oops in task_numa_placment() Hugh Dickins 2012-12-20 1:42 ` Hugh Dickins 2012-12-20 1:44 ` [PATCH] ksm: make rmap walks more scalable Hugh Dickins 2012-12-20 1:44 ` Hugh Dickins 2012-12-20 11:17 ` Mel Gorman 2012-12-20 11:17 ` Mel Gorman 2012-12-20 21:49 ` Sasha Levin 2012-12-20 21:49 ` Sasha Levin 2012-12-20 22:26 ` Linus Torvalds 2012-12-20 22:26 ` Linus Torvalds 2012-12-20 22:40 ` Hugh Dickins 2012-12-20 22:40 ` Hugh Dickins 2012-12-20 22:37 ` Hugh Dickins 2012-12-20 22:37 ` Hugh Dickins 2012-12-20 22:43 ` Sasha Levin 2012-12-20 22:43 ` Sasha Levin 2012-12-21 0:36 ` Petr Holasek 2012-12-21 0:36 ` Petr Holasek 2012-12-21 2:35 ` Hugh Dickins 2012-12-21 2:35 ` Hugh Dickins 2012-12-20 11:14 ` [PATCH] sched: numa: ksm: fix oops in task_numa_placment() Mel Gorman 2012-12-20 11:14 ` Mel Gorman
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.