Skip to content
  • David Hildenbrand's avatar
    f665dede
    kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources · f665dede
    David Hildenbrand authored
    [ Upstream commit 3c9c7975 ]
    
    It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM |
    IORESOURCE_BUSY) only on the first level in the resource tree.  However,
    this is no longer holds for driver-managed system RAM (i.e., added via
    dax/kmem and virtio-mem), which gets added on lower levels, for example,
    inside device containers.
    
    IORESOURCE_SYSTEM_RAM is defined as IORESOURCE_MEM | IORESOURCE_SYSRAM and
    just a special type of IORESOURCE_MEM.
    
    The function walk_mem_res() only considers the first level and is used in
    arch/x86/mm/ioremap.c:__ioremap_check_mem() only.  We currently fail to
    identify System RAM added by dax/kmem and virtio-mem as
    "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such
    "normal RAM" in __ioremap_caller().
    
    Let's find all IORESOURCE_MEM | IORESOURCE_BUSY resources, making the
    function behave similar to walk_system_ram_res().
    
    Link: https://lkml.kernel.org/r/20210325115326.7826-3-david@redhat.com
    
    
    Fixes: ebf71552 ("virtio-mem: Add parent resource for all added "System RAM"")
    Fixes: c221c0b0 ("device-dax: "Hotplug" persistent memory for use like normal RAM")
    Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Keith Busch <keith.busch@intel.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
    f665dede
    kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources
    David Hildenbrand authored
    [ Upstream commit 3c9c7975 ]
    
    It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM |
    IORESOURCE_BUSY) only on the first level in the resource tree.  However,
    this is no longer holds for driver-managed system RAM (i.e., added via
    dax/kmem and virtio-mem), which gets added on lower levels, for example,
    inside device containers.
    
    IORESOURCE_SYSTEM_RAM is defined as IORESOURCE_MEM | IORESOURCE_SYSRAM and
    just a special type of IORESOURCE_MEM.
    
    The function walk_mem_res() only considers the first level and is used in
    arch/x86/mm/ioremap.c:__ioremap_check_mem() only.  We currently fail to
    identify System RAM added by dax/kmem and virtio-mem as
    "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such
    "normal RAM" in __ioremap_caller().
    
    Let's find all IORESOURCE_MEM | IORESOURCE_BUSY resources, making the
    function behave similar to walk_system_ram_res().
    
    Link: https://lkml.kernel.org/r/20210325115326.7826-3-david@redhat.com
    
    
    Fixes: ebf71552 ("virtio-mem: Add parent resource for all added "System RAM"")
    Fixes: c221c0b0 ("device-dax: "Hotplug" persistent memory for use like normal RAM")
    Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Keith Busch <keith.busch@intel.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Qian Cai <cai@lca.pw>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
Loading