Dan Williams dan.j.williams@intel.com writes:
On Tue, Feb 12, 2019 at 1:37 PM Dan Williams dan.j.williams@intel.com wrote:
Lately Linux has encountered platforms that collide Persistent Memory regions between each other, specifically cases where ->start_pad needed to be non-zero. This lead to commit ae86cbfef381 "libnvdimm, pfn: Pad pfn namespaces relative to other regions". That commit allowed namespaces to be mapped with devm_memremap_pages(). However dax operations on those configurations currently fail if attempted within the ->start_pad range because pmem_device->data_offset was still relative to raw resource base not relative to the section aligned resource range mapped by devm_memremap_pages().
Luckily __bdev_dax_supported() caught these failures and simply disabled dax. However, to fix this situation a non-backwards compatible change needs to be made to the interpretation of the nd_pfn info-block. ->start_pad needs to be accounted in ->map.map_offset (formerly ->data_offset), and ->map.map_base (formerly ->phys_addr) needs to be adjusted to the section aligned resource base used to establish ->map.map formerly (formerly ->virt_addr).
See patch 7 "libnvdimm/pfn: Fix 'start_pad' implementation" for more details, and the ndctl patch series "Improve support + testing for labels + info-blocks" for the corresponding regression test.
Hello valued reviewers, can I plead for a sanity check of at least "libnvdimm/pfn: Introduce super-block minimum version requirements" and "libnvdimm/pfn: Fix 'start_pad' implementation"? In particular Jeff / Johannes this has end user / distro impact in that users may lose access to namespaces that are upgraded to v1.3 info-blocks and then boot an old kernel. I did not see a way around that sharp edge.
Yes, I'll take a look.
Cheers, Jeff