Re: [PATCH RFC v2] mm/shmem: set __GFP_SKIP_KASAN for swap_cluster_readahead

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 5/21/26 1:06 AM, Chia-I Wu wrote:
> On Wed, May 20, 2026 at 3:04 AM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>>
>> CC Kairui,
>>
>> On 5/20/26 12:31 PM, Chia-I Wu via B4 Relay wrote:
>>> From: Chia-I Wu <olvaffe@gmail.com>
>>>
>>> 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 <olvaffe@gmail.com>
>>> ---
>>> 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.