Re: [PATCH v8 08/15] hugetlb: Use the has_hwpoisoned flag

On Tue, Aug 04, 2026 at 05:42:28PM +0100, Matthew Wilcox wrote:
> On Tue, Aug 04, 2026 at 12:28:06PM -0400, Gregory Price wrote:
> > Reviewed-by: Gregory Price (Meta) <[email protected]>
> 
> Thanks, will add.
> 
> > > -#if defined(CONFIG_MEMORY_FAILURE) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> > > +#if defined(CONFIG_MEMORY_FAILURE) && defined(CONFIG_LARGE_FOLIO)
> > >  /*
> > > - * PageHasHWPoisoned indicates that at least one subpage is hwpoisoned in the
> > > - * compound page.
> > > + * folio_has_hwpoisoned indicates that at least one page is hwpoisoned in the
> > > + * folio.  That page will usually also have the HWPoison flag set, but this
> > > + * is not possible for folios which have HVO (see memory-failure for the
> > > + * scheme used in that case).  You probably don't want to call this directly;
> > > + * use folio_has_hwpoisoned_page() instead.
> > >   *
> > >   * This flag is set by hwpoison handler.  Cleared by THP split or free page.
> > >   */
> > 
> > Had to google HVO, and didn't see HVO directly mentioned in
> > memory-failure.  Maybe worth expanding HVO to its actual definition and
> > a sentence on the quirk.
> 
> It is mentioned earlier in the same file:
> 
> include/linux/page-flags.h:      * Limit mask usage to HugeTLB vmemmap optimization (HVO) where it
>
> but that's not obvious when reading a patch.  I'll just expand it here:
> 
>  * The has_hwpoisoned flag indicates that at least one page is hwpoisoned
>  * in the folio.  That page will usually also have the HWPoison flag
>  * set, but this is not possible for folios which have HugeTLB vmemmap
>  * optimization (see hugetlb_update_hwpoison() for the scheme used
>  * in that case).  You probably don't want to call this directly; use
>  * folio_has_hwpoisoned_page() instead.
> 
> > Does "Hugepage Vmapmem Optimization" just report poison for the head and
> > we lose the sub-page poison information in general?
> 
> We only lose the sub-folio poison information if kmalloc fails in
> hugetlb_update_hwpoison().  In the happy case, we retain knowledge
> of which pages contain hwpoison (and later in this series, we actually
> expose that information instead of just pretending the whole folio is
> poisoned)
> 

Gotcha, thank you for the additional context.

~Gregory