linux.git/drivers/base, branch v4.17

mm/memory_hotplug: fix leftover use of struct page during hotplug

2018-05-26T01:12:11+00:00

The case of a new numa node got missed in avoiding using the node info
from page_struct during hotplug.  In this path we have a call to
register_mem_sect_under_node (which allows us to specify it is hotplug
so don't change the node), via link_mem_sections which unfortunately
does not.

Fix is to pass check_nid through link_mem_sections as well and disable
it in the new numa node path.

Note the bug only 'sometimes' manifests depending on what happens to be
in the struct page structures - there are lots of them and it only needs
to match one of them.

The result of the bug is that (with a new memory only node) we never
successfully call register_mem_sect_under_node so don't get the memory
associated with the node in sysfs and meminfo for the node doesn't
report it.

It came up whilst testing some arm64 hotplug patches, but appears to be
universal.  Whilst I'm triggering it by removing then reinserting memory
to a node with no other elements (thus making the node disappear then
appear again), it appears it would happen on hotplugging memory where
there was none before and it doesn't seem to be related the arm64
patches.

These patches call __add_pages (where most of the issue was fixed by
Pavel's patch).  If there is a node at the time of the __add_pages call
then all is well as it calls register_mem_sect_under_node from there
with check_nid set to false.  Without a node that function returns
having not done the sysfs related stuff as there is no node to use.
This is expected but it is the resulting path that fails...

Exact path to the problem is as follows:

 mm/memory_hotplug.c: add_memory_resource()

   The node is not online so we enter the 'if (new_node)' twice, on the
   second such block there is a call to link_mem_sections which calls
   into

  drivers/node.c: link_mem_sections() which calls

  drivers/node.c: register_mem_sect_under_node() which calls
     get_nid_for_pfn and keeps trying until the output of that matches
     the expected node (passed all the way down from
     add_memory_resource)

It is effectively the same fix as the one referred to in the fixes tag
just in the code path for a new node where the comments point out we
have to rerun the link creation because it will have failed in
register_new_memory (as there was no node at the time).  (actually that
comment is wrong now as we don't have register_new_memory any more it
got renamed to hotplug_memory_register in Pavel's patch).

Link: http://lkml.kernel.org/r/20180504085311.1240-1-Jonathan.Cameron@huawei.com
Fixes: fc44f7f9231a ("mm/memory_hotplug: don't read nid from struct page during hotplug")
Signed-off-by: Jonathan Cameron 
Reviewed-by: Pavel Tatashin 
Acked-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'pm-4.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2018-05-24T15:49:56+00:00

Pull power management fix from Rafael Wysocki:
 "Fix a regression from the 4.15 cycle that caused the system suspend
  and resume overhead to increase on many systems and triggered more
  serious problems on some of them (Rafael Wysocki)"

* tag 'pm-4.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / core: Fix direct_complete handling for devices with no callbacks

PM / core: Fix direct_complete handling for devices with no callbacks

2018-05-22T12:50:11+00:00

Commit 08810a4119aa (PM / core: Add NEVER_SKIP and SMART_PREPARE
driver flags) inadvertently prevented the power.direct_complete flag
from being set for devices without PM callbacks and with disabled
runtime PM which also prevents power.direct_complete from being set
for their parents.  That led to problems including a resume crash on
HP ZBook 14u.

Restore the previous behavior by causing power.direct_complete to be
set for those devices again, but do that in a more direct way to
avoid overlooking that case in the future.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199693
Fixes: 08810a4119aa (PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags)
Reported-by: Thomas Martitz 
Tested-by: Thomas Martitz 
Cc: 4.15+  # 4.15+
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Ulf Hansson 
Reviewed-by: Johan Hovold

x86/bugs: Expose /sys/../spec_store_bypass

2018-05-03T11:55:47+00:00

Add the sysfs file for the new vulerability. It does not do much except
show the words 'Vulnerable' for recent x86 cores.

Intel cores prior to family 6 are known not to be vulnerable, and so are
some Atoms and some Xeon Phi.

It assumes that older Cyrix, Centaur, etc. cores are immune.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Reviewed-by: Ingo Molnar

Merge tag 'driver-core-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2018-04-27T17:12:20+00:00

Pull driver core fixes from Greg Kroah-Hartman:
 "Here are some small driver core and firmware fixes for 4.17-rc3

  There's a kobject WARN() removal to make syzkaller a lot happier about
  some "normal" error paths that it keeps hitting, which should reduce
  the number of false-positives we have been getting recently.

  There's also some fimware test and documentation fixes, and the
  coredump() function signature change that needed to happen after -rc1
  before drivers started to take advantage of it.

  All of these have been in linux-next with no reported issues"

* tag 'driver-core-4.17-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  firmware: some documentation fixes
  selftests:firmware: fixes a call to a wrong function name
  kobject: don't use WARN for registration failures
  firmware: Fix firmware documentation for recent file renames
  test_firmware: fix setting old custom fw path back on exit, second try
  test_firmware: Install all scripts
  drivers: change struct device_driver::coredump() return type to void

firmware: some documentation fixes

2018-04-25T16:37:20+00:00

Including:
 - Fixup outdated kernel-doc paths
 - Slightly too short title underline
 - Some typos

Signed-off-by: Andres Rodriguez 
Signed-off-by: Greg Kroah-Hartman

dma-mapping: postpone cpu addr translation on mmap

2018-04-23T12:44:24+00:00

Postpone calling virt_to_page() translation on memory locations not
guaranteed to be backed by a struct page.  Try first to map memory from
the device coherent memory pool, then perform translation if that fails.

On some architectures, specifically SH when configured with the SPARSEMEM
memory model, assuming a struct page is always assigned to a memory
address lead to unexpected hangs during the virtual to page address
translation. This patch fixes that specific issue but applies in the
general case too.

Suggested-by: Laurent Pinchart 
Signed-off-by: Jacopo Mondi 
Reviewed-by: Robin Murphy 
Signed-off-by: Christoph Hellwig

dma-coherent: clarify dma_mmap_from_dev_coherent documentation

2018-04-23T12:44:17+00:00

The use of "correctly mapped" here is misleading, since it can give the
wrong expectation in the case that the memory *should* have been mapped
from the per-device pool, but doing so failed for other reasons.

Signed-off-by: Robin Murphy 
Signed-off-by: Christoph Hellwig

mm: check __highest_present_section_nr directly in memory_dev_init()

2018-04-11T17:28:31+00:00

__highest_present_section_nr is a more strict boundary than
NR_MEM_SECTIONS.  So checking __highest_present_section_nr directly is
enough.

Link: http://lkml.kernel.org/r/20180330032044.21647-1-richard.weiyang@gmail.com
Signed-off-by: Wei Yang 
Reviewed-by: Andrew Morton 
Cc: Dave Hansen 
Cc: Michal Hocko 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/memory_hotplug: optimize memory hotplug

2018-04-06T04:36:25+00:00

During memory hotplugging we traverse struct pages three times:

1. memset(0) in sparse_add_one_section()
2. loop in __add_section() to set do: set_page_node(page, nid); and
   SetPageReserved(page);
3. loop in memmap_init_zone() to call __init_single_pfn()

This patch removes the first two loops, and leaves only loop 3.  All
struct pages are initialized in one place, the same as it is done during
boot.

The benefits:

 - We improve memory hotplug performance because we are not evicting the
   cache several times and also reduce loop branching overhead.

 - Remove condition from hotpath in __init_single_pfn(), that was added
   in order to fix the problem that was reported by Bharata in the above
   email thread, thus also improve performance during normal boot.

 - Make memory hotplug more similar to the boot memory initialization
   path because we zero and initialize struct pages only in one
   function.

 - Simplifies memory hotplug struct page initialization code, and thus
   enables future improvements, such as multi-threading the
   initialization of struct pages in order to improve hotplug
   performance even further on larger machines.

[pasha.tatashin@oracle.com: v5]
  Link: http://lkml.kernel.org/r/20180228030308.1116-7-pasha.tatashin@oracle.com
Link: http://lkml.kernel.org/r/20180215165920.8570-7-pasha.tatashin@oracle.com
Signed-off-by: Pavel Tatashin 
Reviewed-by: Ingo Molnar 
Cc: Michal Hocko 
Cc: Baoquan He 
Cc: Bharata B Rao 
Cc: Daniel Jordan 
Cc: Dan Williams 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Kirill A. Shutemov 
Cc: Mel Gorman 
Cc: Steven Sistare 
Cc: Thomas Gleixner 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds