Messages in this thread | | | From | David Hildenbrand <> | Subject | Re: [PATCH v5 1/5] mm,memory_hotplug: Allocate memmap from the added memory range | Date | Fri, 26 Mar 2021 15:53:41 +0100 |
| |
On 26.03.21 15:38, Michal Hocko wrote: > On Fri 26-03-21 09:52:58, David Hildenbrand wrote: > [...] >> Something else to note: >> >> >> We'll not call the memory notifier (e.g., MEM_ONLINE) for the vmemmap. The >> result is that >> >> 1. We won't allocate extended struct pages for the range. Don't think this >> is really problematic (pages are never allocated/freed, so I guess we don't >> care - like ZONE_DEVICE code). > > Agreed. I do not think we need them. Future might disagree but let's > handle it when we have a clear demand. > >> 2. We won't allocate kasan shadow memory. We most probably have to do it >> explicitly via kasan_add_zero_shadow()/kasan_remove_zero_shadow(), see >> mm/memremap.c:pagemap_range() > > I think this is similar to the above. Does kasan has to know about > memory which will never be used for anything?
IIRC, kasan will track read/writes to the vmemmap as well. So it could theoretically detect if we read from the vmemmap before writing (initializing) it IIUC.
This is also why mm/memremap.c does a kasan_add_zero_shadow() before the move_pfn_range_to_zone()->memmap_init_range() for the whole region, including altmap space.
Now, I am no expert on KASAN, what would happen in case we have access to non-tracked memory.
commit 0207df4fa1a869281ddbf72db6203dbf036b3e1a Author: Andrey Ryabinin <ryabinin.a.a@gmail.com> Date: Fri Aug 17 15:47:04 2018 -0700
kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN
indicates that kasan will crash the system on "non-existent shadow memory"
> >> Further a locking rework might be necessary. We hold the device hotplug >> lock, but not the memory hotplug lock. E.g., for get_online_mems(). Might >> have to move that out online_pages. > > Could you be more explicit why this locking is needed? What it would > protect from for vmemmap pages? >
One example is in mm/kmemleak.c:kmemleak_scan(), where we scan the vmemmap for pointers. We don't want the vmemmap to get unmapped while we are working on it (-> fault).
-- Thanks,
David / dhildenb
| |