From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC7AB394797 for ; Thu, 21 May 2026 07:05:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779347135; cv=none; b=T4VdaMezwGfVHCNqPALNcFCPmF55MVzxLs8Tez0f5Cb9tWjfXMmcZl0o72l+mE+2JneRHzRlZ7G2txViTD+pqFBPruZ/zzmD1SdvQQZ4RU+hOKM01lQ2Aq4YIOfAZBmxIOB2TGQOIJBmnNY9O82MvyW7rTBSXKeoBu3AEY1Gjsk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779347135; c=relaxed/simple; bh=GeXk8DUM2yhN4N2heZ5zvWemVUB1gX53UnUMAZOFBcA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OR+52WZ1EnoPrM9jtrO6fs47t2kA6/xw7Ie4b7SBLU+HhUTHfKj+yHOFJLtgkk70FH9hSuKhqG77QQfkFp7eJx197ZvBG5yz+gFNuqrm7QW3xRcv0T0VsV1iP4VeGF8D6COix+DgcC95NI1xHDNG8laQpXlI2HPrLaDYwY7y7jU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Y+CXmDSx; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Y+CXmDSx" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1779347123; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=xH7qKoIs4z2pm0gBGG10i9tuQP6jlkYOOctvFgABV28=; b=Y+CXmDSxVQH60MWfBgourX2z9ORAmLMa2/qAilhD6/yJIvqLlEESN8avI6AHEfZQvojB+hrAl+3FxRUdiElY4z2j7fymrBEZEGuovan/KS1RL2Ie7BHJZt/arHMbuo0V/2ttg6laL71TLAT6QIzwrX+3wed2GrO1XBViOhDk8t4= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R211e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0X3L5YXe_1779347122; Received: from 30.74.144.124(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X3L5YXe_1779347122 cluster:ay36) by smtp.aliyun-inc.com; Thu, 21 May 2026 15:05:22 +0800 Message-ID: Date: Thu, 21 May 2026 15:05:21 +0800 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 RFC v2] mm/shmem: set __GFP_SKIP_KASAN for swap_cluster_readahead To: Chia-I Wu Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Hugh Dickins , Kairui Song , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Boris Brezillon References: <20260519-panthor-kasan-v2-1-b7384458f076@gmail.com> <72bec63c-09f2-4a97-908d-3e6af8e3e0ae@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/21/26 1:06 AM, Chia-I Wu wrote: > On Wed, May 20, 2026 at 3:04 AM Baolin Wang > wrote: >> >> CC Kairui, >> >> On 5/20/26 12:31 PM, Chia-I Wu via B4 Relay wrote: >>> From: Chia-I Wu >>> >>> swap_cluster_readahead can allocate folios for other mappings. If the >>> gfp flags do not have __GFP_SKIP_KASAN, but the other mappings have >>> PROT_MTE, we can end up with false KASAN errors such as >>> >>> BUG: KASAN: invalid-access in swap_writepage+0xb0/0x21c >>> Read at addr f5ffff81aa71dff8 by task WM.task-4/6956 >>> Pointer tag: [f5], memory tag: [f9] >>> >>> In the above example, because __GFP_SKIP_KASAN was missing, KASAN set >>> both pointer tag and memory tag to 0xf5 when swap_cluster_readahead >>> allocated the folio. But the userspace had already set the memory tag to >>> 0xf9 before swapped out. arch_swap_restore restored the memory tag back >>> to 0xf9, leading to the mismatch. >>> >>> Signed-off-by: Chia-I Wu >>> --- >>> Changes in v2: >>> - set __GFP_SKIP_KASAN for shmem instead of drm/panthor >>> - Link to v1: https://patch.msgid.link/20260512-panthor-kasan-v1-1-d8d3e275d71b@gmail.com >>> --- >>> mm/shmem.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/mm/shmem.c b/mm/shmem.c >>> index 3b5dc21b323c2..db9130a8c5b76 100644 >>> --- a/mm/shmem.c >>> +++ b/mm/shmem.c >>> @@ -1784,6 +1784,11 @@ static struct folio *shmem_swapin_cluster(swp_entry_t swap, gfp_t gfp, >>> pgoff_t ilx; >>> struct folio *folio; >>> >>> + /* swap_cluster_readahead might cross the mapping boundary and >>> + * allocate pages for other mappings. We have to skip KASAN. >>> + */ >>> + gfp |= __GFP_SKIP_KASAN; >>> + >>> mpol = shmem_get_pgoff_policy(info, index, 0, &ilx); >>> folio = swap_cluster_readahead(swap, gfp, mpol, ilx); >>> mpol_cond_put(mpol); >> >> If we force __GFP_SKIP_KASAN, would this cause issues for mappings that >> explicitly should NOT have the flag? and your v1 link already mentions >> this scenario. > We lose the benefits of kasan hw tags (other modes are not affected) > by forcing the flag. > > The other mappings swap_cluster_readahead can affect are anon > mappings, regular shmem mappings, or gpu shmem mappings. I think only > gpu shmem mappings miss __GFP_SKIP_KASAN. That might not even be > intentional, because gpu shmem mappings pick GFP_HIGHUSER over > GFP_HIGHUSER_MOVABLE to avoid __GFP_MOVABLE. That was before > __GFP_SKIP_KASAN was added to GFP_HIGHUSER_MOVABLE. It sounds like the right approach would be to explicitly set __GFP_SKIP_KASAN for GPU shmem mappings, no? I think having users explicitly set __GFP_SKIP_KASAN makes the implications clearer than having shmem core set it implicitly. We could also consider adding a VM_WARN in shmem_swapin_cluster() to detect any mappings missing the __GFP_SKIP_KASAN flag. > I guess what I am trying to say is these are all user pages. We have > to skip kasan when user pages can be mapped PROT_MTE. The Yes, regular shmem mappings typically default to GFP_HIGHUSER_MOVABLE, while GPU shmem mappings are a special case. > justification for gpu shmem mappings is that they cannot be mapped > PROT_MTE. But if readahead can affect non-gpu shmem mappings, it seems > we have to either force __GFP_SKIP_KASAN or to cap/disable readahead.