linux-stable.git/mm/memory_hotplug.c, branch v5.7.7

mm/memory_hotplug.c: fix false softlockup during pfn range removal

2020-06-30T19:36:25+00:00

commit b7e3debdd0408c0dca5d4750371afa5003f792dc upstream.

When working with very large nodes, poisoning the struct pages (for which
there will be very many) can take a very long time.  If the system is
using voluntary preemptions, the software watchdog will not be able to
detect forward progress.  This patch addresses this issue by offering to
give up time like __remove_pages() does.  This behavior was introduced in
v5.6 with: commit d33695b16a9f ("mm/memory_hotplug: poison memmap in
remove_pfn_range_from_zone()")

Alternately, init_page_poison could do this cond_resched(), but it seems
to me that the caller of init_page_poison() is what actually knows whether
or not it should relax its own priority.

Based on Dan's notes, I think this is perfectly safe: commit f931ab479dd2
("mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}")

Aside from fixing the lockup, it is also a friendlier thing to do on lower
core systems that might wipe out large chunks of hotplug memory (probably
not a very common case).

Fixes this kind of splat:

  watchdog: BUG: soft lockup - CPU#46 stuck for 22s! [daxctl:9922]
  irq event stamp: 138450
  hardirqs last  enabled at (138449): [] trace_hardirqs_on_thunk+0x1a/0x1c
  hardirqs last disabled at (138450): [] trace_hardirqs_off_thunk+0x1a/0x1c
  softirqs last  enabled at (138448): [] __do_softirq+0x347/0x456
  softirqs last disabled at (138443): [] irq_exit+0x7d/0xb0
  CPU: 46 PID: 9922 Comm: daxctl Not tainted 5.7.0-BEN-14238-g373c6049b336 #30
  Hardware name: Intel Corporation PURLEY/PURLEY, BIOS PLYXCRB1.86B.0578.D07.1902280810 02/28/2019
  RIP: 0010:memset_erms+0x9/0x10
  Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1  aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
  Call Trace:
   remove_pfn_range_from_zone+0x3a/0x380
   memunmap_pages+0x17f/0x280
   release_nodes+0x22a/0x260
   __device_release_driver+0x172/0x220
   device_driver_detach+0x3e/0xa0
   unbind_store+0x113/0x130
   kernfs_fop_write+0xdc/0x1c0
   vfs_write+0xde/0x1d0
   ksys_write+0x58/0xd0
   do_syscall_64+0x5a/0x120
   entry_SYSCALL_64_after_hwframe+0x49/0xb3
  Built 2 zonelists, mobility grouping on.  Total pages: 49050381
  Policy zone: Normal
  Built 3 zonelists, mobility grouping on.  Total pages: 49312525
  Policy zone: Normal

David said: "It really only is an issue for devmem.  Ordinary
hotplugged system memory is not affected (onlined/offlined in memory
block granularity)."

Link: http://lkml.kernel.org/r/20200619231213.1160351-1-ben.widawsky@intel.com
Fixes: commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()")
Signed-off-by: Ben Widawsky 
Reported-by: "Scargall, Steve" 
Reported-by: Ben Widawsky 
Acked-by: David Hildenbrand 
Cc: Dan Williams 
Cc: Vishal Verma 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm/memory_hotplug: add pgprot_t to mhp_params

2020-04-10T22:36:21+00:00

devm_memremap_pages() is currently used by the PCI P2PDMA code to create
struct page mappings for IO memory.  At present, these mappings are
created with PAGE_KERNEL which implies setting the PAT bits to be WB.
However, on x86, an mtrr register will typically override this and force
the cache type to be UC-.  In the case firmware doesn't set this
register it is effectively WB and will typically result in a machine
check exception when it's accessed.

Other arches are not currently likely to function correctly seeing they
don't have any MTRR registers to fall back on.

To solve this, provide a way to specify the pgprot value explicitly to
arch_add_memory().

Of the arches that support MEMORY_HOTPLUG: x86_64, and arm64 need a
simple change to pass the pgprot_t down to their respective functions
which set up the page tables.  For x86_32, set the page tables
explicitly using _set_memory_prot() (seeing they are already mapped).

For ia64, s390 and sh, reject anything but PAGE_KERNEL settings -- this
should be fine, for now, seeing these architectures don't support
ZONE_DEVICE.

A check in __add_pages() is also added to ensure the pgprot parameter
was set for all arches.

Signed-off-by: Logan Gunthorpe 
Signed-off-by: Andrew Morton 
Acked-by: David Hildenbrand 
Acked-by: Michal Hocko 
Acked-by: Dan Williams 
Cc: Andy Lutomirski 
Cc: Benjamin Herrenschmidt 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Christoph Hellwig 
Cc: Dave Hansen 
Cc: Eric Badger 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jason Gunthorpe 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Link: http://lkml.kernel.org/r/20200306170846.9333-7-logang@deltatee.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug: rename mhp_restrictions to mhp_params

2020-04-10T22:36:21+00:00

The mhp_restrictions struct really doesn't specify anything resembling a
restriction anymore so rename it to be mhp_params as it is a list of
extended parameters.

Signed-off-by: Logan Gunthorpe 
Signed-off-by: Andrew Morton 
Reviewed-by: David Hildenbrand 
Reviewed-by: Dan Williams 
Acked-by: Michal Hocko 
Cc: Andy Lutomirski 
Cc: Benjamin Herrenschmidt 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Christoph Hellwig 
Cc: Dave Hansen 
Cc: Eric Badger 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jason Gunthorpe 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Link: http://lkml.kernel.org/r/20200306170846.9333-3-logang@deltatee.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug.c: use __pfn_to_section() instead of open-coding

2020-04-07T17:43:41+00:00

Use __pfn_to_section() API instead of open-coding for better code
readability.

Signed-off-by: chenqiwu 
Signed-off-by: Andrew Morton 
Acked-by: David Hildenbrand 
Link: http://lkml.kernel.org/r/1584345134-16671-1-git-send-email-qiwuchen55@gmail.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug: allow to specify a default online_type

2020-04-07T17:43:41+00:00

For now, distributions implement advanced udev rules to essentially
- Don't online any hotplugged memory (s390x)
- Online all memory to ZONE_NORMAL (e.g., most virt environments like
  hyperv)
- Online all memory to ZONE_MOVABLE in case the zone imbalance is taken
  care of (e.g., bare metal, special virt environments)

In summary: All memory is usually onlined the same way, however, the
kernel always has to ask user space to come up with the same answer.
E.g., Hyper-V always waits for a memory block to get onlined before
continuing, otherwise it might end up adding memory faster than
onlining it, which can result in strange OOM situations.  This waiting
slows down adding of a bigger amount of memory.

Let's allow to specify a default online_type, not just "online" and
"offline".  This allows distributions to configure the default online_type
when booting up and be done with it.

We can now specify "offline", "online", "online_movable" and
"online_kernel" via
- "memhp_default_state=" on the kernel cmdline
- /sys/devices/system/memory/auto_online_blocks
just like we are able to specify for a single memory block via
/sys/devices/system/memory/memoryX/state

Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Wei Yang 
Reviewed-by: Baoquan He 
Acked-by: Michal Hocko 
Acked-by: Pankaj Gupta 
Cc: Greg Kroah-Hartman 
Cc: Oscar Salvador 
Cc: "Rafael J. Wysocki" 
Cc: Wei Yang 
Cc: Benjamin Herrenschmidt 
Cc: Eduardo Habkost 
Cc: Haiyang Zhang 
Cc: Igor Mammedov 
Cc: "K. Y. Srinivasan" 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Stephen Hemminger 
Cc: Vitaly Kuznetsov 
Cc: Wei Liu 
Cc: Yumei Huang 
Link: http://lkml.kernel.org/r/20200317104942.11178-9-david@redhat.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug: convert memhp_auto_online to store an online_type

2020-04-07T17:43:40+00:00

...  and rename it to memhp_default_online_type.  This is a preparation
for more detailed default online behavior.

Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Wei Yang 
Reviewed-by: Baoquan He 
Acked-by: Michal Hocko 
Acked-by: Pankaj Gupta 
Cc: Greg Kroah-Hartman 
Cc: Oscar Salvador 
Cc: "Rafael J. Wysocki" 
Cc: Wei Yang 
Cc: Benjamin Herrenschmidt 
Cc: Eduardo Habkost 
Cc: Haiyang Zhang 
Cc: Igor Mammedov 
Cc: "K. Y. Srinivasan" 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Stephen Hemminger 
Cc: Vitaly Kuznetsov 
Cc: Wei Liu 
Cc: Yumei Huang 
Link: http://lkml.kernel.org/r/20200317104942.11178-8-david@redhat.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug: unexport memhp_auto_online

2020-04-07T17:43:40+00:00

All in-tree users except the mm-core are gone. Let's drop the export.

Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Wei Yang 
Reviewed-by: Baoquan He 
Acked-by: Michal Hocko 
Acked-by: Pankaj Gupta 
Cc: Oscar Salvador 
Cc: "Rafael J. Wysocki" 
Cc: Benjamin Herrenschmidt 
Cc: Eduardo Habkost 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Igor Mammedov 
Cc: "K. Y. Srinivasan" 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Stephen Hemminger 
Cc: Vitaly Kuznetsov 
Cc: Wei Liu 
Cc: Yumei Huang 
Link: http://lkml.kernel.org/r/20200317104942.11178-7-david@redhat.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug.c: cleanup __add_pages()

2020-04-07T17:43:40+00:00

Let's drop the basically unused section stuff and simplify.  The logic now
matches the logic in __remove_pages().

Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Baoquan He 
Reviewed-by: Wei Yang 
Cc: Segher Boessenkool 
Cc: Oscar Salvador 
Cc: Michal Hocko 
Cc: Dan Williams 
Link: http://lkml.kernel.org/r/20200228095819.10750-3-david@redhat.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug.c: simplify calculation of number of pages in __remove_pages()

2020-04-07T17:43:40+00:00

In commit 52fb87c81f11 ("mm/memory_hotplug: cleanup __remove_pages()"), we
cleaned up __remove_pages(), and introduced a shorter variant to calculate
the number of pages to the next section boundary.

Turns out we can make this calculation easier to read.  We always want to
have the number of pages (> 0) to the next section boundary, starting from
the current pfn.

We'll clean up __remove_pages() in a follow-up patch and directly make use
of this computation.

Suggested-by: Segher Boessenkool 
Signed-off-by: David Hildenbrand 
Signed-off-by: Andrew Morton 
Reviewed-by: Baoquan He 
Reviewed-by: Wei Yang 
Cc: Oscar Salvador 
Cc: Michal Hocko 
Cc: Dan Williams 
Link: http://lkml.kernel.org/r/20200228095819.10750-2-david@redhat.com
Signed-off-by: Linus Torvalds

mm/memory_hotplug.c: only respect mem= parameter during boot stage

2020-04-07T17:43:40+00:00

In commit 357b4da50a62 ("x86: respect memory size limiting via mem=
parameter") a global varialbe max_mem_size is added to store the value
parsed from 'mem= ', then checked when memory region is added.  This truly
stops those DIMMs from being added into system memory during boot-time.

However, it also limits the later memory hotplug functionality.  Any DIMM
can't be hotplugged any more if its region is beyond the max_mem_size.  We
will get errors like:

[  216.387164] acpi PNP0C80:02: add_memory failed
[  216.389301] acpi PNP0C80:02: acpi_memory_enable_device() error
[  216.392187] acpi PNP0C80:02: Enumeration failure

This will cause issue in a known use case where 'mem=' is added to the
hypervisor.  The memory that lies after 'mem=' boundary will be assigned
to KVM guests.  After commit 357b4da50a62 merged, memory can't be extended
dynamically if system memory on hypervisor is not sufficient.

So fix it by also checking if it's during boot-time restricting to add
memory.  Otherwise, skip the restriction.

And also add this use case to document of 'mem=' kernel parameter.

Fixes: 357b4da50a62 ("x86: respect memory size limiting via mem= parameter")
Signed-off-by: Baoquan He 
Signed-off-by: Andrew Morton 
Reviewed-by: Juergen Gross 
Acked-by: Michal Hocko 
Cc: Ingo Molnar 
Cc: William Kucharski 
Cc: David Hildenbrand 
Cc: Balbir Singh 
Link: http://lkml.kernel.org/r/20200204050643.20925-1-bhe@redhat.com
Signed-off-by: Linus Torvalds