On Wed, May 3, 2017 at 9:09 AM, Kani, Toshimitsu <[email protected]> wrote: > On Wed, 2017-05-03 at 08:52 -0700, Dan Williams wrote: >> On Wed, May 3, 2017 at 8:31 AM, Toshi Kani <[email protected]> >> wrote: >> > This is a RFC patch for seeking suggestions. It adds support of >> > badblocks check in Device DAX by using region-level badblocks list. >> > This patch is only briefly tested. >> > >> > device_dax is a well-isolated self-contained module as it calls >> > alloc_dax() with dev_dax, which is private to device_dax. For >> > checking badblocks, it needs to call dax_pmem to check with >> > region-level badblocks. >> > >> > This patch attempts to keep device_dax self-contained. It adds >> > check_error() to dax_operations, and dax_check_error() as a stub >> > with *dev_dax and *dev pointers to convey it to dax_pmem. I am >> > wondering if this is the right direction, or we should change the >> > modularity to let dax_pmem call alloc_dax() with its dax_pmem (or >> > I completely missed something). >> >> The problem is that device-dax guarantees a given fault granularity. >> To make that guarantee we can't fallback from 1G or 2M mappings due >> to an error. We also can't reasonably go the other way and fail >> mappings that contain a badblock because that would change the blast >> radius of a media error to the fault size. > > Does it mean we expect users to have CPUs with MCE recovery for Device > DAX? Can we add an attributes like allow error-check & fall-back?
Yes, without MCE recovery device-dax mappings that consume errors will reboot. If an application needs the kernel protection it should be using filesystem-dax.
