Re: [PATCH 2/9] sparc32: flush the source user alias in copy_user_highpage()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] sparc32: stale kernel cache alias at vfrom in
  copy_user_highpage()
--

commit 698c37936dc073ff888986a9b12b4e12b07451f0
Author: Magnus Lindholm <linmag7@gmail.com>

sparc32: flush the source user alias in copy_user_highpage()

This commit implements copy_user_highpage() on sparc32 to flush the source
page's user cache alias before copying and flush the destination page via
its mapped kmap_local address.

> diff --git a/arch/sparc/mm/init_32.c b/arch/sparc/mm/init_32.c
> index 2f693b70dbd80..7b53ee9f061f3 100644
> --- a/arch/sparc/mm/init_32.c
> +++ b/arch/sparc/mm/init_32.c
> @@ -103,6 +103,29 @@ void sparc_flush_page_to_ram(struct page *page)
>  }
>  EXPORT_SYMBOL(sparc_flush_page_to_ram);
>  
> +/*
> + * The kernel reads the source page through a kmap alias, which on a
> + * virtually indexed cache lands in a different set than the user mapping
> + * userspace has been dirtying.  Flush that alias first, and flush the
> + * destination through the address actually written rather than
> + * page_address(), which is NULL for a highmem page.
> + */
> +void copy_user_highpage(struct page *to, struct page *from,
> +			unsigned long vaddr, struct vm_area_struct *vma)
> +{
> +	char *vfrom, *vto;
> +
> +	if (vma)
> +		flush_cache_page(vma, vaddr, page_to_pfn(from));
> +
> +	vfrom = kmap_local_page(from);
> +	vto = kmap_local_page(to);
> +	copy_page(vto, vfrom);
> +	__flush_page_to_ram((unsigned long)vto);
> +	kunmap_local(vto);
> +	kunmap_local(vfrom);
> +}

[Severity: Medium]
Can copy_page(vto, vfrom) leave or hit stale supervisor cache lines at
vfrom when from is a lowmem page on HyperSPARC?

For a lowmem page, kmap_local_page(from) returns page_address(from) and
kunmap_local(vfrom) returns early without flushing because vfrom is
outside the fixmap kmap range.  Reading vfrom in copy_page() populates
clean supervisor-tagged cache lines at page_address(from).

If the remaining process later reuses from via wp_page_reuse(), writes to
vaddr at a different cache colour, and forks again, neither
hypersparc_flush_cache_mm() (which uses ASI_M_FLUSH_USER) nor
hypersparc_flush_cache_page(vma, vaddr, ...) (which flushes only the user
virtual address vaddr) invalidates the supervisor lines at vfrom.  The
second copy_page(vto, vfrom) will then read stale cached data from vfrom
instead of the updated lines written back from vaddr to RAM.

Flushing vfrom with __flush_page_to_ram((unsigned long)vfrom) as well
would evict the kernel alias.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261108223516.1125534-1-linmag7@gmail.com?part=2