On Thu, Jun 20, 2019 at 5:31 AM Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> wrote: > > Dan Williams <dan.j.willi...@intel.com> 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.st...@dwillia2-desk3.amr.corp.intel.com/ > > > You can add Tested-by: Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> > 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.ku...@linux.ibm.com > > 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.