Skip to content

Commit 23a12dd

Browse files
author
Ingo Molnar
committed
Merge branch 'core/urgent' into x86/urgent, to pick up objtool fix
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2 parents 98f7620 + bcb6fb5 commit 23a12dd

File tree

4,068 files changed

+261819
-73542
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

4,068 files changed

+261819
-73542
lines changed

‎.clang-format

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -323,7 +323,6 @@ ForEachMacros:
323323
- 'protocol_for_each_card'
324324
- 'protocol_for_each_dev'
325325
- 'queue_for_each_hw_ctx'
326-
- 'radix_tree_for_each_contig'
327326
- 'radix_tree_for_each_slot'
328327
- 'radix_tree_for_each_tagged'
329328
- 'rbtree_postorder_for_each_entry_safe'

‎.mailmap

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -119,6 +119,13 @@ Mark Brown <broonie@sirena.org.uk>
119119
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
120120
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
121121
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
122+
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
123+
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
124+
Matthew Wilcox <willy@infradead.org> <mawilcox@linuxonhyperv.com>
125+
Matthew Wilcox <willy@infradead.org> <mawilcox@microsoft.com>
126+
Matthew Wilcox <willy@infradead.org> <willy@debian.org>
127+
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
128+
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
122129
Matthieu CASTET <castet.matthieu@free.fr>
123130
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
124131
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
@@ -153,6 +160,11 @@ Peter Oruba <peter.oruba@amd.com>
153160
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
154161
Praveen BP <praveenbp@ti.com>
155162
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
163+
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
164+
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
165+
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
166+
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
167+
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
156168
Rajesh Shah <rajesh.shah@intel.com>
157169
Ralf Baechle <ralf@linux-mips.org>
158170
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>

‎Documentation/ABI/testing/sysfs-bus-iio

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -199,7 +199,7 @@ Description:
199199

