linux-stable.git/kernel/resource.c, branch v5.11.22

kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources

2021-05-19T08:29:47+00:00

[ Upstream commit 3c9c797534364593b73ba6ab060a014af8934721 ]

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: ebf71552bb0e ("virtio-mem: Add parent resource for all added "System RAM"")
Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM")
Signed-off-by: David Hildenbrand 
Reviewed-by: Dan Williams 
Cc: Greg Kroah-Hartman 
Cc: Dan Williams 
Cc: Daniel Vetter 
Cc: Andy Shevchenko 
Cc: Mauro Carvalho Chehab 
Cc: Dave Young 
Cc: Baoquan He 
Cc: Vivek Goyal 
Cc: Dave Hansen 
Cc: Keith Busch 
Cc: Michal Hocko 
Cc: Qian Cai 
Cc: Oscar Salvador 
Cc: Eric Biederman 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Tom Lendacky 
Cc: Brijesh Singh 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources

2021-05-19T08:29:47+00:00

[ Upstream commit 97f61c8f44ec9020708b97a51188170add4f3084 ]

Patch series "kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree", v2.

Playing with kdump+virtio-mem I noticed that kexec_file_load() does not
consider System RAM added via dax/kmem and virtio-mem when preparing the
elf header for kdump.  Looking into the details, the logic used in
walk_system_ram_res() and walk_mem_res() seems to be outdated.

walk_system_ram_range() already does the right thing, let's change
walk_system_ram_res() and walk_mem_res(), and clean up.

Loading a kdump kernel via "kexec -p -s" ...  will result in the kdump
kernel to also dump dax/kmem and virtio-mem added System RAM now.

Note: kexec-tools on x86-64 also have to be updated to consider this
memory in the kexec_load() case when processing /proc/iomem.

This patch (of 3):

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.

We have two users of walk_system_ram_res(), which currently only
consideres the first level:

a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip
   IORESOURCE_SYSRAM_DRIVER_MANAGED resources via
   locate_mem_hole_callback(), so even after this change, we won't be
   placing kexec images onto dax/kmem and virtio-mem added memory.  No
   change.

b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently
   not adding relevant ranges to the crash elf header, resulting in them
   not getting dumped via kdump.

This change fixes loading a crashkernel via kexec_file_load() and
including dax/kmem and virtio-mem added System RAM in the crashdump on
x86-64.  Note that e.g,, arm64 relies on memblock data and, therefore,
always considers all added System RAM already.

Let's find all IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY resources, making
the function behave like walk_system_ram_range().

Link: https://lkml.kernel.org/r/20210325115326.7826-1-david@redhat.com
Link: https://lkml.kernel.org/r/20210325115326.7826-2-david@redhat.com
Fixes: ebf71552bb0e ("virtio-mem: Add parent resource for all added "System RAM"")
Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM")
Signed-off-by: David Hildenbrand 
Reviewed-by: Dan Williams 
Acked-by: Baoquan He 
Cc: Greg Kroah-Hartman 
Cc: Dan Williams 
Cc: Daniel Vetter 
Cc: Andy Shevchenko 
Cc: Mauro Carvalho Chehab 
Cc: Dave Young 
Cc: Baoquan He 
Cc: Vivek Goyal 
Cc: Dave Hansen 
Cc: Keith Busch 
Cc: Michal Hocko 
Cc: Qian Cai 
Cc: Oscar Salvador 
Cc: Eric Biederman 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Tom Lendacky 
Cc: Brijesh Singh 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

kernel/resource.c: fix kernel-doc markups

2020-12-16T06:46:18+00:00

Kernel-doc markups should use this format:
        identifier - description

While here, fix a kernel-doc tag that was using, instead,
a normal comment block.

[akpm@linux-foundation.org: coding style fixes]

Link: https://lkml.kernel.org/r/c5e38e1070f8dbe2f9607a10b44afe2875bd966c.1605521731.git.mchehab+huawei@kernel.org
Signed-off-by: Mauro Carvalho Chehab 
Cc: "Jonathan Corbet" 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

resource: Simplify region_intersects() by reducing conditionals

2020-11-17T17:06:28+00:00

Now we have for 'other' and 'type' variables

other	type	return
  0	  0	REGION_DISJOINT
  0	  x	REGION_INTERSECTS
  x	  0	REGION_DISJOINT
  x	  x	REGION_MIXED

Obviously it's easier to check 'type' for 0 first instead of
currently checked 'other'.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Hanjun Guo 
Tested-by: Hanjun Guo 
Signed-off-by: Rafael J. Wysocki

kernel/resource: make iomem_resource implicit in release_mem_region_adjustable()

2020-10-16T18:11:18+00:00

"mem" in the name already indicates the root, similar to
release_mem_region() and devm_request_mem_region().  Make it implicit.
The only single caller always passes iomem_resource, other parents are not
applicable.

Suggested-by: Wei Yang 
Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Wei Yang 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Ard Biesheuvel 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Link: https://lkml.kernel.org/r/20200916073041.10355-1-david@redhat.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System RAM resources

2020-10-16T18:11:18+00:00

Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.

This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space).  We really want to merge
added resources in this scenario where possible.

Let's provide a flag (MEMHP_MERGE_RESOURCE) to specify that a resource
either created within add_memory*() or passed via add_memory_resource()
shall be marked mergeable and merged with applicable siblings.

To implement that, we need a kernel/resource interface to mark selected
System RAM resources mergeable (IORESOURCE_SYSRAM_MERGEABLE) and trigger
merging.

Note: We really want to merge after the whole operation succeeded, not
directly when adding a resource to the resource tree (it would break
add_memory_resource() and require splitting resources again when the
operation failed - e.g., due to -ENOMEM).

Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Pankaj Gupta 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Ard Biesheuvel 
Cc: Thomas Gleixner 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Wei Liu 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Roger Pau Monné 
Cc: Julien Grall 
Cc: Baoquan He 
Cc: Wei Yang 
Cc: Anton Blanchard 
Cc: Benjamin Herrenschmidt 
Cc: Christian Borntraeger 
Cc: Dave Jiang 
Cc: Eric Biederman 
Cc: Greg Kroah-Hartman 
Cc: Heiko Carstens 
Cc: Jason Wang 
Cc: Len Brown 
Cc: Leonardo Bras 
Cc: Libor Pechacek 
Cc: Michael Ellerman 
Cc: "Michael S. Tsirkin" 
Cc: Nathan Lynch 
Cc: "Oliver O'Halloran" 
Cc: Paul Mackerras 
Cc: Pingfan Liu 
Cc: "Rafael J. Wysocki" 
Cc: Vasily Gorbik 
Cc: Vishal Verma 
Link: https://lkml.kernel.org/r/20200911103459.10306-6-david@redhat.com
Signed-off-by: Linus Torvalds

kernel/resource: make release_mem_region_adjustable() never fail

2020-10-16T18:11:17+00:00

Patch series "selective merging of system ram resources", v4.

Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.

This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space).  We really want to merge
added resources in this scenario where possible.

Resources are effectively stored in a list-based tree.  Having a lot of
resources not only wastes memory, it also makes traversing that tree more
expensive, and makes /proc/iomem explode in size (e.g., requiring
kexec-tools to manually merge resources when creating a kdump header.  The
current kexec-tools resource count limit does not allow for more than
~100GB of memory with a memory block size of 128MB on x86-64).

Let's allow to selectively merge system ram resources by specifying a new
flag for add_memory*().  Patch #5 contains a /proc/iomem example.  Only
tested with virtio-mem.

This patch (of 8):

Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected System RAM resources
- then, we'll trigger that case more often on memory hotunplug.

In general, this function is already unlikely to fail.  When we remove
memory, we free up quite a lot of metadata (memmap, page tables, memory
block device, etc.).  The only reason it could really fail would be when
injecting allocation errors.

All other error cases inside release_mem_region_adjustable() seem to be
sanity checks if the function would be abused in different context - let's
add WARN_ON_ONCE() in these cases so we can catch them.

[natechancellor@gmail.com: fix use of ternary condition in release_mem_region_adjustable]
  Link: https://lkml.kernel.org/r/20200922060748.2452056-1-natechancellor@gmail.com
  Link: https://github.com/ClangBuiltLinux/linux/issues/1159

Signed-off-by: David Hildenbrand 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Ard Biesheuvel 
Cc: Pankaj Gupta 
Cc: Baoquan He 
Cc: Wei Yang 
Cc: Anton Blanchard 
Cc: Benjamin Herrenschmidt 
Cc: Boris Ostrovsky 
Cc: Christian Borntraeger 
Cc: Dave Jiang 
Cc: Eric Biederman 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Heiko Carstens 
Cc: Jason Wang 
Cc: Juergen Gross 
Cc: Julien Grall 
Cc: "K. Y. Srinivasan" 
Cc: Len Brown 
Cc: Leonardo Bras 
Cc: Libor Pechacek 
Cc: Michael Ellerman 
Cc: "Michael S. Tsirkin" 
Cc: Nathan Lynch 
Cc: "Oliver O'Halloran" 
Cc: Paul Mackerras 
Cc: Pingfan Liu 
Cc: "Rafael J. Wysocki" 
Cc: Roger Pau Monn 
Cc: Stefano Stabellini 
Cc: Stephen Hemminger 
Cc: Thomas Gleixner 
Cc: Vasily Gorbik 
Cc: Vishal Verma 
Cc: Wei Liu 
Link: https://lkml.kernel.org/r/20200911103459.10306-2-david@redhat.com
Signed-off-by: Linus Torvalds

resource: report parent to walk_iomem_res_desc() callback

2020-10-14T01:38:27+00:00

In support of detecting whether a resource might have been been claimed,
report the parent to the walk_iomem_res_desc() callback.  For example, the
ACPI HMAT parser publishes "hmem" platform devices per target range.
However, if the HMAT is disabled / missing a fallback driver can attach
devices to the raw memory ranges as a fallback if it sees unclaimed /
orphan "Soft Reserved" resources in the resource tree.

Otherwise, find_next_iomem_res() returns a resource with garbage data from
the stack allocation in __walk_iomem_res_desc() for the res->parent field.

There are currently no users that expect ->child and ->sibling to be
valid, and the resource_lock would be needed to traverse them.  Use a
compound literal to implicitly zero initialize the fields that are not
being returned in addition to setting ->parent.

Signed-off-by: Dan Williams 
Signed-off-by: Andrew Morton 
Cc: Jason Gunthorpe 
Cc: Dave Hansen 
Cc: Wei Yang 
Cc: Tom Lendacky 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Benjamin Herrenschmidt 
Cc: Ben Skeggs 
Cc: Borislav Petkov 
Cc: Brice Goglin 
Cc: Catalin Marinas 
Cc: Daniel Vetter 
Cc: Dave Jiang 
Cc: David Airlie 
Cc: David Hildenbrand 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Ira Weiny 
Cc: Jeff Moyer 
Cc: Jia He 
Cc: Joao Martins 
Cc: Jonathan Cameron 
Cc: Michael Ellerman 
Cc: Mike Rapoport 
Cc: Paul Mackerras 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Thomas Gleixner 
Cc: Vishal Verma 
Cc: Will Deacon 
Cc: Ard Biesheuvel 
Cc: Bjorn Helgaas 
Cc: Boris Ostrovsky 
Cc: Hulk Robot 
Cc: Jason Yan 
Cc: "Jérôme Glisse" 
Cc: Juergen Gross 
Cc: kernel test robot 
Cc: Randy Dunlap 
Cc: Stefano Stabellini 
Cc: Vivek Goyal 
Link: https://lkml.kernel.org/r/159643097166.4062302.11875688887228572793.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Linus Torvalds

/dev/mem: Revoke mappings when a driver claims the region

2020-05-27T09:10:05+00:00

Close the hole of holding a mapping over kernel driver takeover event of
a given address range.

Commit 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
introduced CONFIG_IO_STRICT_DEVMEM with the goal of protecting the
kernel against scenarios where a /dev/mem user tramples memory that a
kernel driver owns. However, this protection only prevents *new* read(),
write() and mmap() requests. Established mappings prior to the driver
calling request_mem_region() are left alone.

Especially with persistent memory, and the core kernel metadata that is
stored there, there are plentiful scenarios for a /dev/mem user to
violate the expectations of the driver and cause amplified damage.

Teach request_mem_region() to find and shoot down active /dev/mem
mappings that it believes it has successfully claimed for the exclusive
use of the driver. Effectively a driver call to request_mem_region()
becomes a hole-punch on the /dev/mem device.

The typical usage of unmap_mapping_range() is part of
truncate_pagecache() to punch a hole in a file, but in this case the
implementation is only doing the "first half" of a hole punch. Namely it
is just evacuating current established mappings of the "hole", and it
relies on the fact that /dev/mem establishes mappings in terms of
absolute physical address offsets. Once existing mmap users are
invalidated they can attempt to re-establish the mapping, or attempt to
continue issuing read(2) / write(2) to the invalidated extent, but they
will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can
block those subsequent accesses.

Cc: Arnd Bergmann 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Matthew Wilcox 
Cc: Russell King 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Fixes: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Dan Williams 
Reviewed-by: Kees Cook 
Link: https://lore.kernel.org/r/159009507306.847224.8502634072429766747.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Greg Kroah-Hartman

mm/memory_hotplug.c: use PFN_UP / PFN_DOWN in walk_system_ram_range()

2019-09-24T22:54:09+00:00

Patch series "mm/memory_hotplug: online_pages() cleanups", v2.

Some cleanups (+ one fix for a special case) in the context of
online_pages().

This patch (of 5):

This makes it clearer that we will never call func() with duplicate PFNs
in case we have multiple sub-page memory resources.  All unaligned parts
of PFNs are completely discarded.

Link: http://lkml.kernel.org/r/20190814154109.3448-2-david@redhat.com
Signed-off-by: David Hildenbrand 
Acked-by: Michal Hocko 
Reviewed-by: Wei Yang 
Cc: Dan Williams 
Cc: Borislav Petkov 
Cc: Bjorn Helgaas 
Cc: Ingo Molnar 
Cc: Dave Hansen 
Cc: Nadav Amit 
Cc: Oscar Salvador 
Cc: Arun KS 
Cc: Pavel Tatashin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds