[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3519195a98428998160d272997a3d2ed6c53c6a.1755004923.git.maciej.wieczor-retman@intel.com>
Date: Tue, 12 Aug 2025 15:23:52 +0200
From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
To: nathan@...nel.org,
arnd@...db.de,
broonie@...nel.org,
Liam.Howlett@...cle.com,
urezki@...il.com,
will@...nel.org,
kaleshsingh@...gle.com,
rppt@...nel.org,
leitao@...ian.org,
coxu@...hat.com,
surenb@...gle.com,
akpm@...ux-foundation.org,
luto@...nel.org,
jpoimboe@...nel.org,
changyuanl@...gle.com,
hpa@...or.com,
dvyukov@...gle.com,
kas@...nel.org,
corbet@....net,
vincenzo.frascino@....com,
smostafa@...gle.com,
nick.desaulniers+lkml@...il.com,
morbo@...gle.com,
andreyknvl@...il.com,
alexander.shishkin@...ux.intel.com,
thiago.bauermann@...aro.org,
catalin.marinas@....com,
ryabinin.a.a@...il.com,
jan.kiszka@...mens.com,
jbohac@...e.cz,
dan.j.williams@...el.com,
joel.granados@...nel.org,
baohua@...nel.org,
kevin.brodsky@....com,
nicolas.schier@...ux.dev,
pcc@...gle.com,
andriy.shevchenko@...ux.intel.com,
wei.liu@...nel.org,
bp@...en8.de,
ada.coupriediaz@....com,
xin@...or.com,
pankaj.gupta@....com,
vbabka@...e.cz,
glider@...gle.com,
jgross@...e.com,
kees@...nel.org,
jhubbard@...dia.com,
joey.gouly@....com,
ardb@...nel.org,
thuth@...hat.com,
pasha.tatashin@...een.com,
kristina.martsenko@....com,
bigeasy@...utronix.de,
maciej.wieczor-retman@...el.com,
lorenzo.stoakes@...cle.com,
jason.andryuk@....com,
david@...hat.com,
graf@...zon.com,
wangkefeng.wang@...wei.com,
ziy@...dia.com,
mark.rutland@....com,
dave.hansen@...ux.intel.com,
samuel.holland@...ive.com,
kbingham@...nel.org,
trintaeoitogc@...il.com,
scott@...amperecomputing.com,
justinstitt@...gle.com,
kuan-ying.lee@...onical.com,
maz@...nel.org,
tglx@...utronix.de,
samitolvanen@...gle.com,
mhocko@...e.com,
nunodasneves@...ux.microsoft.com,
brgerst@...il.com,
willy@...radead.org,
ubizjak@...il.com,
peterz@...radead.org,
mingo@...hat.com,
sohil.mehta@...el.com
Cc: linux-mm@...ck.org,
linux-kbuild@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
x86@...nel.org,
llvm@...ts.linux.dev,
kasan-dev@...glegroups.com,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [PATCH v4 16/18] mm: Unpoison pcpu chunks with base address tag
The problem presented here is related to NUMA systems and tag-based
KASAN mode. It can be explained in the following points:
1. There can be more than one virtual memory chunk.
2. Chunk's base address has a tag.
3. The base address points at the first chunk and thus inherits
the tag of the first chunk.
4. The subsequent chunks will be accessed with the tag from the
first chunk.
5. Thus, the subsequent chunks need to have their tag set to
match that of the first chunk.
Refactor code by moving it into a helper in preparation for the actual
fix.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
---
Changelog v4:
- Redo the patch message numbered list.
- Do the refactoring in this patch and move additions to the next new
one.
Changelog v3:
- Remove last version of this patch that just resets the tag on
base_addr and add this patch that unpoisons all areas with the same
tag instead.
include/linux/kasan.h | 10 ++++++++++
mm/kasan/hw_tags.c | 11 +++++++++++
mm/kasan/shadow.c | 10 ++++++++++
mm/vmalloc.c | 4 +---
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 7a2527794549..3ec432d7df9a 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -613,6 +613,13 @@ static __always_inline void kasan_poison_vmalloc(const void *start,
__kasan_poison_vmalloc(start, size);
}
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms);
+static __always_inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
+{
+ if (kasan_enabled())
+ __kasan_unpoison_vmap_areas(vms, nr_vms);
+}
+
#else /* CONFIG_KASAN_VMALLOC */
static inline void kasan_populate_early_vm_area_shadow(void *start,
@@ -637,6 +644,9 @@ static inline void *kasan_unpoison_vmalloc(const void *start,
static inline void kasan_poison_vmalloc(const void *start, unsigned long size)
{ }
+static inline void kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
+{ }
+
#endif /* CONFIG_KASAN_VMALLOC */
#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
index 9a6927394b54..1f569df313c3 100644
--- a/mm/kasan/hw_tags.c
+++ b/mm/kasan/hw_tags.c
@@ -382,6 +382,17 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size)
*/
}
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
+{
+ int area;
+
+ for (area = 0 ; area < nr_vms ; area++) {
+ vms[area]->addr = __kasan_unpoison_vmalloc(
+ vms[area]->addr, vms[area]->size,
+ KASAN_VMALLOC_PROT_NORMAL);
+ }
+}
+
#endif
void kasan_enable_hw_tags(void)
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index d2c70cd2afb1..b41f74d68916 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -646,6 +646,16 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size)
kasan_poison(start, size, KASAN_VMALLOC_INVALID, false);
}
+void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms)
+{
+ int area;
+
+ for (area = 0 ; area < nr_vms ; area++) {
+ kasan_poison(vms[area]->addr, vms[area]->size,
+ arch_kasan_get_tag(vms[area]->addr), false);
+ }
+}
+
#else /* CONFIG_KASAN_VMALLOC */
int kasan_alloc_module_shadow(void *addr, size_t size, gfp_t gfp_mask)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 83d666e4837a..72eecc8b087a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4847,9 +4847,7 @@ struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
* With hardware tag-based KASAN, marking is skipped for
* non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
*/
- for (area = 0; area < nr_vms; area++)
- vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr,
- vms[area]->size, KASAN_VMALLOC_PROT_NORMAL);
+ kasan_unpoison_vmap_areas(vms, nr_vms);
kfree(vas);
return vms;
--
2.50.1
Powered by blists - more mailing lists