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

[Chia-I Wu]

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.

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


>
> Additionally, I'm wondering if we could use shmem_should_replace_folio()
> to detect such cases where shmem is being prematurely swapped in with
> incorrect GFP flags (e.g.: __GFP_SKIP_KASAN), and then handle it through
> shmem_replace_folio()?
I don't know if we want to impose a copy for the benefits. More
importantly, this only helps shmem mappings but not anon mappings.