From: Shuai Xue <xueshuai@linux.alibaba.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Luck, Tony" <tony.luck@intel.com>,
"nao.horiguchi@gmail.com" <nao.horiguchi@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linmiaohe@huawei.com" <linmiaohe@huawei.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"jpoimboe@kernel.org" <jpoimboe@kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"baolin.wang@linux.alibaba.com" <baolin.wang@linux.alibaba.com>,
"tianruidong@linux.alibaba.com" <tianruidong@linux.alibaba.com>
Subject: Re: [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling
Date: Sat, 1 Mar 2025 13:54:03 +0800 [thread overview]
Message-ID: <d41853e8-0594-4359-bba7-18969725d8ac@linux.alibaba.com> (raw)
In-Reply-To: <20250228123553.GCZ8GtqbSq9kaYOaCi@fat_crate.local>
在 2025/2/28 20:35, Borislav Petkov 写道:
> On Tue, Feb 25, 2025 at 09:51:25AM +0800, Shuai Xue wrote:
>> It depends on the forked process which trying to read the poison.
>
> And? Can you try creating more processes and see what happens then?
>
Sure.
The experimental model includes:
1. inject UE to a memory buffer
2. create 10 processes
3. all 10 process read the posioned buffer
4. 10 MCEs and 1 UCNA will be triggered
5. each process receives a SIGBUS
Some details:
#perf record -e probe:memory_failure -agR -- ./einj_mem_uc thread
0: thread vaddr = 0x7f65f08da400 paddr = 82702ec400
injecting ...
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
>> trigger_thread
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
signal 7 code 4 addr 0x7f65f08da000
page not present
Unusual number of MCEs seen: 10
Test passed
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.640 MB perf.data (11 samples) ]
#perf script
einj_mem_uc 1722254 [151] 695128.161644: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722255 [014] 695128.161712: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722256 [153] 695128.161716: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722257 [124] 695128.161759: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722258 [154] 695128.161782: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722259 [026] 695128.161819: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722260 [157] 695128.161852: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722261 [158] 695128.161895: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
kworker/50:3-mm 1714430 [050] 695128.168736: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa25aa93 uc_decode_notifier+0x73 ([kernel.kallsyms])
ffffffffaa3068bb notifier_call_chain+0x5b ([kernel.kallsyms])
ffffffffaa306ae1 blocking_notifier_call_chain+0x41 ([kernel.kallsyms])
ffffffffaa25bbfe mce_gen_pool_process+0x3e ([kernel.kallsyms])
ffffffffaa2f455f process_one_work+0x19f ([kernel.kallsyms])
ffffffffaa2f509c worker_thread+0x20c ([kernel.kallsyms])
ffffffffaa2fec89 kthread+0xd9 ([kernel.kallsyms])
ffffffffaa245131 ret_from_fork+0x31 ([kernel.kallsyms])
ffffffffaa2076ca ret_from_fork_asm+0x1a ([kernel.kallsyms])
einj_mem_uc 1722252 [050] 695128.183025: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
einj_mem_uc 1722253 [051] 695128.191348: probe:memory_failure: (ffffffffaa622db4)
ffffffffaa622db5 memory_failure+0x5 ([kernel.kallsyms])
ffffffffaa2594fb kill_me_maybe+0x5b ([kernel.kallsyms])
ffffffffaa2fac29 task_work_run+0x59 ([kernel.kallsyms])
ffffffffaaf52347 irqentry_exit_to_user_mode+0x1c7 ([kernel.kallsyms])
ffffffffaaf50bce noist_exc_machine_check+0x3e ([kernel.kallsyms])
ffffffffaa001303 asm_exc_machine_check+0x33 ([kernel.kallsyms])
405046 thread+0xe (/home/shawn.xs/ras-tools/einj_mem_uc)
>> IMHO, we should send a SIGBUS signal to the processes running on the CPUs that
>> detect a memory error for dirty page, which is the current behavior in the
>> memory_failure.
>
> And for all those other processes which do get to see the already
> poisoned/clean page, they should continue on their merry way instead of
> getting killed by a SIGBUS?
>
Yes, memory_failure() only sends a SIGBUS signal to the process that
is actively reading a poisoned page. Other processes that share the
poisoned page will not receive a SIGBUS signal unless they have the
PF_MCE_EARLY flag set.[1]
[1]https://lkml.kernel.org/r/20220218090118.1105-4-linmiaohe@huawei.com
Thanks.
Shuai
next prev parent reply other threads:[~2025-03-01 5:54 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 6:33 [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling Shuai Xue
2025-02-17 6:33 ` [PATCH v2 1/5] x86/mce: Collect error message for severities below MCE_PANIC_SEVERITY Shuai Xue
2025-02-18 7:58 ` Borislav Petkov
2025-02-18 9:39 ` Shuai Xue
2025-02-18 9:50 ` Borislav Petkov
2025-02-17 6:33 ` [PATCH v2 2/5] x86/mce: dump error msg from severities Shuai Xue
2025-02-28 12:37 ` Borislav Petkov
2025-03-01 6:16 ` Shuai Xue
2025-03-01 11:10 ` Borislav Petkov
2025-03-01 14:03 ` Shuai Xue
2025-03-01 18:47 ` Borislav Petkov
2025-03-02 7:14 ` Shuai Xue
2025-03-02 7:37 ` Borislav Petkov
2025-03-02 9:13 ` Shuai Xue
2025-03-03 16:49 ` Luck, Tony
2025-03-03 18:08 ` Yazen Ghannam
2025-03-05 1:50 ` Shuai Xue
2025-03-05 16:16 ` Luck, Tony
2025-03-05 22:33 ` Luck, Tony
2025-03-06 15:58 ` Yazen Ghannam
2025-02-17 6:33 ` [PATCH v2 3/5] x86/mce: add EX_TYPE_EFAULT_REG as in-kernel recovery context to fix copy-from-user operations regression Shuai Xue
2025-02-18 12:54 ` Peter Zijlstra
2025-02-18 13:02 ` Peter Zijlstra
2025-02-18 14:03 ` Shuai Xue
2025-02-18 13:28 ` Shuai Xue
2025-02-18 14:15 ` Peter Zijlstra
2025-02-18 16:48 ` Borislav Petkov
2025-02-19 10:40 ` Peter Zijlstra
2025-02-21 6:52 ` Shuai Xue
2025-02-17 6:33 ` [PATCH v2 4/5] mm/hwpoison: Fix incorrect "not recovered" report for recovered clean pages Shuai Xue
2025-02-19 6:34 ` Miaohe Lin
2025-02-19 8:54 ` Shuai Xue
2025-02-19 17:15 ` Luck, Tony
2025-02-20 1:16 ` Miaohe Lin
2025-02-17 6:33 ` [PATCH v2 5/5] mm: memory-failure: move return value documentation to function declaration Shuai Xue
2025-02-19 6:31 ` Miaohe Lin
2025-02-18 3:29 ` [PATCH v2 0/5] mm/hwpoison: Fix regressions in memory failure handling Andrew Morton
2025-02-18 8:03 ` Borislav Petkov
2025-02-18 8:27 ` Borislav Petkov
2025-02-18 11:31 ` Shuai Xue
2025-02-18 12:24 ` Borislav Petkov
2025-02-18 13:08 ` Shuai Xue
2025-02-18 13:17 ` Borislav Petkov
2025-02-18 13:53 ` Shuai Xue
2025-02-18 15:31 ` Borislav Petkov
2025-02-19 7:13 ` Shuai Xue
2025-02-18 17:59 ` Luck, Tony
2025-02-19 6:04 ` Shuai Xue
2025-02-18 17:30 ` Luck, Tony
2025-02-19 8:10 ` Borislav Petkov
2025-02-19 17:11 ` Luck, Tony
2025-02-20 11:19 ` Borislav Petkov
2025-02-20 17:50 ` Luck, Tony
2025-02-21 6:05 ` Shuai Xue
2025-02-24 22:01 ` Borislav Petkov
2025-02-25 1:51 ` Shuai Xue
2025-02-28 12:35 ` Borislav Petkov
2025-03-01 5:54 ` Shuai Xue [this message]
2025-02-24 21:50 ` Borislav Petkov
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=d41853e8-0594-4359-bba7-18969725d8ac@linux.alibaba.com \
--to=xueshuai@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=nao.horiguchi@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tianruidong@linux.alibaba.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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.