[PATCH 32/46] mm/memory_hotplug: avoid races in pfn_to_online_page() with dying pgmap
David Hildenbrand (Arm)
david at kernel.org
Tue Oct 27 12:41:02 PDT 2026
> LLM stumbled upon a possible race in kpage_read() ...
>
> Say the reader passes pfn_section_valid() for a device PFN in a section
> shared with online RAM, gets preempted, and resumes after
> pgmap_array_delete(). We'd then find no pgmap and return pfn_to_page(pfn),
> even though the subsection is no longer valid ...
I think that's similar to our pfn_to_online_page() vs. memory offlining races,
just slightly different. Getting these races down to 0 is pretty hard.
This patch here tries to do better and arguably almost looks like a cleanup.
I wouldn't worry about that one for now; it's extremely unlikely to hit. And it'
>
> Could we take the memory hotplug read lock in kpage_read(), covering both
> the lookup and the metadata reads? We can drop it before put_user(), once
> we're done with the page.
>
> Maybe along these lines?
>
> ---8<---
> diff --git a/fs/proc/page.c b/fs/proc/page.c
> index 6aa99e42ec22..12bed36d76dc 100644
> --- a/fs/proc/page.c
> +++ b/fs/proc/page.c
> @@ -12,6 +12,7 @@
> #include <linux/hugetlb.h>
> #include <linux/memremap.h>
> #include <linux/memcontrol.h>
> +#include <linux/memory_hotplug.h>
> #include <linux/mmu_notifier.h>
> #include <linux/page_idle.h>
> #include <linux/kernel-page-flags.h>
> @@ -77,6 +78,8 @@ static ssize_t kpage_read(struct file *file, char __user *buf,
> count = min_t(unsigned long, count, (max_dump_pfn * KPMSIZE) - src);
>
> while (count > 0) {
> + /* Prevent memory removal while inspecting the memmap. */
> + get_online_mems();
get_online_mems() is the big hammer we try to avoid (or ideally remove at some
point). And it's most pfn_to_online_page() users that are affected.
A seqcount in pfn_to_online_page() could detect concurrent pgmap removal and
retry from the start. But I'd rather delay something like that.
Thanks for taking a look! (Can I convince you to review some of the THP fixes?
pleeeeaaasseee :) )
--
Cheers,
David
More information about the kexec
mailing list