From: David Hildenbrand <david@redhat.com>
To: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>, linux-mm@kvack.org
Cc: Peter Xu <peterx@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Axel Rasmussen <axelrasmussen@google.com>
Subject: Re: BUG selftests/mm]
Date: Mon, 11 Mar 2024 10:31:41 +0100 [thread overview]
Message-ID: <4a5c8d28-7f73-4c15-b288-641f0ccc91c2@redhat.com> (raw)
In-Reply-To: <a9e3120d-8b79-4435-b113-ceb20aa45ee2@alu.unizg.hr>
On 09.03.24 20:12, Mirsad Todorovac wrote:
> Hi,
>
> Routine run of the test in net-next gave also this mm unit error.
>
> root@defiant:tools/testing/selftests/mm# ./uffd-unit-tests
> Testing UFFDIO_API (with syscall)... done
> Testing UFFDIO_API (with /dev/userfaultfd)... done
> Testing register-ioctls on anon... done
> Testing register-ioctls on shmem... done
> Testing register-ioctls on shmem-private... done
> Testing register-ioctls on hugetlb... skipped [reason: memory allocation failed]
> Testing register-ioctls on hugetlb-private... skipped [reason: memory allocation failed]
> Testing zeropage on anon... done
> Testing zeropage on shmem... done
> Testing zeropage on shmem-private... done
> Testing zeropage on hugetlb... skipped [reason: memory allocation failed]
> Testing zeropage on hugetlb-private... skipped [reason: memory allocation failed]
> Testing move on anon... done
> Testing move-pmd on anon... done
> Testing move-pmd-split on anon... done
> Testing wp-fork on anon... done
> Testing wp-fork on shmem... done
> Testing wp-fork on shmem-private... done
> Testing wp-fork on hugetlb... skipped [reason: memory allocation failed]
> Testing wp-fork on hugetlb-private... skipped [reason: memory allocation failed]
> Testing wp-fork-with-event on anon... done
> Testing wp-fork-with-event on shmem... done
> Testing wp-fork-with-event on shmem-private... done
> Testing wp-fork-with-event on hugetlb... skipped [reason: memory allocation failed]
> Testing wp-fork-with-event on hugetlb-private... skipped [reason: memory allocation failed]
> Testing wp-fork-pin on anon... done
> Testing wp-fork-pin on shmem... done
> Testing wp-fork-pin on shmem-private... done
> Testing wp-fork-pin on hugetlb... skipped [reason: memory allocation failed]
> Testing wp-fork-pin on hugetlb-private... skipped [reason: memory allocation failed]
> Testing wp-fork-pin-with-event on anon... done
> Testing wp-fork-pin-with-event on shmem... done
> Testing wp-fork-pin-with-event on shmem-private... done
> Testing wp-fork-pin-with-event on hugetlb... skipped [reason: memory allocation failed]
> Testing wp-fork-pin-with-event on hugetlb-private... skipped [reason: memory allocation failed]
> Testing wp-unpopulated on anon... done
> Testing minor on shmem... done
> Testing minor on hugetlb... skipped [reason: memory allocation failed]
> Testing minor-wp on shmem... done
> Testing minor-wp on hugetlb... skipped [reason: memory allocation failed]
> Testing minor-collapse on shmem... done
> Testing sigbus on anon... done
> Testing sigbus on shmem... done
> Testing sigbus on shmem-private... done
> Testing sigbus on hugetlb... skipped [reason: memory allocation failed]
> Testing sigbus on hugetlb-private... skipped [reason: memory allocation failed]
> Testing sigbus-wp on anon... done
> Testing sigbus-wp on shmem... done
> Testing sigbus-wp on shmem-private... done
> Testing sigbus-wp on hugetlb... skipped [reason: memory allocation failed]
> Testing sigbus-wp on hugetlb-private... skipped [reason: memory allocation failed]
> Testing events on anon... done
> Testing events on shmem... done
> Testing events on shmem-private... done
> Testing events on hugetlb... skipped [reason: memory allocation failed]
> Testing events on hugetlb-private... skipped [reason: memory allocation failed]
> Testing events-wp on anon... done
> Testing events-wp on shmem... done
> Testing events-wp on shmem-private... done
> Testing events-wp on hugetlb... skipped [reason: memory allocation failed]
> Testing events-wp on hugetlb-private... skipped [reason: memory allocation failed]
> Testing poison on anon... done
> Testing poison on shmem... done
> Testing poison on shmem-private... done
> Testing poison on hugetlb... skipped [reason: memory allocation failed]
> Testing poison on hugetlb-private... skipped [reason: memory allocation failed]
> Userfaults unit tests: pass=42, skip=24, fail=0 (total=66)
> root@defiant:tools/testing/selftests/mm# grep -i huge /proc/meminfo
>
> It resulted in alarming errors in the syslog:
>
> Mar 9 19:48:24 defiant kernel: [77187.055103] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4631e000
> Mar 9 19:48:24 defiant kernel: [77187.055132] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46320000
> Mar 9 19:48:24 defiant kernel: [77187.055160] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46322000
> Mar 9 19:48:24 defiant kernel: [77187.055189] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46324000
> Mar 9 19:48:24 defiant kernel: [77187.055218] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46326000
> Mar 9 19:48:24 defiant kernel: [77187.055250] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46328000
> Mar 9 19:48:24 defiant kernel: [77187.055278] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4632a000
> Mar 9 19:48:24 defiant kernel: [77187.055307] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4632c000
> Mar 9 19:48:24 defiant kernel: [77187.055336] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4632e000
> Mar 9 19:48:24 defiant kernel: [77187.055366] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46330000
> Mar 9 19:48:24 defiant kernel: [77187.055395] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46332000
> Mar 9 19:48:24 defiant kernel: [77187.055423] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46334000
> Mar 9 19:48:24 defiant kernel: [77187.055452] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46336000
> Mar 9 19:48:24 defiant kernel: [77187.055480] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46338000
> Mar 9 19:48:24 defiant kernel: [77187.055509] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4633a000
> Mar 9 19:48:24 defiant kernel: [77187.055538] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4633c000
> Mar 9 19:48:24 defiant kernel: [77187.055567] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 4633e000
> Mar 9 19:48:24 defiant kernel: [77187.055597] MCE: Killing uffd-unit-tests:1321817 due to hardware memory corruption fault at 46340000
>
> At this point, it can be problem with my box's memory chips, or something with HUGETLB.
>
> However, since the "classic" allocations were successful, the problem might be in huge pages, or
> if I understood well, in deliberate poisoning of pages?
>
Isn't that just the (expected) side effect of UFFDIO_POISON tests?
IOW, there is no problem here. We are poisoning virtual memory locations
(not actual memory) and expect a SIGBUS on next access. While testing
that, we receive these messages.
The "ugly" thing here seems to be that we can trigger repeated pr_err()
from user space. There is no rate-limiting in place. Maybe UFFDIO_POISON
requires root permissions so this cannot be exploited by unprivileged
user space to flood the system log?
CCing Axel
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-03-11 9:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-09 19:12 Mirsad Todorovac
2024-03-11 9:31 ` David Hildenbrand [this message]
2024-03-11 14:35 ` Peter Xu
2024-03-11 14:48 ` David Hildenbrand
2024-03-11 15:12 ` Peter Xu
2024-03-11 18:59 ` Axel Rasmussen
2024-03-11 19:28 ` Peter Xu
2024-03-11 21:26 ` James Houghton
2024-03-11 22:28 ` Jiaqi Yan
2024-03-12 15:38 ` Peter Xu
2024-03-12 16:47 ` Axel Rasmussen
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=4a5c8d28-7f73-4c15-b288-641f0ccc91c2@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mirsad.todorovac@alu.unizg.hr \
--cc=peterx@redhat.com \
--cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox