From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EC2BA3A8723 for ; Thu, 14 May 2026 10:23:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778754184; cv=none; b=Kd9CAgDR5nxR+YUk815o/Y1cmS96AlNRWT3WuS/NXt9/C8lMzXFvrootccFcFaIvUqYLhK4Sb6rHizNYjzRbH7NCT2z0ccRlRJuhkI5nAaeTObXGxDzJrhQ4/xFjmeZgrh4CBzSHuq7aW2HzteUPaVPULjxxT0SYD8L42q+hCgw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778754184; c=relaxed/simple; bh=jzWryjg+VuWmthERUhxtCVABBovPPSvPdO9zYRbLN9c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dsmQhAOMtUxAEA0/TF5AsATmWJbCJUoD5WwWO9fwMiest2F7EDTGnldr3vCaSFqtVM9tVDmmcW8E5TMcQ/PpzeVz9gzx2zOYlMUyJDxU7WrXLRd8crfBO0uyIccvymDo4gCM6H81B932b4tdU8VCH+QEEc1tOZHNIwgG2iJMi10= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=VaCIY3e1; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="VaCIY3e1" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 072061655; Thu, 14 May 2026 03:22:57 -0700 (PDT) Received: from [10.164.148.47] (MacBook-Pro.blr.arm.com [10.164.148.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B34D03F7B4; Thu, 14 May 2026 03:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778754182; bh=jzWryjg+VuWmthERUhxtCVABBovPPSvPdO9zYRbLN9c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VaCIY3e1mM/3lajYRe+4kEeATPJjHgU8XC8DGOZ/gGNs4k32VM9U6XL3g1QNFwMX7 aiE1mChsAlQuWiG6dtlqRE2QG1uwezLRN5eWNRz4nneCDgGMRgbFGO85Pk32T8U+pL 1qRkiXei4Y3UKQbNxNmYYSp43V/UdA6VLpVX9moM= Message-ID: <794cc60f-4d51-40e3-9e06-4848d05a0f07@arm.com> Date: Thu, 14 May 2026 15:52:43 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] kasan: hw_tags: some micro-optimizations To: "Harry Yoo (Oracle)" Cc: akpm@linux-foundation.org, vbabka@kernel.org, ryabinin.a.a@gmail.com, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, hao.li@linux.dev, cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, glider@google.com, andreyknvl@gmail.com, dvyukov@google.com, vincenzo.frascino@arm.com, kasan-dev@googlegroups.com, ryan.roberts@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com References: <20260513105734.3380544-1-dev.jain@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 >> >