200200
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
201201
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
202-
KernelVersion: 4.18
202+
KernelVersion: 4.19
203203
Contact: linux-iio@vger.kernel.org
204204
Description:
205205
Relative position in direction x or y on a pad (may be

‎Documentation/admin-guide/mm/memory-hotplug.rst

Lines changed: 41 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ Memory Hotplug
55
==============
66

77
:Created: Jul 28 2007
8-
:Updated: Add description of notifier of memory hotplug: Oct 11 2007
8+
:Updated: Add some details about locking internals: Aug 20 2018
99

1010
This document is about memory hotplug including how-to-use and current status.
1111
Because Memory Hotplug is still under development, contents of this text will
@@ -392,6 +392,46 @@ Need more implementation yet....
392392
- Notification completion of remove works by OS to firmware.
393393
- Guard from remove if not yet.
394394

395+
396+
Locking Internals
397+
=================
398+
399+
When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
400+
the device_hotplug_lock should be held to:
401+
402+
- synchronize against online/offline requests (e.g. via sysfs). This way, memory
403+
block devices can only be accessed (.online/.state attributes) by user
404+
space once memory has been fully added. And when removing memory, we
405+
know nobody is in critical sections.
406+
- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
407+
408+
Especially, there is a possible lock inversion that is avoided using
409+
device_hotplug_lock when adding memory and user space tries to online that
410+
memory faster than expected:
411+
412+
- device_online() will first take the device_lock(), followed by
413+
mem_hotplug_lock
414+
- add_memory_resource() will first take the mem_hotplug_lock, followed by
415+
the device_lock() (while creating the devices, during bus_add_device()).
416+
417+
As the device is visible to user space before taking the device_lock(), this
418+
can result in a lock inversion.
419+
420+
onlining/offlining of memory should be done via device_online()/
421+
device_offline() - to make sure it is properly synchronized to actions
422+
via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
423+
424+
When adding/removing/onlining/offlining memory or adding/removing
425+
heterogeneous/device memory, we should always hold the mem_hotplug_lock in
426+
write mode to serialise memory hotplug (e.g. access to global/zone
427+
variables).
428+
429+
In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
430+
mode allows for a quite efficient get_online_mems/put_online_mems
431+
implementation, so code accessing memory can protect from that memory
432+
vanishing.
433+
434+
395435
Future Work
396436
===========
397437

‎Documentation/arm/Samsung/Bootloader-interface.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@ Offset Value Purpose
2626
0x20 0xfcba0d10 (Magic cookie) AFTR
2727
0x24 exynos_cpu_resume_ns AFTR
2828
0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR
29+
0x28 0x0 or last value during resume (Exynos542x) System suspend
2930

3031

3132
2. Secure mode

‎Documentation/core-api/boot-time-mm.rst

Lines changed: 9 additions & 60 deletions
Original file line numberDiff line numberDiff line change
@@ -5,54 +5,23 @@ Boot time memory management
55
Early system initialization cannot use "normal" memory management
66
simply because it is not set up yet. But there is still need to
77
allocate memory for various data structures, for instance for the
8-
physical page allocator. To address this, a specialized allocator
9-
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
10-
introduced. Several years later PowerPC developers added a "Logical
11-
Memory Blocks" allocator, which was later adopted by other
12-
architectures and renamed to :ref:`memblock <memblock>`. There is also
13-
a compatibility layer called `nobootmem` that translates bootmem
14-
allocation interfaces to memblock calls.
8+
physical page allocator.
159

16-
The selection of the early allocator is done using
17-
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
18-
configuration options. These options are enabled or disabled
19-
statically by the architectures' Kconfig files.
20-
21-
* Architectures that rely only on bootmem select
22-
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
23-
* The users of memblock with the nobootmem compatibility layer set
24-
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
25-
* And for those that use both memblock and bootmem the configuration
26-
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
27-
28-
Whichever allocator is used, it is the responsibility of the
29-
architecture specific initialization to set it up in
30-
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
10+
A specialized allocator called ``memblock`` performs the
11+
boot time memory management. The architecture specific initialization
12+
must set it up in :c:func:`setup_arch` and tear it down in
13+
:c:func:`mem_init` functions.
3114

3215
Once the early memory management is available it offers a variety of
3316
functions and macros for memory allocations. The allocation request
3417
may be directed to the first (and probably the only) node or to a
3518
particular node in a NUMA system. There are API variants that panic
36-
when an allocation fails and those that don't. And more recent and
37-
advanced memblock even allows controlling its own behaviour.
38-
39-
.. _bootmem:
40-
41-
Bootmem
42-
=======
19+
when an allocation fails and those that don't.
4320

44-
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
45-
Memory Manager" `book`_)
21+
Memblock also offers a variety of APIs that control its own behaviour.
4622

47-
.. _book: https://www.kernel.org/doc/gorman/
48-
49-
.. kernel-doc:: mm/bootmem.c
50-
:doc: bootmem overview
51-
52-
.. _memblock:
53-
54-
Memblock
55-
========
23+
Memblock Overview
24+
=================
5625

5726
.. kernel-doc:: mm/memblock.c
5827
:doc: memblock overview
@@ -61,26 +30,6 @@ Memblock
6130
Functions and structures
6231
========================
6332

64-
Common API
65-
----------
66-
67-
The functions that are described in this section are available
68-
regardless of what early memory manager is enabled.
69-
70-
.. kernel-doc:: mm/nobootmem.c
71-
72-
Bootmem specific API
73-
--------------------
74-
75-
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
76-
77-
.. kernel-doc:: include/linux/bootmem.h
78-
.. kernel-doc:: mm/bootmem.c
79-
:functions:
80-
81-
Memblock specific API
82-
---------------------
83-
8433
Here is the description of memblock data structures, functions and
8534
macros. Some of them are actually internal, but since they are
8635
documented it would be silly to omit them. Besides, reading the

‎Documentation/core-api/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@ Core utilities
2121
local_ops
2222
workqueue
2323
genericirq
24+
xarray
2425
flexible-arrays
2526
librs
2627
genalloc

0 commit comments

Comments
 (0)