[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B8B7E3FA-6EAB-46B7-95EB-5A31395C8ADE@vmware.com>
Date: Mon, 15 Nov 2021 11:04:16 +0000
From: Alexey Makhalov <amakhalov@...are.com>
To: Michal Hocko <mhocko@...e.com>
CC: Dennis Zhou <dennis@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"cl@...ux.com" <cl@...ux.com>,
"mm-commits@...r.kernel.org" <mm-commits@...r.kernel.org>,
"osalvador@...e.de" <osalvador@...e.de>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"tj@...nel.org" <tj@...nel.org>
Subject: Re: + mm-fix-panic-in-__alloc_pages.patch added to -mm tree
Hi Michal,
>
> I have asked several times for details about the specific setup that has
> led to the reported crash. Without much success so far. Reproduction
> steps would be the first step. That would allow somebody to work on this
> at least if Alexey doesn't have time to dive into this deeper.
>
I didn’t know that repro steps are still not clear.
To reproduce the panic you need to have a system, where you can hot add
the CPU that belongs to memoryless NUMA node which is not present and onlined
yet. In other words, by hot adding CPU, you will add both CPU and NUMA node
at the same time.
I’m using VMware hypervisor and linux VM there configured in a way
that every (possible) CPU has its own NUMA node.
Before doing CPU hot add, udev rule for CPU onlining should be disabled.
After CPU hot add event, panic will be triggered shortly right on the next
percpu allocation.
Let me know if this is enough or you need some extra information.
Thanks,
—Alexey
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists