On Thu, Oct 14, 2021 at 10:36:44PM +0900, Naoya Horiguchi wrote: > Thanks for the good question, this could trigger WARN for unpoisoned pages. > The impact is limited because the caller of unpoison should know that that > happens in testing workload, but maybe there's no good reason to prevent > from it. So I'll drop this WARN_ON(). Sounds good, thanks. > > I had a feeling that when handling the page fault in do_swap_page before we > > SIGBUS the program, we should double-check the PageHWPoison on the pfn page, > > but I could be missing something.. > > The double-checking seems to allow processes to detect that the hwpoison page > is unpoisoned, some test programs could benefit from it. But maybe it could > be done independent of this patch. > > Personally, I only use unpoison in cleanup phase of each test case, > and each test case newly starts test processes, so reusing error pages > with unpoison can be avoided. I see. We don't have anything like soft-online a page, do we? I also don't know whether hwpoison can be used in any other form besides testing the hwpoison code path. E.g. logically it can be used to forbid accessing a physical page for any reason then recover using unhwpoison? Uffd has the SIGBUS mode that can do similar thing to the virtual address space, so any access to some page will generate a SIGBUS. While hwpoison is phsical address space based from that pov, and just like uffd it doesn't need to change vma layout which should be a good property unlike mprotect(). But I totally have no clue on all these... so it's just wild idea. Anyway, agreed on above, even if it's applicable it should be a separate patch. Thanks, -- Peter Xu
