Patch 1 uses GFP_SKIP_KASAN to skip unpoisoning of a slab page in the page
allocator, since slab allocator itself poisons the slab page immediately.

Patch 2 and 3 remove wasted work while poisoning the tail end of the
vmalloc/slab allocation.

---
Based on 7.1-rc2.

Dev Jain (3):
  mm/slub: hw_tags: skip page-allocator unpoisoning on slab allocation
  kasan: avoid re-poisoning tag-based kmalloc redzones
  vmalloc: hw_tags: optimize vmalloc redzoning

 include/linux/kasan.h | 17 +++++++++----
 mm/kasan/common.c     | 55 +++++++++++++++++++++++++++++++++----------
 mm/kasan/hw_tags.c    | 13 ++++++----
 mm/page_alloc.c       |  2 +-
 mm/slub.c             | 22 ++++++++++++-----
 5 files changed, 79 insertions(+), 30 deletions(-)

-- 
2.43.0

I have a few questions...

Does the performance of KASAN_HW_TAGS matter?

Yes, the performance of Hardware Tag-Based KASAN matters because
it is meant to be used in production on mobile devices as it utilizes
cutting-edge (to me) hardware support instead of compiler
instrumentation.

Do you have data or are you planning to measure the performance
impact of this work?

On Wed, May 13, 2026 at 04:27:31PM +0530, Dev Jain wrote:
> Patch 1 uses GFP_SKIP_KASAN to skip unpoisoning of a slab page in the page
> allocator, since slab allocator itself poisons the slab page immediately.

If __GFP_SKIP_KASAN skips unpoisoning, why should the slab allocator
poison the whole page (kasan_poison_slab())? It's already poisoned.

> Patch 2 and 3 remove wasted work while poisoning the tail end of the
> vmalloc/slab allocation.

> ---
> Based on 7.1-rc2.
> 
> Dev Jain (3):
>   mm/slub: hw_tags: skip page-allocator unpoisoning on slab allocation
>   kasan: avoid re-poisoning tag-based kmalloc redzones
>   vmalloc: hw_tags: optimize vmalloc redzoning
> 
>  include/linux/kasan.h | 17 +++++++++----
>  mm/kasan/common.c     | 55 +++++++++++++++++++++++++++++++++----------
>  mm/kasan/hw_tags.c    | 13 ++++++----
>  mm/page_alloc.c       |  2 +-
>  mm/slub.c             | 22 ++++++++++++-----
>  5 files changed, 79 insertions(+), 30 deletions(-)
> 
> -- 
> 2.43.0
> 

-- 
Cheers,
Harry / Hyeonggon

On 14/05/26 3:26 pm, Harry Yoo (Oracle) wrote:
> I have a few questions...
> 
> Does the performance of KASAN_HW_TAGS matter?
> 
> Yes, the performance of Hardware Tag-Based KASAN matters because
> it is meant to be used in production on mobile devices as it utilizes
> cutting-edge (to me) hardware support instead of compiler
> instrumentation.
> 
> Do you have data or are you planning to measure the performance
> impact of this work?

I will get back on this.

> 
> On Wed, May 13, 2026 at 04:27:31PM +0530, Dev Jain wrote:
>> Patch 1 uses GFP_SKIP_KASAN to skip unpoisoning of a slab page in the page
>> allocator, since slab allocator itself poisons the slab page immediately.
> 
> If __GFP_SKIP_KASAN skips unpoisoning, why should the slab allocator
> poison the whole page (kasan_poison_slab())? It's already poisoned.

Nice observation! Although it may not always be the case that the slab
page is already poisoned. If should_skip_kasan_poison() in the buddy
code triggers, then a freed page is not poisoned.

But, the point of kasan_poison_slab() is still served without it -
an OOB for a slab object is still caught probabilistically because
the allocation has a random tag.
> 
>> Patch 2 and 3 remove wasted work while poisoning the tail end of the
>> vmalloc/slab allocation.
> 
>> ---
>> Based on 7.1-rc2.
>>
>> Dev Jain (3):
>>   mm/slub: hw_tags: skip page-allocator unpoisoning on slab allocation
>>   kasan: avoid re-poisoning tag-based kmalloc redzones
>>   vmalloc: hw_tags: optimize vmalloc redzoning
>>
>>  include/linux/kasan.h | 17 +++++++++----
>>  mm/kasan/common.c     | 55 +++++++++++++++++++++++++++++++++----------
>>  mm/kasan/hw_tags.c    | 13 ++++++----
>>  mm/page_alloc.c       |  2 +-
>>  mm/slub.c             | 22 ++++++++++++-----
>>  5 files changed, 79 insertions(+), 30 deletions(-)
>>
>> -- 
>> 2.43.0
>>
>