On Mon, Jun 11, 2018 at 08:19:54AM -0700, Dan Williams wrote: > On Mon, Jun 11, 2018 at 7:56 AM, Michal Hocko <mho...@kernel.org> wrote: > > On Mon 11-06-18 07:44:39, Dan Williams wrote: > > [...] > >> I'm still trying to understand the next level of detail on where you > >> think the design should go next? Is it just the HWPoison page flag? > >> Are you concerned about supporting greater than PAGE_SIZE poison? > > > > I simply do not want to check for HWPoison at zillion of places and have > > each type of page to have some special handling which can get wrong very > > easily. I am not clear on details here, this is something for users of > > hwpoison to define what is the reasonable scenarios when the feature is > > useful and turn that into a feature list that can be actually turned > > into a design document. See the different from let's put some more on > > top approach... > > > > So you want me to pay the toll of writing a design document justifying > all the existing use cases of HWPoison before we fix the DAX bugs, and > the design document may or may not result in any substantive change to > these patches? > > Naoya or Andi, can you chime in here?
memory_failure() does 3 things: - unmapping the error page from processes using it, - isolating the error page with PageHWPoison, - logging/reporting. The unmapping part and the isolating part are quite page type dependent, so this seems to me hard to do them in generic manner (so supporting new page type always needs case specific new code.) But I agree that we can improve code and document to help developers add support for new page type. About documenting, the content of Documentation/vm/hwpoison.rst is not updated since 2009, so some update with design thing might be required. My current thought about update items are like this: - detailing general workflow, - adding some about soft offline, - guideline for developers to support new type of memory, (- and anything helpful/requested.) Making code more readable/self-descriptive is helpful, though I'm not clear now about how. Anyway I'll find time to work on this, while now I'm testing the dax support patches and fixing a bug I found recently. Thanks, Naoya Horiguchi _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
