On 4/12/2024 12:48 PM, Matthew Wilcox wrote:
On Thu, Apr 11, 2024 at 05:00:33PM +0800, Miaohe Lin wrote:
But as code changes, the above page lock shift is gone. And I think below logic can't
trigger now. As we hold extra page refcnt so page can't be coallesced into a new THP or Slab page.
/*
* We're only intended to deal with the non-Compound page here.
* However, the page could have changed compound pages due to
* race window. If this happens, we could try again to hopefully
* handle the page next round.
*/
if (PageCompound(p)) {
if (retry) {
ClearPageHWPoison(p);
unlock_page(p);
put_page(p);
flags &= ~MF_COUNT_INCREASED;
retry = false;
goto try_again;
}
res = action_result(pfn, MF_MSG_DIFFERENT_COMPOUND, MF_IGNORED);
goto unlock_page;
}
So it might be better to replace above code block as WARN_ON(PageCompound(p)) and remove MF_MSG_DIFFERENT_COMPOUND case.
Any thoughts?
Yes, I think you're right. As the MM handling of pages has evolved,
people haven't kept memory-failure uptodate. That's both understandable
and regrettable.
I don't have the time to focus on memory-failure myself; I have a couple
of hundred uses of page->mapping to eliminate. And I'd want to get a
lot more serious about testing before starting on that journey.
I do have ideas for handling hwpoison without splitting a folio.
I'd also really like to improve memory-failure to handle sub-page-size
blast radius (Intel CXL used to have a blast radius of 256 bytes).
But realistically, these things are never going to rise high enough on
my todo list to actually get done.
Yeah, glad to have the issue identified, that's progress.
I'm working on a series dealing with handling hwpoison without splitting
a THP, will post it for comments.
thanks,
-jane
