* linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state @ 2020-03-07 21:05 syzbot 2020-03-09 9:24 ` Kirill A. Shutemov 0 siblings, 1 reply; 9+ messages in thread From: syzbot @ 2020-03-07 21:05 UTC (permalink / raw) To: akpm, cgroups, hannes, linux-kernel, linux-mm, mhocko, syzkaller-bugs, vdavydov.dev Hello, syzbot found the following crash on: HEAD commit: b86a6a24 Add linux-next specific files for 20200306 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1766b731e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=9c79dccc623ccc6f dashboard link: https://syzkaller.appspot.com/bug?extid=826543256ed3b8c37f62 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+826543256ed3b8c37f62@syzkaller.appspotmail.com check_preemption_disabled: 3 callbacks suppressed BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 __split_huge_page mm/huge_memory.c:2575 [inline] split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 split_huge_page include/linux/huge_mm.h:167 [inline] madvise_free_huge_pmd+0x873/0xb90 mm/huge_memory.c:1766 madvise_free_pte_range+0x6ff/0x2650 mm/madvise.c:584 walk_pmd_range mm/pagewalk.c:89 [inline] walk_pud_range mm/pagewalk.c:160 [inline] walk_p4d_range mm/pagewalk.c:193 [inline] walk_pgd_range mm/pagewalk.c:229 [inline] __walk_page_range+0xcfb/0x2070 mm/pagewalk.c:331 walk_page_range+0x1bd/0x3a0 mm/pagewalk.c:427 madvise_free_single_vma+0x384/0x550 mm/madvise.c:731 madvise_dontneed_free mm/madvise.c:819 [inline] madvise_vma mm/madvise.c:958 [inline] do_madvise mm/madvise.c:1161 [inline] do_madvise+0x5ba/0x1b80 mm/madvise.c:1084 __do_sys_madvise mm/madvise.c:1189 [inline] __se_sys_madvise mm/madvise.c:1187 [inline] __x64_sys_madvise+0xae/0x120 mm/madvise.c:1187 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x460bf7 Code: 8b 24 24 48 8b 6c 24 10 48 83 c4 18 c3 cc cc cc cc cc cc 48 8b 7c 24 08 48 8b 74 24 10 8b 54 24 18 48 c7 c0 1c 00 00 00 0f 05 <89> 44 24 20 c3 cc cc cc cc 48 8b 7c 24 08 8b 74 24 10 8b 54 24 14 RSP: 002b:00007ffd6e086670 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 0000000000460bf7 RDX: 0000000000000008 RSI: 000000000000a000 RDI: 000000c00029a000 RBP: 00007ffd6e0866b0 R08: 000000c000200000 R09: 000000c0002a4000 R10: 00007fffffffffff R11: 0000000000000246 R12: 0000000000000007 R13: 00007f30cae546d0 R14: 0000000000000080 R15: 00000000000000fa BUG: using __this_cpu_add() in preemptible [00000000] code: syz-fuzzer/9432 caller is __mod_memcg_state+0xca/0x1a0 mm/memcontrol.c:697 CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 __mod_memcg_state+0xca/0x1a0 mm/memcontrol.c:697 __split_huge_page mm/huge_memory.c:2575 [inline] split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 split_huge_page include/linux/huge_mm.h:167 [inline] madvise_free_huge_pmd+0x873/0xb90 mm/huge_memory.c:1766 madvise_free_pte_range+0x6ff/0x2650 mm/madvise.c:584 walk_pmd_range mm/pagewalk.c:89 [inline] walk_pud_range mm/pagewalk.c:160 [inline] walk_p4d_range mm/pagewalk.c:193 [inline] walk_pgd_range mm/pagewalk.c:229 [inline] __walk_page_range+0xcfb/0x2070 mm/pagewalk.c:331 walk_page_range+0x1bd/0x3a0 mm/pagewalk.c:427 madvise_free_single_vma+0x384/0x550 mm/madvise.c:731 madvise_dontneed_free mm/madvise.c:819 [inline] madvise_vma mm/madvise.c:958 [inline] do_madvise mm/madvise.c:1161 [inline] do_madvise+0x5ba/0x1b80 mm/madvise.c:1084 __do_sys_madvise mm/madvise.c:1189 [inline] __se_sys_madvise mm/madvise.c:1187 [inline] __x64_sys_madvise+0xae/0x120 mm/madvise.c:1187 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x460bf7 Code: 8b 24 24 48 8b 6c 24 10 48 83 c4 18 c3 cc cc cc cc cc cc 48 8b 7c 24 08 48 8b 74 24 10 8b 54 24 18 48 c7 c0 1c 00 00 00 0f 05 <89> 44 24 20 c3 cc cc cc cc 48 8b 7c 24 08 8b 74 24 10 8b 54 24 14 RSP: 002b:00007ffd6e086670 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 0000000000460bf7 RDX: 0000000000000008 RSI: 000000000000a000 RDI: 000000c00029a000 RBP: 00007ffd6e0866b0 R08: 000000c000200000 R09: 000000c0002a4000 R10: 00007fffffffffff R11: 0000000000000246 R12: 0000000000000007 R13: 00007f30cae546d0 R14: 0000000000000080 R15: 00000000000000fa BUG: using __this_cpu_write() in preemptible [00000000] code: syz-fuzzer/9432 caller is __mod_memcg_state+0x87/0x1a0 mm/memcontrol.c:702 CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 __mod_memcg_state+0x87/0x1a0 mm/memcontrol.c:702 __split_huge_page mm/huge_memory.c:2575 [inline] split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 split_huge_page include/linux/huge_mm.h:167 [inline] madvise_free_huge_pmd+0x873/0xb90 mm/huge_memory.c:1766 madvise_free_pte_range+0x6ff/0x2650 mm/madvise.c:584 walk_pmd_range mm/pagewalk.c:89 [inline] walk_pud_range mm/pagewalk.c:160 [inline] walk_p4d_range mm/pagewalk.c:193 [inline] walk_pgd_range mm/pagewalk.c:229 [inline] __walk_page_range+0xcfb/0x2070 mm/pagewalk.c:331 walk_page_range+0x1bd/0x3a0 mm/pagewalk.c:427 madvise_free_single_vma+0x384/0x550 mm/madvise.c:731 madvise_dontneed_free mm/madvise.c:819 [inline] madvise_vma mm/madvise.c:958 [inline] do_madvise mm/madvise.c:1161 [inline] do_madvise+0x5ba/0x1b80 mm/madvise.c:1084 __do_sys_madvise mm/madvise.c:1189 [inline] __se_sys_madvise mm/madvise.c:1187 [inline] __x64_sys_madvise+0xae/0x120 mm/madvise.c:1187 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x460bf7 Code: 8b 24 24 48 8b 6c 24 10 48 83 c4 18 c3 cc cc cc cc cc cc 48 8b 7c 24 08 48 8b 74 24 10 8b 54 24 18 48 c7 c0 1c 00 00 00 0f 05 <89> 44 24 20 c3 cc cc cc cc 48 8b 7c 24 08 8b 74 24 10 8b 54 24 14 RSP: 002b:00007ffd6e086670 EFLAGS: 00000246 ORIG_RAX: 000000000000001c RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 0000000000460bf7 RDX: 0000000000000008 RSI: 000000000000a000 RDI: 000000c00029a000 RBP: 00007ffd6e0866b0 R08: 000000c000200000 R09: 000000c0002a4000 R10: 00007fffffffffff R11: 0000000000000246 R12: 0000000000000007 R13: 00007f30cae546d0 R14: 0000000000000080 R15: 00000000000000fa --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-03-07 21:05 linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state syzbot @ 2020-03-09 9:24 ` Kirill A. Shutemov 2020-03-09 9:56 ` Alex Shi 0 siblings, 1 reply; 9+ messages in thread From: Kirill A. Shutemov @ 2020-03-09 9:24 UTC (permalink / raw) To: syzbot, Alex Shi Cc: akpm, cgroups, hannes, linux-kernel, linux-mm, mhocko, syzkaller-bugs, vdavydov.dev On Sat, Mar 07, 2020 at 01:05:10PM -0800, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: b86a6a24 Add linux-next specific files for 20200306 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1766b731e00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9c79dccc623ccc6f > dashboard link: https://syzkaller.appspot.com/bug?extid=826543256ed3b8c37f62 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+826543256ed3b8c37f62@syzkaller.appspotmail.com > > check_preemption_disabled: 3 callbacks suppressed > BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 > caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x188/0x20d lib/dump_stack.c:118 > check_preemption_disabled lib/smp_processor_id.c:47 [inline] > __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 > __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > __split_huge_page mm/huge_memory.c:2575 [inline] > split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 > split_huge_page include/linux/huge_mm.h:167 [inline] It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru locking"). Alex? > madvise_free_huge_pmd+0x873/0xb90 mm/huge_memory.c:1766 > madvise_free_pte_range+0x6ff/0x2650 mm/madvise.c:584 > walk_pmd_range mm/pagewalk.c:89 [inline] > walk_pud_range mm/pagewalk.c:160 [inline] > walk_p4d_range mm/pagewalk.c:193 [inline] > walk_pgd_range mm/pagewalk.c:229 [inline] > __walk_page_range+0xcfb/0x2070 mm/pagewalk.c:331 > walk_page_range+0x1bd/0x3a0 mm/pagewalk.c:427 > madvise_free_single_vma+0x384/0x550 mm/madvise.c:731 > madvise_dontneed_free mm/madvise.c:819 [inline] > madvise_vma mm/madvise.c:958 [inline] > do_madvise mm/madvise.c:1161 [inline] > do_madvise+0x5ba/0x1b80 mm/madvise.c:1084 > __do_sys_madvise mm/madvise.c:1189 [inline] > __se_sys_madvise mm/madvise.c:1187 [inline] > __x64_sys_madvise+0xae/0x120 mm/madvise.c:1187 > do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x460bf7 -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-03-09 9:24 ` Kirill A. Shutemov @ 2020-03-09 9:56 ` Alex Shi 2020-03-09 13:26 ` Alex Shi 0 siblings, 1 reply; 9+ messages in thread From: Alex Shi @ 2020-03-09 9:56 UTC (permalink / raw) To: Kirill A. Shutemov, syzbot Cc: akpm, cgroups, hannes, linux-kernel, linux-mm, mhocko, syzkaller-bugs, vdavydov.dev 在 2020/3/9 下午5:24, Kirill A. Shutemov 写道: >> check_preemption_disabled: 3 callbacks suppressed >> BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 >> caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 >> CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:77 [inline] >> dump_stack+0x188/0x20d lib/dump_stack.c:118 >> check_preemption_disabled lib/smp_processor_id.c:47 [inline] >> __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 >> __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 >> __split_huge_page mm/huge_memory.c:2575 [inline] >> split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 >> split_huge_page include/linux/huge_mm.h:167 [inline] > It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru > locking"). yes, I guess so. In this patch, I am very bold to move the lru unlock from before 'remap_page(head);' up to before 'ClearPageCompound(head);' which is often checked in lrulock. I want to know which part that real should stay in lru_lock. So revert this patch or move it back or move after ClearPageCompound should fix this problem. In the weekend and today, I tried a lot to reproduce this bug on my 2 machines, but still can't. :~( Many thanks to give a try! Thank Alex line 2605 mm/huge_memory.c: spin_unlock_irqrestore(&pgdat->lru_lock, flags); ClearPageCompound(head); split_page_owner(head, HPAGE_PMD_ORDER); /* See comment in __split_huge_page_tail() */ if (PageAnon(head)) { /* Additional pin to swap cache */ if (PageSwapCache(head)) { page_ref_add(head, 2); xa_unlock(&swap_cache->i_pages); } else { page_ref_inc(head); } } else { /* Additional pin to page cache */ page_ref_add(head, 2); xa_unlock(&head->mapping->i_pages); } remap_page(head); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-03-09 9:56 ` Alex Shi @ 2020-03-09 13:26 ` Alex Shi 2020-04-18 7:04 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Alex Shi @ 2020-03-09 13:26 UTC (permalink / raw) To: Kirill A. Shutemov, syzbot Cc: akpm, cgroups, hannes, linux-kernel, linux-mm, mhocko, syzkaller-bugs, vdavydov.dev 在 2020/3/9 下午5:56, Alex Shi 写道: > > > 在 2020/3/9 下午5:24, Kirill A. Shutemov 写道: >>> check_preemption_disabled: 3 callbacks suppressed >>> BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 >>> caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 >>> CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >>> Call Trace: >>> __dump_stack lib/dump_stack.c:77 [inline] >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 >>> check_preemption_disabled lib/smp_processor_id.c:47 [inline] >>> __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 >>> __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 >>> __split_huge_page mm/huge_memory.c:2575 [inline] >>> split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 >>> split_huge_page include/linux/huge_mm.h:167 [inline] >> It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru >> locking"). > > yes, I guess so. Yes, it is a stupid mistake to pull out lock for __mod_memcg_state which should be in a lock. revert this patch should be all fine, since ClearPageCompound and page_ref_inc later may related with lru_list valid issue in release_pges. Sorry for the disaster! Alex ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-03-09 13:26 ` Alex Shi @ 2020-04-18 7:04 ` Dmitry Vyukov 2020-04-18 7:43 ` Stephen Rothwell 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Vyukov @ 2020-04-18 7:04 UTC (permalink / raw) To: Alex Shi, Linux-Next Mailing List, Stephen Rothwell Cc: Kirill A. Shutemov, syzbot, Andrew Morton, Cgroups, Johannes Weiner, LKML, Linux-MM, Michal Hocko, syzkaller-bugs, Vladimir Davydov On Mon, Mar 9, 2020 at 2:27 PM Alex Shi <alex.shi@linux.alibaba.com> wrote: > 在 2020/3/9 下午5:56, Alex Shi 写道: > > > > > > 在 2020/3/9 下午5:24, Kirill A. Shutemov 写道: > >>> check_preemption_disabled: 3 callbacks suppressed > >>> BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 > >>> caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > >>> CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > >>> Call Trace: > >>> __dump_stack lib/dump_stack.c:77 [inline] > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 > >>> check_preemption_disabled lib/smp_processor_id.c:47 [inline] > >>> __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 > >>> __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > >>> __split_huge_page mm/huge_memory.c:2575 [inline] > >>> split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 > >>> split_huge_page include/linux/huge_mm.h:167 [inline] > >> It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru > >> locking"). > > > > yes, I guess so. > > Yes, it is a stupid mistake to pull out lock for __mod_memcg_state which > should be in a lock. > > revert this patch should be all fine, since ClearPageCompound and page_ref_inc > later may related with lru_list valid issue in release_pges. > > > Sorry for the disaster! > > Alex +linux-next, Stephen for currently open linux-next build/boot failure Hi Alex, What's the status of this? Was the guilty patch reverted? If so, please mark it as invalid for syzbot, otherwise it still shows up as open bug. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-04-18 7:04 ` Dmitry Vyukov @ 2020-04-18 7:43 ` Stephen Rothwell 2020-04-18 7:50 ` Stephen Rothwell 0 siblings, 1 reply; 9+ messages in thread From: Stephen Rothwell @ 2020-04-18 7:43 UTC (permalink / raw) To: Dmitry Vyukov Cc: Alex Shi, Linux-Next Mailing List, Kirill A. Shutemov, syzbot, Andrew Morton, Cgroups, Johannes Weiner, LKML, Linux-MM, Michal Hocko, syzkaller-bugs, Vladimir Davydov [-- Attachment #1: Type: text/plain, Size: 2113 bytes --] Hi Dmitry, On Sat, 18 Apr 2020 09:04:38 +0200 Dmitry Vyukov <dvyukov@google.com> wrote: > > On Mon, Mar 9, 2020 at 2:27 PM Alex Shi <alex.shi@linux.alibaba.com> wrote: > > 在 2020/3/9 下午5:56, Alex Shi 写道: > > > > > > > > > 在 2020/3/9 下午5:24, Kirill A. Shutemov 写道: > > >>> check_preemption_disabled: 3 callbacks suppressed > > >>> BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 > > >>> caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > > >>> CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > >>> Call Trace: > > >>> __dump_stack lib/dump_stack.c:77 [inline] > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 > > >>> check_preemption_disabled lib/smp_processor_id.c:47 [inline] > > >>> __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 > > >>> __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > > >>> __split_huge_page mm/huge_memory.c:2575 [inline] > > >>> split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 > > >>> split_huge_page include/linux/huge_mm.h:167 [inline] > > >> It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru > > >> locking"). > > > > > > yes, I guess so. > > > > Yes, it is a stupid mistake to pull out lock for __mod_memcg_state which > > should be in a lock. > > > > revert this patch should be all fine, since ClearPageCompound and page_ref_inc > > later may related with lru_list valid issue in release_pges. > > > > > > Sorry for the disaster! > > > > Alex > > +linux-next, Stephen for currently open linux-next build/boot failure > > Hi Alex, > > What's the status of this? Was the guilty patch reverted? If so, > please mark it as invalid for syzbot, otherwise it still shows up as > open bug. The patch was removed from Andrew's tree in March and never made it to Linus' tree. I can't find how to tell syzbot that the patch went away ... -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-04-18 7:43 ` Stephen Rothwell @ 2020-04-18 7:50 ` Stephen Rothwell 2020-04-18 8:02 ` Dmitry Vyukov 0 siblings, 1 reply; 9+ messages in thread From: Stephen Rothwell @ 2020-04-18 7:50 UTC (permalink / raw) To: Dmitry Vyukov Cc: Alex Shi, Linux-Next Mailing List, Kirill A. Shutemov, syzbot, Andrew Morton, Cgroups, Johannes Weiner, LKML, Linux-MM, Michal Hocko, syzkaller-bugs, Vladimir Davydov [-- Attachment #1: Type: text/plain, Size: 2357 bytes --] Hi Stephen, On Sat, 18 Apr 2020 17:43:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Dmitry, > > On Sat, 18 Apr 2020 09:04:38 +0200 Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Mon, Mar 9, 2020 at 2:27 PM Alex Shi <alex.shi@linux.alibaba.com> wrote: > > > 在 2020/3/9 下午5:56, Alex Shi 写道: > > > > > > > > > > > > 在 2020/3/9 下午5:24, Kirill A. Shutemov 写道: > > > >>> check_preemption_disabled: 3 callbacks suppressed > > > >>> BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 > > > >>> caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > > > >>> CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 > > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > > >>> Call Trace: > > > >>> __dump_stack lib/dump_stack.c:77 [inline] > > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 > > > >>> check_preemption_disabled lib/smp_processor_id.c:47 [inline] > > > >>> __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 > > > >>> __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > > > >>> __split_huge_page mm/huge_memory.c:2575 [inline] > > > >>> split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 > > > >>> split_huge_page include/linux/huge_mm.h:167 [inline] > > > >> It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru > > > >> locking"). > > > > > > > > yes, I guess so. > > > > > > Yes, it is a stupid mistake to pull out lock for __mod_memcg_state which > > > should be in a lock. > > > > > > revert this patch should be all fine, since ClearPageCompound and page_ref_inc > > > later may related with lru_list valid issue in release_pges. > > > > > > > > > Sorry for the disaster! > > > > > > Alex > > > > +linux-next, Stephen for currently open linux-next build/boot failure > > > > Hi Alex, > > > > What's the status of this? Was the guilty patch reverted? If so, > > please mark it as invalid for syzbot, otherwise it still shows up as > > open bug. > > The patch was removed from Andrew's tree in March and never made it to > Linus' tree. I can't find how to tell syzbot that the patch went away ... Lets try: #syz invalid -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-04-18 7:50 ` Stephen Rothwell @ 2020-04-18 8:02 ` Dmitry Vyukov 2020-04-18 8:13 ` Stephen Rothwell 0 siblings, 1 reply; 9+ messages in thread From: Dmitry Vyukov @ 2020-04-18 8:02 UTC (permalink / raw) To: Stephen Rothwell Cc: Alex Shi, Linux-Next Mailing List, Kirill A. Shutemov, syzbot, Andrew Morton, Cgroups, Johannes Weiner, LKML, Linux-MM, Michal Hocko, syzkaller-bugs, Vladimir Davydov On Sat, Apr 18, 2020 at 9:51 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi Stephen, > > On Sat, 18 Apr 2020 17:43:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > Hi Dmitry, > > > > On Sat, 18 Apr 2020 09:04:38 +0200 Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > On Mon, Mar 9, 2020 at 2:27 PM Alex Shi <alex.shi@linux.alibaba.com> wrote: > > > > 在 2020/3/9 下午5:56, Alex Shi 写道: > > > > > > > > > > > > > > > 在 2020/3/9 下午5:24, Kirill A. Shutemov 写道: > > > > >>> check_preemption_disabled: 3 callbacks suppressed > > > > >>> BUG: using __this_cpu_read() in preemptible [00000000] code: syz-fuzzer/9432 > > > > >>> caller is __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > > > > >>> CPU: 1 PID: 9432 Comm: syz-fuzzer Not tainted 5.6.0-rc4-next-20200306-syzkaller #0 > > > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > > > >>> Call Trace: > > > > >>> __dump_stack lib/dump_stack.c:77 [inline] > > > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 > > > > >>> check_preemption_disabled lib/smp_processor_id.c:47 [inline] > > > > >>> __this_cpu_preempt_check.cold+0x84/0x90 lib/smp_processor_id.c:64 > > > > >>> __mod_memcg_state+0x27/0x1a0 mm/memcontrol.c:689 > > > > >>> __split_huge_page mm/huge_memory.c:2575 [inline] > > > > >>> split_huge_page_to_list+0x124b/0x3380 mm/huge_memory.c:2862 > > > > >>> split_huge_page include/linux/huge_mm.h:167 [inline] > > > > >> It looks like a regression due to c8cba0cc2a80 ("mm/thp: narrow lru > > > > >> locking"). > > > > > > > > > > yes, I guess so. > > > > > > > > Yes, it is a stupid mistake to pull out lock for __mod_memcg_state which > > > > should be in a lock. > > > > > > > > revert this patch should be all fine, since ClearPageCompound and page_ref_inc > > > > later may related with lru_list valid issue in release_pges. > > > > > > > > > > > > Sorry for the disaster! > > > > > > > > Alex > > > > > > +linux-next, Stephen for currently open linux-next build/boot failure > > > > > > Hi Alex, > > > > > > What's the status of this? Was the guilty patch reverted? If so, > > > please mark it as invalid for syzbot, otherwise it still shows up as > > > open bug. > > > > The patch was removed from Andrew's tree in March and never made it to > > Linus' tree. I can't find how to tell syzbot that the patch went away ... > > Lets try: > > #syz invalid This is correct, thanks! You may now see "Status: closed as invalid on 2020/04/18 07:51" at: https://syzkaller.appspot.com/bug?extid=826543256ed3b8c37f62 It does not show up as "open" and if this will happen again syzbot will report it (rather than assume it's still the old bug happening). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state 2020-04-18 8:02 ` Dmitry Vyukov @ 2020-04-18 8:13 ` Stephen Rothwell 0 siblings, 0 replies; 9+ messages in thread From: Stephen Rothwell @ 2020-04-18 8:13 UTC (permalink / raw) To: Dmitry Vyukov Cc: Alex Shi, Linux-Next Mailing List, Kirill A. Shutemov, syzbot, Andrew Morton, Cgroups, Johannes Weiner, LKML, Linux-MM, Michal Hocko, syzkaller-bugs, Vladimir Davydov [-- Attachment #1: Type: text/plain, Size: 490 bytes --] Hi Dmitry, On Sat, 18 Apr 2020 10:02:36 +0200 Dmitry Vyukov <dvyukov@google.com> wrote: > > > > #syz invalid > > This is correct, thanks! > > You may now see "Status: closed as invalid on 2020/04/18 07:51" at: > https://syzkaller.appspot.com/bug?extid=826543256ed3b8c37f62 > > It does not show up as "open" and if this will happen again syzbot > will report it (rather than assume it's still the old bug happening). OK, good, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-04-18 8:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-07 21:05 linux-next test error: BUG: using __this_cpu_read() in preemptible code in __mod_memcg_state syzbot 2020-03-09 9:24 ` Kirill A. Shutemov 2020-03-09 9:56 ` Alex Shi 2020-03-09 13:26 ` Alex Shi 2020-04-18 7:04 ` Dmitry Vyukov 2020-04-18 7:43 ` Stephen Rothwell 2020-04-18 7:50 ` Stephen Rothwell 2020-04-18 8:02 ` Dmitry Vyukov 2020-04-18 8:13 ` Stephen Rothwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).