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

[Baolin Wang]

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