linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* 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).