From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, nao.horiguchi@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
akpm@linux-foundation.org, shuah@kernel.org
Subject: Re: [PATCH 0/3] selftests/mm: add memory failure selftests
Date: Mon, 12 Jan 2026 10:40:49 +0100 [thread overview]
Message-ID: <693dc9aa-cf86-48c7-be9c-ec554f9da855@kernel.org> (raw)
In-Reply-To: <2ae04380-fd60-a8a1-6217-386454fec610@huawei.com>
On 1/12/26 10:19, Miaohe Lin wrote:
> On 2026/1/9 21:45, David Hildenbrand (Red Hat) wrote:
>> On 1/7/26 10:37, Miaohe Lin wrote:
>>> Introduce selftests to validate the functionality of memory failure.
>>> These tests help ensure that memory failure handling for anonymous
>>> pages, pagecaches pages works correctly, including proper SIGBUS
>>> delivery to user processes, page isolation, and recovery paths.
>>>
>>> Currently madvise syscall is used to inject memory failures. And only
>>> anonymous pages and pagecaches are tested. More test scenarios, e.g.
>>> hugetlb, shmem, thp, will be added. Also more memory failure injecting
>>> methods will be supported, e.g. APEI Error INJection, if required.
>>
>
> Thanks for test and report. :)
>
>> 0day reports that these tests fail:
>>
>> # # ------------------------
>> # # running ./memory-failure
>> # # ------------------------
>> # # TAP version 13
>> # # 1..6
>> # # # Starting 6 tests from 2 test cases.
>> # # # RUN memory_failure.madv_hard.anon ...
>> # # # OK memory_failure.madv_hard.anon
>> # # ok 1 memory_failure.madv_hard.anon
>> # # # RUN memory_failure.madv_hard.clean_pagecache ...
>> # # # memory-failure.c:166:clean_pagecache:Expected setjmp (1) == 0 (0)
>> # # # clean_pagecache: Test terminated by assertion
>> # # # FAIL memory_failure.madv_hard.clean_pagecache
>> # # not ok 2 memory_failure.madv_hard.clean_pagecache
>> # # # RUN memory_failure.madv_hard.dirty_pagecache ...
>> # # # memory-failure.c:207:dirty_pagecache:Expected unpoison_memory(self->pfn) (-16) == 0 (0)
>> # # # dirty_pagecache: Test terminated by assertion
>> # # # FAIL memory_failure.madv_hard.dirty_pagecache
>> # # not ok 3 memory_failure.madv_hard.dirty_pagecache
>> # # # RUN memory_failure.madv_soft.anon ...
>> # # # OK memory_failure.madv_soft.anon
>> # # ok 4 memory_failure.madv_soft.anon
>> # # # RUN memory_failure.madv_soft.clean_pagecache ...
>> # # # memory-failure.c:282:clean_pagecache:Expected variant->inject(self, addr) (-1) == 0 (0)
>> # # # clean_pagecache: Test terminated by assertion
>> # # # FAIL memory_failure.madv_soft.clean_pagecache
>> # # not ok 5 memory_failure.madv_soft.clean_pagecache
>> # # # RUN memory_failure.madv_soft.dirty_pagecache ...
>> # # # memory-failure.c:319:dirty_pagecache:Expected variant->inject(self, addr) (-1) == 0 (0)
>> # # # dirty_pagecache: Test terminated by assertion
>> # # # FAIL memory_failure.madv_soft.dirty_pagecache
>> # # not ok 6 memory_failure.madv_soft.dirty_pagecache
>> # # # FAILED: 2 / 6 tests passed.
>> # # # Totals: pass:2 fail:4 xfail:0 xpass:0 skip:0 error:0
>> # # [FAIL]
>> # not ok 71 memory-failure # exit=1
>>
>>
>> Can the test maybe not deal with running in certain environments (config options etc)?
>
> To run the test, I think there should be:
> 1.CONFIG_MEMORY_FAILURE and CONFIG_HWPOISON_INJECT should be enabled.
> 2.Root privilege is required.
> 3.For dirty/clean pagecache testcases, the test file "./clean-page-cache-test-file" and
> "./dirty-page-cache-test-file" are assumed to be created on non-memory file systems
> such as xfs, ext4, etc.
>
> Does your test environment break any of the above rules?
It is 0day environment, so very likely yes. I suspect 1).
> Am I expected to add some code to
> guard against this?
Yes, at least some.
Checking for root privileges is not required. The tests are commonly run
from non-memory file systems, but, in theory, could be run from nfs etc.
If you require special file systems, take a look at gup_longterm.o where
we test for some fileystsem types.
Regarding 1): tools/testing/selftests/mm/config includes the config
options we expect to be set for running MM tests. Extending that might
take a while until environments like 0day would pick up such changes. If
you require something else, make your test SKIP tests if the relevant
kernel support is not there (e.g., sense support and conditionally skip).
--
Cheers
David
next prev parent reply other threads:[~2026-01-12 9:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 9:37 Miaohe Lin
2026-01-07 9:37 ` [PATCH 1/3] selftests/mm: add memory failure anonymous page test Miaohe Lin
2026-01-07 9:37 ` [PATCH 2/3] selftests/mm: add memory failure clean pagecache test Miaohe Lin
2026-01-07 9:37 ` [PATCH 3/3] selftests/mm: add memory failure dirty " Miaohe Lin
2026-01-09 13:45 ` [PATCH 0/3] selftests/mm: add memory failure selftests David Hildenbrand (Red Hat)
2026-01-12 9:19 ` Miaohe Lin
2026-01-12 9:40 ` David Hildenbrand (Red Hat) [this message]
2026-01-12 11:33 ` Miaohe Lin
2026-01-12 12:44 ` Miaohe Lin
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=693dc9aa-cf86-48c7-be9c-ec554f9da855@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=nao.horiguchi@gmail.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox