lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 21 Jul 2022 23:02:06 +0200 From: "Fabio M. De Francesco" <fmdefrancesco@...il.com> To: Ira Weiny <ira.weiny@...el.com>, Andrew Morton <akpm@...ux-foundation.org>, Catalin Marinas <catalin.marinas@....com>, "Matthew Wilcox (Oracle)" <willy@...radead.org>, Will Deacon <will@...nel.org>, Peter Collingbourne <pcc@...gle.com>, Vlastimil Babka <vbabka@...e.cz>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org Cc: "Fabio M. De Francesco" <fmdefrancesco@...il.com>, Mike Rapoport <rppt@...ux.ibm.com>, Thomas Gleixner <tglx@...utronix.de> Subject: [PATCH 7/7] Documentation/mm: Add details about kmap_local_page() and preemption 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/ Cc: Andrew Morton <akpm@...ux-foundation.org> Cc: Matthew Wilcox (Oracle) <willy@...radead.org> Cc: Mike Rapoport <rppt@...ux.ibm.com> Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de> Cc: Thomas Gleixner <tglx@...utronix.de> Suggested-by: Ira Weiny <ira.weiny@...el.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@...il.com> --- Documentation/vm/highmem.rst | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst index 564017b447b1..8ce43965ddef 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/vm/highmem.rst @@ -60,14 +60,19 @@ list shows them in order of preference of use. This function should be preferred, where feasible, over all the others. 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 - CPU while the mapping is active. Even if the thread is preempted (since - preemption is never disabled by the function) the CPU can not be - unplugged from the system via CPU-hotplug until the mapping is disposed. + can only be accessed from within this thread and the thread is bound to the + CPU while the mapping is active. Although preemption is never disabled by + this function, the CPU can not be unplugged from the system via + CPU-hotplug until the mapping is disposed. 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. + 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 that kunmap_local() will never fail. -- 2.37.1
Powered by blists - more mailing lists