From: Daniel Axtens <dja@axtens.net> To: Dmitry Vyukov <dvyukov@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Qian Cai <cai@lca.pw>, kasan-dev <kasan-dev@googlegroups.com>, Linux-MM <linux-mm@kvack.org>, the arch/x86 maintainers <x86@kernel.org>, Alexander Potapenko <glider@google.com>, Andy Lutomirski <luto@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>, Christophe Leroy <christophe.leroy@c-s.fr>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, Vasily Gorbik <gor@linux.ibm.com> Subject: Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory Date: Fri, 29 Nov 2019 23:09:27 +1100 [thread overview] Message-ID: <874kymg9zc.fsf@dja-thinkpad.axtens.net> (raw) In-Reply-To: <CACT4Y+Z+VhfVpkfg-WFq_kFMY=DE+9b_DCi-mCSPK-udaf_Arg@mail.gmail.com> Hi Dmitry, >> I am testing this support on next-20191129 and seeing the following warnings: >> >> BUG: sleeping function called from invalid context at mm/page_alloc.c:4681 >> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 44, name: kworker/1:1 >> 4 locks held by kworker/1:1/44: >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> __write_once_size include/linux/compiler.h:247 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: atomic64_set >> include/asm-generic/atomic-instrumented.h:868 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> atomic_long_set include/asm-generic/atomic-long.h:40 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: set_work_data >> kernel/workqueue.c:615 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> set_work_pool_and_clear_pending kernel/workqueue.c:642 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> process_one_work+0x88b/0x1750 kernel/workqueue.c:2235 >> #1: ffffc900002afdf0 (pcpu_balance_work){+.+.}, at: >> process_one_work+0x8c0/0x1750 kernel/workqueue.c:2239 >> #2: ffffffff8943f080 (pcpu_alloc_mutex){+.+.}, at: >> pcpu_balance_workfn+0xcc/0x13e0 mm/percpu.c:1845 >> #3: ffffffff89450c78 (vmap_area_lock){+.+.}, at: spin_lock >> include/linux/spinlock.h:338 [inline] >> #3: ffffffff89450c78 (vmap_area_lock){+.+.}, at: >> pcpu_get_vm_areas+0x1449/0x3df0 mm/vmalloc.c:3431 >> Preemption disabled at: >> [<ffffffff81a84199>] spin_lock include/linux/spinlock.h:338 [inline] >> [<ffffffff81a84199>] pcpu_get_vm_areas+0x1449/0x3df0 mm/vmalloc.c:3431 >> CPU: 1 PID: 44 Comm: kworker/1:1 Not tainted 5.4.0-next-20191129+ #5 >> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014 >> Workqueue: events pcpu_balance_workfn >> Call Trace: >> __dump_stack lib/dump_stack.c:77 [inline] >> dump_stack+0x199/0x216 lib/dump_stack.c:118 >> ___might_sleep.cold.97+0x1f5/0x238 kernel/sched/core.c:6800 >> __might_sleep+0x95/0x190 kernel/sched/core.c:6753 >> prepare_alloc_pages mm/page_alloc.c:4681 [inline] >> __alloc_pages_nodemask+0x3cd/0x890 mm/page_alloc.c:4730 >> alloc_pages_current+0x10c/0x210 mm/mempolicy.c:2211 >> alloc_pages include/linux/gfp.h:532 [inline] >> __get_free_pages+0xc/0x40 mm/page_alloc.c:4786 >> kasan_populate_vmalloc_pte mm/kasan/common.c:762 [inline] >> kasan_populate_vmalloc_pte+0x2f/0x1b0 mm/kasan/common.c:753 >> apply_to_pte_range mm/memory.c:2041 [inline] >> apply_to_pmd_range mm/memory.c:2068 [inline] >> apply_to_pud_range mm/memory.c:2088 [inline] >> apply_to_p4d_range mm/memory.c:2108 [inline] >> apply_to_page_range+0x5ca/0xa00 mm/memory.c:2133 >> kasan_populate_vmalloc+0x69/0xa0 mm/kasan/common.c:791 >> pcpu_get_vm_areas+0x1596/0x3df0 mm/vmalloc.c:3439 >> pcpu_create_chunk+0x240/0x7f0 mm/percpu-vm.c:340 >> pcpu_balance_workfn+0x1033/0x13e0 mm/percpu.c:1934 >> process_one_work+0x9b5/0x1750 kernel/workqueue.c:2264 >> worker_thread+0x8b/0xd20 kernel/workqueue.c:2410 >> kthread+0x365/0x450 kernel/kthread.c:255 >> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 >> >> >> Not sure if it's the same or not. Is it addressed by something in flight? It looks like this one is the same. There is a patch to fix it: https://lore.kernel.org/linux-mm/20191120052719.7201-1-dja@axtens.net/ Andrew said he had picked it up on the 22nd: https://marc.info/?l=linux-mm-commits&m=157438241512561&w=2 It's landed in mmots but not mmotm, so hopefully that will happen and then it will land in -next very soon! I will look into your other bug report shortly. Regards, Daniel >> >> My config: >> https://gist.githubusercontent.com/dvyukov/36c7be311fdec9cd51c649f7c3cb2ddb/raw/39c6f864fdd0ffc53f0822b14c354a73c1695fa1/gistfile1.txt > > > I've tried this fix for pcpu_get_vm_areas: > https://groups.google.com/d/msg/kasan-dev/t_F2X1MWKwk/h152Z3q2AgAJ > and it helps. But this will break syzbot on linux-next soon.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Axtens <dja@axtens.net> To: Dmitry Vyukov <dvyukov@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Mark Rutland <mark.rutland@arm.com>, Vasily Gorbik <gor@linux.ibm.com>, the arch/x86 maintainers <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>, kasan-dev <kasan-dev@googlegroups.com>, Linux-MM <linux-mm@kvack.org>, Alexander Potapenko <glider@google.com>, Andy Lutomirski <luto@kernel.org>, Qian Cai <cai@lca.pw>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory Date: Fri, 29 Nov 2019 23:09:27 +1100 [thread overview] Message-ID: <874kymg9zc.fsf@dja-thinkpad.axtens.net> (raw) In-Reply-To: <CACT4Y+Z+VhfVpkfg-WFq_kFMY=DE+9b_DCi-mCSPK-udaf_Arg@mail.gmail.com> Hi Dmitry, >> I am testing this support on next-20191129 and seeing the following warnings: >> >> BUG: sleeping function called from invalid context at mm/page_alloc.c:4681 >> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 44, name: kworker/1:1 >> 4 locks held by kworker/1:1/44: >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> __write_once_size include/linux/compiler.h:247 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: atomic64_set >> include/asm-generic/atomic-instrumented.h:868 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> atomic_long_set include/asm-generic/atomic-long.h:40 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: set_work_data >> kernel/workqueue.c:615 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> set_work_pool_and_clear_pending kernel/workqueue.c:642 [inline] >> #0: ffff888067c26d28 ((wq_completion)events){+.+.}, at: >> process_one_work+0x88b/0x1750 kernel/workqueue.c:2235 >> #1: ffffc900002afdf0 (pcpu_balance_work){+.+.}, at: >> process_one_work+0x8c0/0x1750 kernel/workqueue.c:2239 >> #2: ffffffff8943f080 (pcpu_alloc_mutex){+.+.}, at: >> pcpu_balance_workfn+0xcc/0x13e0 mm/percpu.c:1845 >> #3: ffffffff89450c78 (vmap_area_lock){+.+.}, at: spin_lock >> include/linux/spinlock.h:338 [inline] >> #3: ffffffff89450c78 (vmap_area_lock){+.+.}, at: >> pcpu_get_vm_areas+0x1449/0x3df0 mm/vmalloc.c:3431 >> Preemption disabled at: >> [<ffffffff81a84199>] spin_lock include/linux/spinlock.h:338 [inline] >> [<ffffffff81a84199>] pcpu_get_vm_areas+0x1449/0x3df0 mm/vmalloc.c:3431 >> CPU: 1 PID: 44 Comm: kworker/1:1 Not tainted 5.4.0-next-20191129+ #5 >> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014 >> Workqueue: events pcpu_balance_workfn >> Call Trace: >> __dump_stack lib/dump_stack.c:77 [inline] >> dump_stack+0x199/0x216 lib/dump_stack.c:118 >> ___might_sleep.cold.97+0x1f5/0x238 kernel/sched/core.c:6800 >> __might_sleep+0x95/0x190 kernel/sched/core.c:6753 >> prepare_alloc_pages mm/page_alloc.c:4681 [inline] >> __alloc_pages_nodemask+0x3cd/0x890 mm/page_alloc.c:4730 >> alloc_pages_current+0x10c/0x210 mm/mempolicy.c:2211 >> alloc_pages include/linux/gfp.h:532 [inline] >> __get_free_pages+0xc/0x40 mm/page_alloc.c:4786 >> kasan_populate_vmalloc_pte mm/kasan/common.c:762 [inline] >> kasan_populate_vmalloc_pte+0x2f/0x1b0 mm/kasan/common.c:753 >> apply_to_pte_range mm/memory.c:2041 [inline] >> apply_to_pmd_range mm/memory.c:2068 [inline] >> apply_to_pud_range mm/memory.c:2088 [inline] >> apply_to_p4d_range mm/memory.c:2108 [inline] >> apply_to_page_range+0x5ca/0xa00 mm/memory.c:2133 >> kasan_populate_vmalloc+0x69/0xa0 mm/kasan/common.c:791 >> pcpu_get_vm_areas+0x1596/0x3df0 mm/vmalloc.c:3439 >> pcpu_create_chunk+0x240/0x7f0 mm/percpu-vm.c:340 >> pcpu_balance_workfn+0x1033/0x13e0 mm/percpu.c:1934 >> process_one_work+0x9b5/0x1750 kernel/workqueue.c:2264 >> worker_thread+0x8b/0xd20 kernel/workqueue.c:2410 >> kthread+0x365/0x450 kernel/kthread.c:255 >> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 >> >> >> Not sure if it's the same or not. Is it addressed by something in flight? It looks like this one is the same. There is a patch to fix it: https://lore.kernel.org/linux-mm/20191120052719.7201-1-dja@axtens.net/ Andrew said he had picked it up on the 22nd: https://marc.info/?l=linux-mm-commits&m=157438241512561&w=2 It's landed in mmots but not mmotm, so hopefully that will happen and then it will land in -next very soon! I will look into your other bug report shortly. Regards, Daniel >> >> My config: >> https://gist.githubusercontent.com/dvyukov/36c7be311fdec9cd51c649f7c3cb2ddb/raw/39c6f864fdd0ffc53f0822b14c354a73c1695fa1/gistfile1.txt > > > I've tried this fix for pcpu_get_vm_areas: > https://groups.google.com/d/msg/kasan-dev/t_F2X1MWKwk/h152Z3q2AgAJ > and it helps. But this will break syzbot on linux-next soon.
next prev parent reply other threads:[~2019-11-29 12:09 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-31 9:39 [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory Daniel Axtens 2019-10-31 9:39 ` [PATCH v11 1/4] " Daniel Axtens 2019-11-15 16:36 ` Qian Cai 2019-11-15 16:36 ` Qian Cai 2019-11-18 3:29 ` Daniel Axtens 2019-11-19 9:54 ` Andrey Ryabinin 2019-11-29 10:43 ` Dmitry Vyukov 2019-11-29 10:43 ` Dmitry Vyukov 2019-11-29 10:43 ` Dmitry Vyukov 2019-11-29 10:58 ` Dmitry Vyukov 2019-11-29 10:58 ` Dmitry Vyukov 2019-11-29 10:58 ` Dmitry Vyukov 2019-11-29 11:02 ` Dmitry Vyukov 2019-11-29 11:02 ` Dmitry Vyukov 2019-11-29 11:02 ` Dmitry Vyukov 2019-11-29 11:38 ` Andrey Ryabinin 2019-11-29 11:38 ` Andrey Ryabinin 2019-11-29 11:47 ` Dmitry Vyukov 2019-11-29 11:47 ` Dmitry Vyukov 2019-11-29 11:47 ` Dmitry Vyukov 2019-11-29 11:53 ` Andrey Ryabinin 2019-11-29 11:53 ` Andrey Ryabinin 2019-11-29 12:29 ` Daniel Axtens 2019-11-29 12:29 ` Daniel Axtens 2019-11-29 12:45 ` Dmitry Vyukov 2019-11-29 12:45 ` Dmitry Vyukov 2019-11-29 12:45 ` Dmitry Vyukov 2019-11-29 15:13 ` Dmitry Vyukov 2019-11-29 15:13 ` Dmitry Vyukov 2019-11-29 15:13 ` Dmitry Vyukov 2019-11-29 15:15 ` XFS check crash (WAS Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory) Qian Cai 2019-11-29 15:15 ` Qian Cai 2019-11-29 15:50 ` Daniel Axtens 2019-11-29 15:50 ` Daniel Axtens 2019-11-29 12:09 ` Daniel Axtens [this message] 2019-11-29 12:09 ` [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory Daniel Axtens 2019-11-29 12:15 ` Dmitry Vyukov 2019-11-29 12:15 ` Dmitry Vyukov 2019-11-29 12:15 ` Dmitry Vyukov 2019-11-20 5:27 ` [PATCH] update to "kasan: support backing vmalloc space with real shadow memory" Daniel Axtens 2019-11-20 5:27 ` Daniel Axtens 2019-10-31 9:39 ` [PATCH v11 2/4] kasan: add test for vmalloc Daniel Axtens 2019-10-31 9:39 ` [PATCH v11 3/4] fork: support VMAP_STACK with KASAN_VMALLOC Daniel Axtens 2019-10-31 9:39 ` [PATCH v11 4/4] x86/kasan: support KASAN_VMALLOC Daniel Axtens 2019-11-08 22:36 ` [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory Andrey Ryabinin 2019-11-08 22:36 ` Andrey Ryabinin 2019-12-02 8:07 ` Christophe Leroy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=874kymg9zc.fsf@dja-thinkpad.axtens.net \ --to=dja@axtens.net \ --cc=aryabinin@virtuozzo.com \ --cc=cai@lca.pw \ --cc=christophe.leroy@c-s.fr \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=gor@linux.ibm.com \ --cc=kasan-dev@googlegroups.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.