On Thu, Jun 20, 2019 at 5:31 AM Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > Dan Williams <dan.j.williams@xxxxxxxxx> writes: > > > Changes since v9 [1]: > > - Fix multiple issues related to the fact that pfn_valid() has > > traditionally returned true for any pfn in an 'early' (onlined at > > boot) section regardless of whether that pfn represented 'System RAM'. > > Teach pfn_valid() to maintain its traditional behavior in the presence > > of subsections. Specifically, subsection precision for pfn_valid() is > > only considered for non-early / hot-plugged sections. (Qian) > > > > - Related to the first item introduce a SECTION_IS_EARLY > > (->section_mem_map flag) to remove the existing hacks for determining > > an early section by looking at whether the usemap was allocated from the > > slab. > > > > - Kill off the EEXIST hackery in __add_pages(). It breaks > > (arch_add_memory() false-positive) the detection of subsection > > collisions reported by section_activate(). It is also obviated by > > David's recent reworks to move the 'System RAM' request_region() earlier > > in the add_memory() sequence(). > > > > - Switch to an arch-independent / static subsection-size of 2MB. > > Otherwise, a per-arch subsection-size is a roadblock on the path to > > persistent memory namespace compatibility across archs. (Jeff) > > > > - Update the changelog for "libnvdimm/pfn: Fix fsdax-mode namespace > > info-block zero-fields" to clarify that the "Cc: stable" is only there > > as safety measure for a distro that decides to backport "libnvdimm/pfn: > > Stop padding pmem namespaces to section alignment", otherwise there is > > no known bug exposure in older kernels. (Andrew) > > > > - Drop some redundant subsection checks (Oscar) > > > > - Collect some reviewed-bys > > > > [1]: https://lore.kernel.org/lkml/155977186863.2443951.9036044808311959913.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > You can add Tested-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx> > for ppc64. Thank you! > BTW even after this series we have the kernel crash mentioned in the > below email on reconfigure. > > https://lore.kernel.org/linux-mm/20190514025354.9108-1-aneesh.kumar@xxxxxxxxxxxxx > > I guess we need to conclude how the reserve space struct page should be > initialized ? Yes, that issue is independent of the subsection changes. I'll take a closer look.
