Re: [PATCH 0/3] kasan: hw_tags: some micro-optimizations

[Dev Jain <dev.jain@arm.com>]

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
>>
>