From: sashiko-bot@kernel.org
To: "Oscar Salvador" <osalvador@suse.de>,
"Suren Baghdasaryan" <surenb@google.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Michal Hocko" <mhocko@suse.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Zi Yan" <ziy@nvidia.com>, "Miaohe Lin" <linmiaohe@huawei.com>,
"Borislav Petkov" <bp@alien8.de>,
"Thomas Gleixner" <tglx@kernel.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
x86@kernel.org, "David Hildenbrand" <david@kernel.org>,
"Naoya Horiguchi" <nao.horiguchi@gmail.com>,
shakeel.butt@linux.dev,
"Brendan Jackman" <brendan.jackman@linux.dev>,
hannes@cmpxchg.or, "Ard Biesheuvel" <ardb@kernel.org>,
kas@kernel.org, "Ingo Molnar" <mingo@redhat.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Breno Leitao" <leitao@debian.org>
Cc: linux-cxl@vger.kernel.org, linux-mm@kvack.org, rmikey@meta.com,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
linux-efi@vger.kernel.org, harry@kernel.org,
driver-core@lists.linux.dev, kexec@lists.infradead.org,
riel@surriel.com
Subject: Re: [PATCH v5 8/9] mm/memory-failure: add hwpoison_boot_page() to flag an inherited frame
Date: Tue, 15 Sep 2026 14:11:20 +0000 [thread overview]
Message-ID: <20260915141120.A209A1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915-hwpoison-kho-v5-8-3bc7a57bd503@debian.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: memory_failure_stats data race in hwpoison_boot_page()
--
commit 95ab593413859ad843df67ede9095a08529eb0cd
Author: Breno Leitao <leitao@debian.org>
mm/memory-failure: add hwpoison_boot_page() to flag an inherited frame
This commit adds a helper, hwpoison_boot_page(), to flag inherited frames
recorded as poisoned by the previous kernel before they reach the allocator.
It leaves the frame in the state expected for poisoned frames, allowing
existing PG_hwpoison logic to cover it appropriately.
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index d9b8be696aac3..60e9682434700 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
[ ... ]
> @@ -137,6 +137,32 @@ phys_addr_t range_last_hwpoison(phys_addr_t start, unsigned long size)
> return range_hwpoison(start, size, false);
> }
>
> +static void update_per_node_mf_stats(unsigned long pfn, enum mf_result result);
> +
> +void __meminit hwpoison_boot_page(struct page *page,
> + enum meminit_context context)
> +{
> + unsigned long pfn = page_to_pfn(page);
> +
> + if (PageHWPoison(page))
> + return;
> +
> + SetPageHWPoison(page);
> + set_page_count(page, 1);
> + /* The page has been completely isolated == MF_RECOVERED */
> + update_per_node_mf_stats(pfn, MF_RECOVERED);
[Severity: Medium]
Is it safe to call update_per_node_mf_stats() here without acquiring mf_mutex?
During memory hotplug (when context == MEMINIT_HOTPLUG), if
hwpoison_boot_page() is called for inherited poisoned frames, it appears this
could race with runtime hardware error processing on other CPUs.
Other paths like memory_failure() update these same per-node statistics while
holding mf_mutex. Because update_per_node_mf_stats() performs non-atomic
increments:
mm/memory-failure.c:update_per_node_mf_stats() {
...
case MF_RECOVERED:
++mf_stats->recovered;
break;
...
++mf_stats->total;
}
Could calling it here circumvent the mutex and corrupt the memory failure
sysfs statistics by losing counter updates?
> +
> + /*
> + * The per memory block half of num_poisoned_pages_inc() has no block to
> + * find at boot, and divides by zero looking for one. A hotplugged block
> + * is already there.
> + */
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-hwpoison-kho-v5-0-3bc7a57bd503@debian.org?part=8
next prev parent reply other threads:[~2026-09-15 14:11 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 12:53 [PATCH v5 0/9] mm/memory-failure: keep hardware-poisoned pages out of the next kexec Breno Leitao
2026-09-15 12:53 ` [PATCH v5 1/9] mm/page_alloc: factor out the accept-and-free tail of __free_pages_core() Breno Leitao
2026-09-15 12:57 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 2/9] mm/memory-failure: efi: add the LINUX_EFI_POISONED_MEMORY configuration table Breno Leitao
2026-09-15 13:05 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 3/9] mm/memory-failure: libstub: install the poisoned-memory EFI table Breno Leitao
2026-09-15 13:15 ` sashiko-bot
2026-09-15 14:00 ` Breno Leitao
2026-09-16 15:39 ` Usama Arif
2026-09-17 10:53 ` Breno Leitao
2026-09-15 12:53 ` [PATCH v5 4/9] mm/memory-failure: efi: adopt the inherited poisoned-memory table Breno Leitao
2026-09-15 13:24 ` sashiko-bot
2026-09-15 12:53 ` [PATCH v5 5/9] mm/memory-failure: efi: record hardware-poisoned frames into the " Breno Leitao
2026-09-15 13:36 ` sashiko-bot
2026-09-15 14:33 ` Breno Leitao
2026-09-15 12:53 ` [PATCH v5 6/9] mm/memory-failure: efi: answer whether a range is poisoned Breno Leitao
2026-09-15 13:45 ` sashiko-bot
2026-09-16 6:44 ` David Hildenbrand (Arm)
2026-09-18 15:27 ` Breno Leitao
2026-09-18 15:53 ` Harry Yoo
2026-09-18 20:02 ` David Hildenbrand (Arm)
2026-09-15 12:53 ` [PATCH v5 7/9] drivers/base/memory: count inherited poisoned frames into the block Breno Leitao
2026-09-15 13:59 ` sashiko-bot
2026-09-16 6:48 ` David Hildenbrand (Arm)
2026-09-16 9:35 ` Breno Leitao
2026-09-16 14:51 ` David Hildenbrand (Arm)
2026-09-17 13:01 ` Breno Leitao
2026-09-18 12:18 ` David Hildenbrand (Arm)
2026-09-18 15:22 ` Breno Leitao
2026-09-18 20:16 ` David Hildenbrand (Arm)
2026-09-21 14:31 ` Breno Leitao
2026-09-22 11:33 ` David Hildenbrand (Arm)
2026-09-22 12:34 ` Breno Leitao
2026-09-24 11:22 ` David Hildenbrand (Arm)
2026-09-22 12:51 ` Kiryl Shutsemau
2026-09-22 13:45 ` Harry Yoo
2026-09-22 13:53 ` David Hildenbrand (Arm)
2026-09-15 12:53 ` [PATCH v5 8/9] mm/memory-failure: add hwpoison_boot_page() to flag an inherited frame Breno Leitao
2026-09-15 14:11 ` sashiko-bot [this message]
2026-09-19 10:28 ` Shaikh Kamaluddin
2026-09-21 13:41 ` Breno Leitao
2026-09-15 12:53 ` [PATCH v5 9/9] mm/memory-failure: keep inherited poisoned frames out of the buddy allocator Breno Leitao
2026-09-15 14:25 ` sashiko-bot
2026-09-16 8:32 ` Vlastimil Babka (SUSE)
2026-09-22 6:27 ` [PATCH v5 0/9] mm/memory-failure: keep hardware-poisoned pages out of the next kexec Miaohe Lin
2026-09-22 9:14 ` Breno Leitao
2026-09-22 9:29 ` Miaohe Lin
2026-09-22 10:39 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260915141120.A209A1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=brendan.jackman@linux.dev \
--cc=dakr@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.or \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=hpa@zytor.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=rafael@kernel.org \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=x86@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.