Re: [PATCH v3] mm/highmem: refuse to copy hwpoisoned folios in the !copy_mc fallbacks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm/highmem: missing is_page_hwpoison() check in
  copy_mc_to_kernel branch
--

commit 5b18d6f721e579b691687c6c8c6355f1e1a00b17
Author: Yuanhe Shu <xiangzao@linux.alibaba.com>

mm/highmem: refuse to copy hwpoisoned folios in the !copy_mc fallbacks

This commit checks is_page_hwpoison(from) in the !copy_mc_to_kernel
fallback implementations of copy_mc_user_highpage() and copy_mc_highpage()
and returns PAGE_SIZE when the source page is marked hwpoisoned.

Link: https://lore.kernel.org/r/877bjowf9i.fsf@DESKTOP-5N7EMDA/

> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> index d7aac9de1c8a4..c3240f70471d5 100644
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -473,12 +473,18 @@ static inline int copy_mc_highpage(struct page *to, struct page *from)
>  static inline int copy_mc_user_highpage(struct page *to, struct page *from,
>  					unsigned long vaddr, struct vm_area_struct *vma)
>  {
> +	/* Don't touch data that is already marked poisoned. */
> +	if (is_page_hwpoison(from))
> +		return PAGE_SIZE;
>  	copy_user_highpage(to, from, vaddr, vma);
>  	return 0;
>  }
>  
>  static inline int copy_mc_highpage(struct page *to, struct page *from)
>  {
> +	/* Don't touch data that is already marked poisoned. */
> +	if (is_page_hwpoison(from))
> +		return PAGE_SIZE;
>  	copy_highpage(to, from);
>  	return 0;
>  }

[Severity: Medium]
Should the #ifdef copy_mc_to_kernel implementations of
copy_mc_user_highpage() and copy_mc_highpage() also check
is_page_hwpoison(from) before mapping and copying the source page?

copy_mc_to_kernel() only catches hardware exceptions raised during the
memory read and never inspects page flags.  On architectures that define
copy_mc_to_kernel, copying a page with PG_hwpoison already set while the
underlying memory remains readable (for example, an uncorrupted subpage of
a poisoned hugetlb folio, an asynchronous patrol-scrubber notification, or
on x86 when copy_mc_to_kernel() falls back to plain memcpy()) still
succeeds and returns 0, silently consuming the poison and leaving the
destination folio without PG_hwpoison.  When the source page does have
physical DRAM poison, reading it also triggers an avoidable kernel-mode
machine check and queues a redundant memory_failure_queue() work item.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110112641.1196786-1-xiangzao@linux.alibaba.com?part=1