From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Lorenzo Stoakes <lstoakes@gmail.com>,
<kasan-dev@googlegroups.com>, <linux-mm@kvack.org>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: [PATCH -rfc 3/3] mm: kasan: shadow: HACK: add cond_resched_lock() in kasan_depopulate_vmalloc_pte()
Date: Wed, 6 Sep 2023 20:42:34 +0800 [thread overview]
Message-ID: <20230906124234.134200-4-wangkefeng.wang@huawei.com> (raw)
In-Reply-To: <20230906124234.134200-1-wangkefeng.wang@huawei.com>
There is a similar softlockup issue with large size in kasan_release_vmalloc(),
watchdog: BUG: soft lockup - CPU#6 stuck for 48s! [kworker/6:1:59]
_raw_spin_unlock_irqrestore+0x50/0xb8
free_pcppages_bulk+0x2bc/0x3e0
free_unref_page_commit+0x1fc/0x290
free_unref_page+0x184/0x250
__free_pages+0x154/0x1a0
free_pages+0x88/0xb0
kasan_depopulate_vmalloc_pte+0x58/0x80
__apply_to_page_range+0x3ec/0x650
apply_to_existing_page_range+0x1c/0x30
kasan_release_vmalloc+0xa4/0x118
__purge_vmap_area_lazy+0x4f4/0xe30
drain_vmap_area_work+0x60/0xc0
process_one_work+0x4cc/0xa38
worker_thread+0x240/0x638
kthread+0x1c8/0x1e0
ret_from_fork+0x10/0x20
But it is could be fixed by adding a cond_resched_lock(), but see comment
about kasan_release_vmalloc(), free_vmap_area_lock is to protect the
concurrency, so it looks risky, any advise to fix this issue?
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
include/linux/kasan.h | 9 ++++++---
mm/kasan/shadow.c | 9 ++++++---
mm/vmalloc.c | 7 ++++---
3 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 3df5499f7936..6d85715c47ad 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -385,7 +385,8 @@ void kasan_populate_early_vm_area_shadow(void *start, unsigned long size);
int kasan_populate_vmalloc(unsigned long addr, unsigned long size);
void kasan_release_vmalloc(unsigned long start, unsigned long end,
unsigned long free_region_start,
- unsigned long free_region_end);
+ unsigned long free_region_end,
+ void *lock);
#else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
@@ -400,7 +401,8 @@ static inline int kasan_populate_vmalloc(unsigned long start,
static inline void kasan_release_vmalloc(unsigned long start,
unsigned long end,
unsigned long free_region_start,
- unsigned long free_region_end) { }
+ unsigned long free_region_end,
+ void *lock) { }
#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
@@ -435,7 +437,8 @@ static inline int kasan_populate_vmalloc(unsigned long start,
static inline void kasan_release_vmalloc(unsigned long start,
unsigned long end,
unsigned long free_region_start,
- unsigned long free_region_end) { }
+ unsigned long free_region_end,
+ void *lock) { }
static inline void *kasan_unpoison_vmalloc(const void *start,
unsigned long size,
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index d7d6724da2e0..4bce98e2b30d 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -416,12 +416,14 @@ int kasan_populate_vmalloc(unsigned long addr, unsigned long size)
}
static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
- void *unused)
+ void *lock)
{
unsigned long page;
page = (unsigned long)__va(pte_pfn(ptep_get(ptep)) << PAGE_SHIFT);
+ cond_resched_lock(lock);
+
spin_lock(&init_mm.page_table_lock);
if (likely(!pte_none(ptep_get(ptep))))
pte_clear(&init_mm, addr, ptep);
@@ -511,7 +513,8 @@ static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
*/
void kasan_release_vmalloc(unsigned long start, unsigned long end,
unsigned long free_region_start,
- unsigned long free_region_end)
+ unsigned long free_region_end,
+ void *lock)
{
void *shadow_start, *shadow_end;
unsigned long region_start, region_end;
@@ -547,7 +550,7 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end,
apply_to_existing_page_range(&init_mm,
(unsigned long)shadow_start,
size, kasan_depopulate_vmalloc_pte,
- NULL);
+ lock);
flush_tlb_kernel_range((unsigned long)shadow_start,
(unsigned long)shadow_end);
}
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 228a4a5312f2..c40ea7d1b65e 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1768,7 +1768,8 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
if (is_vmalloc_or_module_addr((void *)orig_start))
kasan_release_vmalloc(orig_start, orig_end,
- va->va_start, va->va_end);
+ va->va_start, va->va_end,
+ &free_vmap_area_lock);
atomic_long_sub(nr, &vmap_lazy_nr);
num_purged_areas++;
@@ -4198,7 +4199,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
&free_vmap_area_list);
if (va)
kasan_release_vmalloc(orig_start, orig_end,
- va->va_start, va->va_end);
+ va->va_start, va->va_end, NULL);
vas[area] = NULL;
}
@@ -4248,7 +4249,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
&free_vmap_area_list);
if (va)
kasan_release_vmalloc(orig_start, orig_end,
- va->va_start, va->va_end);
+ va->va_start, va->va_end, &free_vmap_area_lock);
vas[area] = NULL;
kfree(vms[area]);
}
--
2.41.0
next prev parent reply other threads:[~2023-09-06 12:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 12:42 [PATCH -rfc 0/3] mm: kasan: fix softlock when populate or depopulate pte Kefeng Wang
2023-09-06 12:42 ` [PATCH -rfc 1/3] mm: kasan: shadow: add cond_resched() in kasan_populate_vmalloc_pte() Kefeng Wang
2023-09-06 12:42 ` [PATCH -rfc 2/3] mm: kasan: shadow: move free_page() out of page table lock Kefeng Wang
2023-09-06 12:42 ` Kefeng Wang [this message]
2023-09-13 8:48 ` [PATCH -rfc 3/3] mm: kasan: shadow: HACK: add cond_resched_lock() in kasan_depopulate_vmalloc_pte() kernel test robot
2023-09-13 11:21 ` Kefeng Wang
2023-09-15 0:58 ` [PATCH -rfc 0/3] mm: kasan: fix softlock when populate or depopulate pte Kefeng Wang
2023-10-18 14:16 ` Kefeng Wang
2023-10-18 16:37 ` Marco Elver
2023-10-19 1:40 ` Kefeng Wang
2023-10-19 6:17 ` Uladzislau Rezki
2023-10-19 7:26 ` Kefeng Wang
2023-10-19 8:53 ` Uladzislau Rezki
2023-10-19 9:47 ` Kefeng Wang
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=20230906124234.134200-4-wangkefeng.wang@huawei.com \
--to=wangkefeng.wang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hch@infradead.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=ryabinin.a.a@gmail.com \
--cc=urezki@gmail.com \
--cc=vincenzo.frascino@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox