linux-toradex.git/drivers/acpi/acpi_memhotplug.c, branch v4.20

mm/memory_hotplug: make add_memory() take the device_hotplug_lock

2018-10-31T15:54:17+00:00

add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
	arch/powerpc/platforms/pseries/hotplug-memory.c
	drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.

In general, we should hold the device_hotplug_lock when adding memory to
synchronize against online/offline request (e.g.  from user space) - which
already resulted in lock inversions due to device_lock() and
mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory
hot-add deadlock").  add_memory()/add_memory_resource() will create memory
block devices, so this really feels like the right thing to do.

Holding the device_hotplug_lock makes sure that a memory block device
can really only be accessed (e.g. via .online/.state) from user space,
once the memory has been fully added to the system.

The lock is not held yet in
	drivers/xen/balloon.c
	arch/powerpc/platforms/powernv/memtrace.c
	drivers/s390/char/sclp_cmd.c
	drivers/hv/hv_balloon.c
So, let's either use the locked variants or take the lock.

Don't export add_memory_resource(), as it once was exported to be used by
XEN, which is never built as a module.  If somebody requires it, we also
have to export a locked variant (as device_hotplug_lock is never
exported).

Link: http://lkml.kernel.org/r/20180925091457.28651-3-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Rashmica Gupta 
Reviewed-by: Oscar Salvador 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Nathan Fontenot 
Cc: John Allen 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Joonsoo Kim 
Cc: Vlastimil Babka 
Cc: Mathieu Malaterre 
Cc: Pavel Tatashin 
Cc: YASUAKI ISHIMATSU 
Cc: Balbir Singh 
Cc: Haiyang Zhang 
Cc: Heiko Carstens 
Cc: Jonathan Corbet 
Cc: Kate Stewart 
Cc: "K. Y. Srinivasan" 
Cc: Martin Schwidefsky 
Cc: Michael Neuling 
Cc: Philippe Ombredanne 
Cc: Stephen Hemminger 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

2018-10-31T15:54:17+00:00

Patch series "mm: online/offline_pages called w.o. mem_hotplug_lock", v3.

Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock.  And there are other places where we call
device_online()/device_offline() without the device_hotplug_lock.

While e.g.
	echo "online" > /sys/devices/system/memory/memory9/state
is fine, e.g.
	echo 1 > /sys/devices/system/memory/memory9/online
Will not take the mem_hotplug_lock. However the device_lock() and
device_hotplug_lock.

E.g.  via memory_probe_store(), we can end up calling
add_memory()->online_pages() without the device_hotplug_lock.  So we can
have concurrent callers in online_pages().  We e.g.  touch in
online_pages() basically unprotected zone->present_pages then.

Looks like there is a longer history to that (see Patch #2 for details),
and fixing it to work the way it was intended is not really possible.  We
would e.g.  have to take the mem_hotplug_lock in device/base/core.c, which
sounds wrong.

Summary: We had a lock inversion on mem_hotplug_lock and device_lock().
More details can be found in patch 3 and patch 6.

I propose the general rules (documentation added in patch 6):

1. add_memory/add_memory_resource() must only be called with
   device_hotplug_lock.
2. remove_memory() must only be called with device_hotplug_lock. This is
   already documented and holds for all callers.
3. device_online()/device_offline() must only be called with
   device_hotplug_lock. This is already documented and true for now in core
   code. Other callers (related to memory hotplug) have to be fixed up.
4. mem_hotplug_lock is taken inside of add_memory/remove_memory/
   online_pages/offline_pages.

To me, this looks way cleaner than what we have right now (and easier to
verify).  And looking at the documentation of remove_memory, using
lock_device_hotplug also for add_memory() feels natural.

This patch (of 6):

remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported.  So let's provide a variant
that takes the lock and only export that one.

The lock is already held in
	arch/powerpc/platforms/pseries/hotplug-memory.c
	drivers/acpi/acpi_memhotplug.c
	arch/powerpc/platforms/powernv/memtrace.c

Apart from that, there are not other users in the tree.

Link: http://lkml.kernel.org/r/20180925091457.28651-2-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Rashmica Gupta 
Reviewed-by: Oscar Salvador 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Rashmica Gupta 
Cc: Michael Neuling 
Cc: Balbir Singh 
Cc: Nathan Fontenot 
Cc: John Allen 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Joonsoo Kim 
Cc: Vlastimil Babka 
Cc: Greg Kroah-Hartman 
Cc: YASUAKI ISHIMATSU 
Cc: Mathieu Malaterre 
Cc: Boris Ostrovsky 
Cc: Haiyang Zhang 
Cc: Heiko Carstens 
Cc: Jonathan Corbet 
Cc: Juergen Gross 
Cc: Kate Stewart 
Cc: "K. Y. Srinivasan" 
Cc: Martin Schwidefsky 
Cc: Philippe Ombredanne 
Cc: Stephen Hemminger 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ACPI: Remove FSF mailing addresses

2015-07-08T00:27:32+00:00

There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.

Signed-off-by: Jarkko Nikula 
Signed-off-by: Rafael J. Wysocki

ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

2015-01-26T15:09:56+00:00

struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts
just at different offsets. To unify the parsing functions, OSPMs like Linux
need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
extract the shared data.

This patch also synchronizes the structure changes to the Linux kernel.
The usages are searched by matching the following keywords:
1. acpi_resource_address
2. acpi_resource_extended_address
3. ACPI_RESOURCE_TYPE_ADDRESS
4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
And we found and fixed the usages in the following files:
 arch/ia64/kernel/acpi-ext.c
 arch/ia64/pci/pci.c
 arch/x86/pci/acpi.c
 arch/x86/pci/mmconfig-shared.c
 drivers/xen/xen-acpi-memhotplug.c
 drivers/acpi/acpi_memhotplug.c
 drivers/acpi/pci_root.c
 drivers/acpi/resource.c
 drivers/char/hpet.c
 drivers/pnp/pnpacpi/rsparser.c
 drivers/hv/vmbus_drv.c

Build tests are passed with defconfig/allnoconfig/allyesconfig and
defconfig+CONFIG_ACPI=n.

Original-by: Thomas Gleixner 
Original-by: Jiang Liu 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki

ACPI / scan: always register memory hotplug scan handler

2014-05-30T14:04:36+00:00

Prevent platform devices from being created for ACPI memory device
objects if CONFIG_ACPI_HOTPLUG_MEMORY is unset by compiling out the
memory hotplug scan handler's callbacks only in that case and still
compiling its device ID list in and registering the scan handler in
either case.

Also unset the memory hotplug scan handler's .attach() callback
if acpi_no_memhotplug is set, but still register the scan handler to
avoid creating platform devices for ACPI memory devices in that case
too.

This change is based on a prototype from Zhang Rui.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Mika Westerberg

ACPI / memhotplug: add parameter to disable memory hotplug

2014-01-16T00:43:49+00:00

When booting a kexec/kdump kernel on a system that has specific memory
hotplug regions the boot will fail with warnings like:

 swapper/0: page allocation failure: order:9, mode:0x84d0
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-65.el7.x86_64 #1
 Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
  0000000000000000 ffff8800341bd8c8 ffffffff815bcc67 ffff8800341bd950
  ffffffff8113b1a0 ffff880036339b00 0000000000000009 00000000000084d0
  ffff8800341bd950 ffffffff815b87ee 0000000000000000 0000000000000200
 Call Trace:
  [] dump_stack+0x19/0x1b
  [] warn_alloc_failed+0xf0/0x160
  [] ?  __alloc_pages_direct_compact+0xac/0x196
  [] __alloc_pages_nodemask+0x7ff/0xa00
  [] vmemmap_alloc_block+0x62/0xba
  [] vmemmap_alloc_block_buf+0x15/0x3b
  [] vmemmap_populate+0xb4/0x21b
  [] sparse_mem_map_populate+0x27/0x35
  [] sparse_add_one_section+0x7a/0x185
  [] __add_pages+0xaf/0x240
  [] arch_add_memory+0x59/0xd0
  [] add_memory+0xb9/0x1b0
  [] acpi_memory_device_add+0x18d/0x26d
  [] acpi_bus_device_attach+0x7d/0xcd
  [] acpi_ns_walk_namespace+0xc8/0x17f
  [] ? acpi_bus_type_and_status+0x90/0x90
  [] ? acpi_bus_type_and_status+0x90/0x90
  [] acpi_walk_namespace+0x95/0xc5
  [] acpi_bus_scan+0x8b/0x9d
  [] acpi_scan_init+0x63/0x160
  [] acpi_init+0x25d/0x2a6
  [] ? acpi_sleep_proc_init+0x2a/0x2a
  [] do_one_initcall+0xe2/0x190
  [] kernel_init_freeable+0x17c/0x207
  [] ? do_early_param+0x88/0x88
  [] ? rest_init+0x80/0x80
  [] kernel_init+0xe/0x180
  [] ret_from_fork+0x7c/0xb0
  [] ? rest_init+0x80/0x80
 Mem-Info:
 Node 0 DMA per-cpu:
 CPU    0: hi:    0, btch:   1 usd:   0
 Node 0 DMA32 per-cpu:
 CPU    0: hi:   42, btch:   7 usd:   0
 active_anon:0 inactive_anon:0 isolated_anon:0
  active_file:0 inactive_file:0 isolated_file:0
  unevictable:0 dirty:0 writeback:0 unstable:0
  free:872 slab_reclaimable:13 slab_unreclaimable:1880
  mapped:0 shmem:0 pagetables:0 bounce:0
  free_cma:0

because the system has run out of memory at boot time.  This occurs
because of the following sequence in the boot:

Main kernel boots and sets E820 map.  The second kernel is booted with a
map generated by the kdump service using memmap= and memmap=exactmap.
These parameters are added to the kernel parameters of the kexec/kdump
kernel.   The kexec/kdump kernel has limited memory resources so as not
to severely impact the main kernel.

The system then panics and the kdump/kexec kernel boots (which is a
completely new kernel boot).  During this boot ACPI is initialized and the
kernel (as can be seen above) traverses the ACPI namespace and finds an
entry for a memory device to be hotadded.

ie)

  [] __add_pages+0xaf/0x240
  [] arch_add_memory+0x59/0xd0
  [] add_memory+0xb9/0x1b0
  [] acpi_memory_device_add+0x18d/0x26d
  [] acpi_bus_device_attach+0x7d/0xcd
  [] acpi_ns_walk_namespace+0xc8/0x17f
  [] ? acpi_bus_type_and_status+0x90/0x90
  [] ? acpi_bus_type_and_status+0x90/0x90
  [] acpi_walk_namespace+0x95/0xc5
  [] acpi_bus_scan+0x8b/0x9d
  [] acpi_scan_init+0x63/0x160
  [] acpi_init+0x25d/0x2a6

At this point the kernel adds page table information and the the kexec/kdump
kernel runs out of memory.

This can also be reproduced by using the memmap=exactmap and mem=X
parameters on the main kernel and booting.

This patchset resolves the problem by adding a kernel parameter,
acpi_no_memhotplug, to disable ACPI memory hotplug.

Signed-off-by: Prarit Bhargava 
Acked-by: Vivek Goyal 
Acked-by: Toshi Kani 
Acked-by: David Rientjes 
Signed-off-by: Rafael J. Wysocki

ACPI / bind: Pass struct acpi_device pointer to acpi_bind_one()

2013-12-07T00:05:50+00:00

There is no reason to pass an ACPI handle to acpi_bind_one() instead
of a struct acpi_device pointer to the target device object, so
modify that function to take a struct acpi_device pointer as its
second argument and update all code depending on it accordingly.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Lan Tianyu  # for USB/ACPI

Merge branch 'acpi-hotplug'

2013-10-28T00:12:41+00:00

* acpi-hotplug:
  ACPI / memhotplug: Use defined marco METHOD_NAME__STA
  ACPI / hotplug: Use kobject_init_and_add() instead of _init() and _add()
  ACPI / hotplug: Don't set kobject parent pointer explicitly
  ACPI / hotplug: Set kobject name via kobject_add(), not kobject_set_name()
  hotplug, powerpc, x86: Remove cpu_hotplug_driver_lock()
  hotplug / x86: Disable ARCH_CPU_PROBE_RELEASE on x86
  hotplug / x86: Add hotplug lock to missing places
  hotplug / x86: Fix online state in cpu0 debug interface

ACPI / memhotplug: Use defined marco METHOD_NAME__STA

2013-10-10T00:32:33+00:00

We already have predefined marco for method name "_STA', so
using the marco instead of directly using the string.

Signed-off-by: Zhang Yanfei 
Signed-off-by: Rafael J. Wysocki

ACPI / mm: use NUMA_NO_NODE

2013-09-23T23:40:38+00:00

Use more appropriate NUMA_NO_NODE instead of -1

Signed-off-by: Jianguo Wu 
Acked-by: David Rientjes 
Signed-off-by: Rafael J. Wysocki