On Thu, Sep 30, 2021 at 1:34 PM Borislav Petkov <[email protected]> wrote: > > On Thu, Sep 30, 2021 at 08:15:51PM +0000, Luck, Tony wrote: > > That may now be a confusing name for the page flag bit. Until the > > pmem/storage use case we just simply lost the whole page (back > > then set_mce_nospec() didn't take an argument, it just marked the > > whole page as "not present" in the kernel 1:1 map). > > > > So the meaning of HWPoison has subtly changed from "this whole > > page is poisoned" to "there is some poison in some/all[1] of this page" > > Is that that PMEM driver case Dan is talking about: "the owner of that > page, PMEM driver, knows how to navigate around that poison to maximize > data recovery flows."? > > IOW, even if the page is marked as poison, in the PMEM case the driver > can access those sub-page ranges to salvage data? And in the "normal" > case, we only deal with whole pages anyway because memory_failure() > will mark the whole page as poison and nothing will be able to access > sub-page ranges there to salvage data? > > Closer? >
Yes, that's a good way to think about it. The only way to avoid poison for page allocator pages is to just ditch the page. In the case of PMEM the driver can do this fine grained dance because it gets precise sub-page poison lists to consult and implements a non-mmap path to access the page contents.
