• Roel Kluin's avatar
    mm: get_nid_for_pfn() returns int · 47504980
    Roel Kluin authored
    get_nid_for_pfn() returns int
    
    Presumably the (nid < 0) case has never happened.
    
    We do know that it is happening on one system while creating a symlink for
    a memory section so it should also happen on the same system if
    unregister_mem_sect_under_nodes() were called to remove the same symlink.
    
    The test was actually added in response to a problem with an earlier
    version reported by Yasunori Goto where one or more of the leading pages
    of a memory section on the 2nd node of one of his systems was
    uninitialized because I believe they coincided with a memory hole.
    
    That earlier version did not ignore uninitialized pages and determined
    the nid by considering only the 1st page of each memory section.  This
    caused the symlink to the 1st memory section on the 2nd node to be
    incorrectly created in /sys/devices/system/node/node0 instead of
    /sys/devices/system/node/node1.  The problem was fixed by adding the
    test to skip over uninitialized pages.
    
    I suspect we have not seen any reports of the non-removal
    of a symlink due to the incorrect declaration of the nid
    variable in unregister_mem_sect_under_nodes() because
      - systems where a memory section could have an uninitialized
        range of leading pages are probably rare.
      - memory remove is probably not done very frequently on the
        systems that are capable of demonstrating the problem.
      - lingering symlink(s) that should have been removed may
        have simply gone unnoticed.
    
    [garyhade@us.ibm.com: wrote changelog]
    Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
    Cc: Gary Hade <garyhade@us.ibm.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    47504980
node.c 12.5 KB