On Thu 11-03-21 14:34:04, Muchun Song wrote:

On Wed, Mar 10, 2021 at 11:28 PM Michal Hocko [off-list ref] wrote:

quoted

On Mon 08-03-21 18:28:03, Muchun Song wrote:

quoted

Because we reuse the first tail vmemmap page frame and remap it
with read-only, we cannot set the PageHWPosion on some tail pages.
So we can use the head[4].private (There are at least 128 struct
page structures associated with the optimized HugeTLB page, so
using head[4].private is safe) to record the real error page index
and set the raw error page PageHWPoison later.

Can we have more poisoned tail pages? Also who does consume that index
and set the HWPoison on the proper tail page?

Good point. I look at the routine of memory failure closely.
If we do not clear the HWPoison of the head page, we cannot
poison another tail page.

So we should not set the destructor of the huge page from
HUGETLB_PAGE_DTOR to NULL_COMPOUND_DTOR
before calling alloc_huge_page_vmemmap(). In this case,
the below check of PageHuge() always returns true.

I need to fix this in the previous patch.

memory_failure()
    if (PageHuge(page))
        memory_failure_hugetlb()
            head = compound_head(page)
            if (TestSetPageHWPoison(head))
                return

I have to say that I am not fully familiar with hwpoisoning code
(especially after recent changes) but IIRC it does rely on hugetlb page
dissolving. With the new code this operation can fail which is a new
situation. Unless I am misunderstanding this can lead to a lost memory
failure operation on other tail pages.

Anyway the above answers the question why a single slot is sufficient so
it would be great to mention that in a changelog along with the caveat
that some pages might miss their poisoning.
-- 
Michal Hocko
SUSE Labs