From: Harry Yoo <harry.yoo@oracle.com>
To: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Daniel Axtens <dja@axtens.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kasan-dev@googlegroups.com, linux-s390@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v9 1/1] kasan: Avoid sleepable page allocation from atomic context
Date: Sat, 17 May 2025 20:18:55 +0900 [thread overview]
Message-ID: <aChwn4mmYMdMSuEt@harry> (raw)
In-Reply-To: <c61d3560297c93ed044f0b1af085610353a06a58.1747316918.git.agordeev@linux.ibm.com>
On Thu, May 15, 2025 at 03:55:38PM +0200, Alexander Gordeev wrote:
> apply_to_pte_range() enters the lazy MMU mode and then invokes
> kasan_populate_vmalloc_pte() callback on each page table walk
> iteration. However, the callback can go into sleep when trying
> to allocate a single page, e.g. if an architecutre disables
> preemption on lazy MMU mode enter.
>
> On s390 if make arch_enter_lazy_mmu_mode() -> preempt_enable()
> and arch_leave_lazy_mmu_mode() -> preempt_disable(), such crash
> occurs:
>
> [ 0.663336] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321
> [ 0.663348] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
> [ 0.663358] preempt_count: 1, expected: 0
> [ 0.663366] RCU nest depth: 0, expected: 0
> [ 0.663375] no locks held by kthreadd/2.
> [ 0.663383] Preemption disabled at:
> [ 0.663386] [<0002f3284cbb4eda>] apply_to_pte_range+0xfa/0x4a0
> [ 0.663405] CPU: 0 UID: 0 PID: 2 Comm: kthreadd Not tainted 6.15.0-rc5-gcc-kasan-00043-gd76bb1ebb558-dirty #162 PREEMPT
> [ 0.663408] Hardware name: IBM 3931 A01 701 (KVM/Linux)
> [ 0.663409] Call Trace:
> [ 0.663410] [<0002f3284c385f58>] dump_stack_lvl+0xe8/0x140
> [ 0.663413] [<0002f3284c507b9e>] __might_resched+0x66e/0x700
> [ 0.663415] [<0002f3284cc4f6c0>] __alloc_frozen_pages_noprof+0x370/0x4b0
> [ 0.663419] [<0002f3284ccc73c0>] alloc_pages_mpol+0x1a0/0x4a0
> [ 0.663421] [<0002f3284ccc8518>] alloc_frozen_pages_noprof+0x88/0xc0
> [ 0.663424] [<0002f3284ccc8572>] alloc_pages_noprof+0x22/0x120
> [ 0.663427] [<0002f3284cc341ac>] get_free_pages_noprof+0x2c/0xc0
> [ 0.663429] [<0002f3284cceba70>] kasan_populate_vmalloc_pte+0x50/0x120
> [ 0.663433] [<0002f3284cbb4ef8>] apply_to_pte_range+0x118/0x4a0
> [ 0.663435] [<0002f3284cbc7c14>] apply_to_pmd_range+0x194/0x3e0
> [ 0.663437] [<0002f3284cbc99be>] __apply_to_page_range+0x2fe/0x7a0
> [ 0.663440] [<0002f3284cbc9e88>] apply_to_page_range+0x28/0x40
> [ 0.663442] [<0002f3284ccebf12>] kasan_populate_vmalloc+0x82/0xa0
> [ 0.663445] [<0002f3284cc1578c>] alloc_vmap_area+0x34c/0xc10
> [ 0.663448] [<0002f3284cc1c2a6>] __get_vm_area_node+0x186/0x2a0
> [ 0.663451] [<0002f3284cc1e696>] __vmalloc_node_range_noprof+0x116/0x310
> [ 0.663454] [<0002f3284cc1d950>] __vmalloc_node_noprof+0xd0/0x110
> [ 0.663457] [<0002f3284c454b88>] alloc_thread_stack_node+0xf8/0x330
> [ 0.663460] [<0002f3284c458d56>] dup_task_struct+0x66/0x4d0
> [ 0.663463] [<0002f3284c45be90>] copy_process+0x280/0x4b90
> [ 0.663465] [<0002f3284c460940>] kernel_clone+0xd0/0x4b0
> [ 0.663467] [<0002f3284c46115e>] kernel_thread+0xbe/0xe0
> [ 0.663469] [<0002f3284c4e440e>] kthreadd+0x50e/0x7f0
> [ 0.663472] [<0002f3284c38c04a>] __ret_from_fork+0x8a/0xf0
> [ 0.663475] [<0002f3284ed57ff2>] ret_from_fork+0xa/0x38
>
> Instead of allocating single pages per-PTE, bulk-allocate the
> shadow memory prior to applying kasan_populate_vmalloc_pte()
> callback on a page range.
>
> Suggested-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: stable@vger.kernel.org
> Fixes: 3c5c3cfb9ef4 ("kasan: support backing vmalloc space with real shadow memory")
> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
> ---
V9 of this patch looks good to me,
Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
--
Cheers,
Harry / Hyeonggon
prev parent reply other threads:[~2025-05-17 11:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 13:55 [PATCH v9 0/1] kasan: Avoid sleepable page allocation from atomic context Alexander Gordeev
2025-05-15 13:55 ` [PATCH v9 1/1] " Alexander Gordeev
2025-05-17 11:18 ` Harry Yoo [this message]
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=aChwn4mmYMdMSuEt@harry \
--to=harry.yoo@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dja@axtens.net \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=stable@vger.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: link
Be 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.