| Message ID | 20210322160200.19633-3-david@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree | expand |
On Mon, Mar 22, 2021 at 9:02 AM David Hildenbrand <david@redhat.com> wrote: > > It used to be true that we can have system RAM only on the first level > in the resourc tree. However, this is no longer holds for driver-managed > system RAM (i.e., dax/kmem and virtio-mem). > > The function walk_mem_res() only consideres 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 busy IORESOURCE_MEM resources, making the function > behave similar to walk_system_ram_res(). Looks good, Reviewed-by: Dan Williams <dan.j.williams@intel.com>
On Mon, Mar 22, 2021 at 05:01:59PM +0100, David Hildenbrand wrote: > It used to be true that we can have system RAM only on the first level > in the resourc tree. However, this is no longer holds for driver-managed > system RAM (i.e., dax/kmem and virtio-mem). > > The function walk_mem_res() only consideres 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(). Here I dunno, but consider to add Fixes tag if it fixes known bad behaviour. > Let's find all busy IORESOURCE_MEM resources, making the function > behave similar to walk_system_ram_res(). > > Cc: Andrew Morton <akpm@linux-foundation.org> > 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: Signed-off-by: David Hildenbrand <david@redhat.com> > 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> > Cc: x86@kernel.org > Cc: kexec@lists.infradead.org > Signed-off-by: David Hildenbrand <david@redhat.com> > --- > kernel/resource.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/resource.c b/kernel/resource.c > index 4efd6e912279..16e0c7e8ed24 100644 > --- a/kernel/resource.c > +++ b/kernel/resource.c > @@ -470,7 +470,7 @@ int walk_mem_res(u64 start, u64 end, void *arg, > { > unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY; > > - return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, true, > + return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, false, > arg, func); > } > > -- > 2.29.2 >
On 23.03.21 12:08, Andy Shevchenko wrote: > On Mon, Mar 22, 2021 at 05:01:59PM +0100, David Hildenbrand wrote: >> It used to be true that we can have system RAM only on the first level >> in the resourc tree. However, this is no longer holds for driver-managed >> system RAM (i.e., dax/kmem and virtio-mem). >> >> The function walk_mem_res() only consideres 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(). > > Here I dunno, but consider to add Fixes tag if it fixes known bad behaviour. Haven't observed it in the wild. We can add the same fixes tags as to patch #1.
diff --git a/kernel/resource.c b/kernel/resource.c index 4efd6e912279..16e0c7e8ed24 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -470,7 +470,7 @@ int walk_mem_res(u64 start, u64 end, void *arg, { unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY; - return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, true, + return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, false, arg, func); }
It used to be true that we can have system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., dax/kmem and virtio-mem). The function walk_mem_res() only consideres 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 busy IORESOURCE_MEM resources, making the function behave similar to walk_system_ram_res(). Cc: Andrew Morton <akpm@linux-foundation.org> 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: Signed-off-by: David Hildenbrand <david@redhat.com> 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> Cc: x86@kernel.org Cc: kexec@lists.infradead.org Signed-off-by: David Hildenbrand <david@redhat.com> --- kernel/resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)