Messages in this thread | | | Subject | Re: [PATCH 0/4] arch, mm: improve robustness of direct map manipulation | From | David Hildenbrand <> | Date | Thu, 29 Oct 2020 09:15:47 +0100 |
| |
On 25.10.20 11:15, Mike Rapoport wrote: > From: Mike Rapoport <rppt@linux.ibm.com> > > Hi, > > During recent discussion about KVM protected memory, David raised a concern > about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1]. > > Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is > possible that __kernel_map_pages() would fail, but since this function is > void, the failure will go unnoticed. > > Moreover, there's lack of consistency of __kernel_map_pages() semantics > across architectures as some guard this function with > #ifdef DEBUG_PAGEALLOC, some refuse to update the direct map if page > allocation debugging is disabled at run time and some allow modifying the > direct map regardless of DEBUG_PAGEALLOC settings. > > This set straightens this out by restoring dependency of > __kernel_map_pages() on DEBUG_PAGEALLOC and updating the call sites > accordingly. >
So, I was primarily wondering if we really have to touch direct mappings in hibernation code, or if we can avoid doing that. I was wondering if we cannot simply do something like kmap() when trying to access a !mapped page. Similar to reading old-os memory after kexec when in kdump. Just a thought.
-- Thanks,
David / dhildenb
| |