hamza.kesraoui/sst-linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Documentation/mm: add details about kmap_local_page() and preemption

Browse Source 
What happens if a thread is preempted after mapping pages with
kmap_local_page() was questioned recently.[1]

Commit f3ba3c710ac5 ("mm/highmem: Provide kmap_local*") from Thomas
Gleixner explains clearly that on context switch, the maps of an outgoing
task are removed and the map of the incoming task are restored and that
kmap_local_page() can be invoked from both preemptible and atomic
contexts.[2]

Therefore, for the purpose to make it clearer that users can call
kmap_local_page() from contexts that allow preemption, rework a couple of
sentences and add further information in highmem.rst.

[1] https://lore.kernel.org/lkml/5303077.Sb9uPGUboI@opensuse/
[2] https://lore.kernel.org/all/20201118204007.468533059@linutronix.de/

Link: https://lkml.kernel.org/r/20220728154844.10874-8-fmdefrancesco@gmail.com
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Suggested-by: Ira Weiny <ira.weiny@intel.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This commit is contained in:
Fabio M. De Francesco 2022-07-28 17:48:44 +02:00 committed by Andrew Morton
parent 72f1c55adf
commit a9e9c93966
1 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
Documentation/mm/highmem.rst
View File

@ -60,14 +60,19 @@ list shows them in order of preference of use.
This function should be preferred, where feasible, over all the others. This function should be preferred, where feasible, over all the others.
These mappings are thread-local and CPU-local, meaning that the mapping These mappings are thread-local and CPU-local, meaning that the mapping
can only be accessed from within this thread and the thread is bound the can only be accessed from within this thread and the thread is bound to the
CPU while the mapping is active. Even if the thread is preempted (since CPU while the mapping is active. Although preemption is never disabled by
preemption is never disabled by the function) the CPU can not be this function, the CPU can not be unplugged from the system via
unplugged from the system via CPU-hotplug until the mapping is disposed. CPU-hotplug until the mapping is disposed.
It's valid to take pagefaults in a local kmap region, unless the context It's valid to take pagefaults in a local kmap region, unless the context
in which the local mapping is acquired does not allow it for other reasons. in which the local mapping is acquired does not allow it for other reasons.
As said, pagefaults and preemption are never disabled. There is no need to
disable preemption because, when context switches to a different task, the
maps of the outgoing task are saved and those of the incoming one are
restored.
kmap_local_page() always returns a valid virtual address and it is assumed kmap_local_page() always returns a valid virtual address and it is assumed
that kunmap_local() will never fail. that kunmap_local() will never fail.