9:18 a.m.
Hi, Rongwei
Thank you for the patch.
On Tue, May 16, 2023 at 8:00 PM <crash-utility-request(a)redhat.com> wrote:
Date: Tue, 16 May 2023 19:40:54 +0800
From: Rongwei Wang <rongwei.wang(a)linux.alibaba.com>
To: crash-utility(a)redhat.com, k-hagio-ab(a)nec.com
Subject: [Crash-utility] [PATCH v3] arm64/x86_64: show zero pfn
information when using vtop
Message-ID: <20230516114054.63844-1-rongwei.wang(a)linux.alibaba.com>
Content-Type: text/plain; charset="US-ASCII"; x-default=true
Now vtop can not show us the page is zero pfn
when PTE or PMD has attached ZERO PAGE. This
patch supports show this information directly
when using vtop, likes:
crash> vtop -c 13674 ffff8917e000
VIRTUAL PHYSICAL
ffff8917e000 836e71000
PAGE DIRECTORY: ffff000802f8d000
PGD: ffff000802f8dff8 => 884e29003
PUD: ffff000844e29ff0 => 884e93003
PMD: ffff000844e93240 => 840413003
PTE: ffff000800413bf0 => 160000836e71fc3
PAGE: 836e71000 (ZERO PAGE)
...
If huge page found:
crash> vtop -c 14538 ffff95800000
VIRTUAL PHYSICAL
ffff95800000 910c00000
PAGE DIRECTORY: ffff000801fa0000
PGD: ffff000801fa0ff8 => 884f53003
PUD: ffff000844f53ff0 => 8426cb003
PMD: ffff0008026cb560 => 60000910c00fc1
PAGE: 910c00000 (2MB, ZERO PAGE)
...
I did some tests on x86 64 and aarch64 machines, and got the following
results.
[1] on x86 64, it does not print the "ZERO PAGE" when using 1G huge pages.
(but for 2M huge page, it works)
crash> vtop -c 2763 7fdfc0000000
VIRTUAL PHYSICAL
7fdfc0000000 300000000
PGD: 23b9ae7f8 => 8000000235031067
PUD: 235031bf8 => 80000003000008e7
PAGE: 300000000 (1GB)
PTE PHYSICAL FLAGS
80000003000008e7 300000000 (PRESENT|RW|USER|ACCESSED|DIRTY|PSE|NX)
VMA START END FLAGS FILE
ffff9d65fc8a85c0 7fdfc0000000 7fe000000000 84400fb /mnt/hugetlbfs/test
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffef30cc000000 300000000 ffff9d65f5c35850 0 2 57ffffc001000c
uptodate,dirty,head
crash> help -v|grep zero
zero_paddr: 221a37000
huge_zero_paddr: 240000000
[2] on aarch64, it does not print the "ZERO PAGE"
crash> vtop -c 23390 ffff8d600000
VIRTUAL PHYSICAL
ffff8d600000 cc800000
PAGE DIRECTORY: ffff224ba02d9000
PGD: ffff224ba02d9ff8 => 80000017b38f003
PUD: ffff224b7b38fff0 => 80000017b38e003
PMD: ffff224b7b38e358 => e80000cc800f41
PAGE: cc800000 (2MB)
PTE PHYSICAL FLAGS
e80000cc800f41 cc800000 (VALID|USER|SHARED|AF|NG|PXN|UXN|DIRTY)
VMA START END FLAGS FILE
ffff224bb315f678 ffff8d600000 ffff8d800000 4400fb /mnt/hugetlbfs/test
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffc892b320000 cc800000 ffff224b5c48ac90 0 2 7ffff80001000c
uptodate,dirty,head
crash> help -v|grep zero
zero_paddr: 142662000
huge_zero_paddr: 111400000
I have one question: can this patch print "ZERO PAGE" on x86 64 when using
1G huge pages? Or is it expected behavior on x86 64?
And It does not work on aarch64 machine to me. Did I miss anything else?
Thanks
Lianbo
6:26 p.m.
New subject: [PATCH v3] arm64/x86_64: show zero pfn information when using vtop
On 2023/5/24 22:18, lijiang wrote:
Hi, Rongwei
Thank you for the patch.
On Tue, May 16, 2023 at 8:00 PM <crash-utility-request(a)redhat.com> wrote:
Date: Tue, 16 May 2023 19:40:54 +0800
From: Rongwei Wang <rongwei.wang(a)linux.alibaba.com>
To: crash-utility(a)redhat.com, k-hagio-ab(a)nec.com
Subject: [Crash-utility] [PATCH v3] arm64/x86_64: show zero pfn
information when using vtop
Message-ID: <20230516114054.63844-1-rongwei.wang(a)linux.alibaba.com>
Content-Type: text/plain; charset="US-ASCII"; x-default=true
Now vtop can not show us the page is zero pfn
when PTE or PMD has attached ZERO PAGE. This
patch supports show this information directly
when using vtop, likes:
crash> vtop -c 13674 ffff8917e000
VIRTUAL PHYSICAL
ffff8917e000 836e71000
PAGE DIRECTORY: ffff000802f8d000
PGD: ffff000802f8dff8 => 884e29003
PUD: ffff000844e29ff0 => 884e93003
PMD: ffff000844e93240 => 840413003
PTE: ffff000800413bf0 => 160000836e71fc3
PAGE: 836e71000 (ZERO PAGE)
...
If huge page found:
crash> vtop -c 14538 ffff95800000
VIRTUAL PHYSICAL
ffff95800000 910c00000
PAGE DIRECTORY: ffff000801fa0000
PGD: ffff000801fa0ff8 => 884f53003
PUD: ffff000844f53ff0 => 8426cb003
PMD: ffff0008026cb560 => 60000910c00fc1
PAGE: 910c00000 (2MB, ZERO PAGE)
...
I did some tests on x86 64 and aarch64 machines, and got the following
results.
[1] on x86 64, it does not print the "ZERO PAGE" when using 1G huge
pages. (but for 2M huge page, it works)
crash> vtop -c 2763 7fdfc0000000
VIRTUAL PHYSICAL
7fdfc0000000 300000000
PGD: 23b9ae7f8 => 8000000235031067
PUD: 235031bf8 => 80000003000008e7
PAGE: 300000000 (1GB)
PTE PHYSICAL FLAGS
80000003000008e7 300000000 (PRESENT|RW|USER|ACCESSED|DIRTY|PSE|NX)
VMA START END FLAGS FILE
ffff9d65fc8a85c0 7fdfc0000000 7fe000000000 84400fb /mnt/hugetlbfs/test
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffef30cc000000 300000000 ffff9d65f5c35850 0 2 57ffffc001000c
uptodate,dirty,head
crash> help -v|grep zero
zero_paddr: 221a37000
huge_zero_paddr: 240000000
[2] on aarch64, it does not print the "ZERO PAGE"
crash> vtop -c 23390 ffff8d600000
VIRTUAL PHYSICAL
ffff8d600000 cc800000
PAGE DIRECTORY: ffff224ba02d9000
PGD: ffff224ba02d9ff8 => 80000017b38f003
PUD: ffff224b7b38fff0 => 80000017b38e003
PMD: ffff224b7b38e358 => e80000cc800f41
PAGE: cc800000 (2MB)
PTE PHYSICAL FLAGS
e80000cc800f41 cc800000 (VALID|USER|SHARED|AF|NG|PXN|UXN|DIRTY)
VMA START END FLAGS FILE
ffff224bb315f678 ffff8d600000 ffff8d800000 4400fb /mnt/hugetlbfs/test
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffc892b320000 cc800000 ffff224b5c48ac90 0 2 7ffff80001000c
uptodate,dirty,head
crash> help -v|grep zero
zero_paddr: 142662000
huge_zero_paddr: 111400000
I have one question: can this patch print "ZERO PAGE" on x86 64 when
using 1G huge pages? Or is it expected behavior on x86 64?
And It does not work on aarch64 machine to me. Did I miss anything else?
Hi, lijiang
I find you use '/mnt/hugetlbfs/test' to test this patch, but I have not
do this on hugetlbfs, just support THP (I indeed ignore the hugetlb when
coding this function).
And I have read mm/hugetlb.c roughly, not find any zero page stuff when
page fault with read. It seems that hugetlb is not an angel user of this
function.
If I miss something, please let me know.
Thanks for your time!
-wrw
Thanks
Lianbo
7:18 a.m.
New subject: [PATCH v3] arm64/x86_64: show zero pfn information when using vtop
On Thu, May 25, 2023 at 7:27 AM Rongwei Wang <rongwei.wang(a)linux.alibaba.com>
wrote:
On 2023/5/24 22:18, lijiang wrote:
Hi, Rongwei
Thank you for the patch.
On Tue, May 16, 2023 at 8:00 PM <crash-utility-request(a)redhat.com> wrote:
> Date: Tue, 16 May 2023 19:40:54 +0800
> From: Rongwei Wang <rongwei.wang(a)linux.alibaba.com>
> To: crash-utility(a)redhat.com, k-hagio-ab(a)nec.com
> Subject: [Crash-utility] [PATCH v3] arm64/x86_64: show zero pfn
> information when using vtop
> Message-ID: <20230516114054.63844-1-rongwei.wang(a)linux.alibaba.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Now vtop can not show us the page is zero pfn
> when PTE or PMD has attached ZERO PAGE. This
> patch supports show this information directly
> when using vtop, likes:
>
> crash> vtop -c 13674 ffff8917e000
> VIRTUAL PHYSICAL
> ffff8917e000 836e71000
>
> PAGE DIRECTORY: ffff000802f8d000
> PGD: ffff000802f8dff8 => 884e29003
> PUD: ffff000844e29ff0 => 884e93003
> PMD: ffff000844e93240 => 840413003
> PTE: ffff000800413bf0 => 160000836e71fc3
> PAGE: 836e71000 (ZERO PAGE)
> ...
>
> If huge page found:
>
> crash> vtop -c 14538 ffff95800000
> VIRTUAL PHYSICAL
> ffff95800000 910c00000
>
> PAGE DIRECTORY: ffff000801fa0000
> PGD: ffff000801fa0ff8 => 884f53003
> PUD: ffff000844f53ff0 => 8426cb003
> PMD: ffff0008026cb560 => 60000910c00fc1
> PAGE: 910c00000 (2MB, ZERO PAGE)
> ...
>
>
I did some tests on x86 64 and aarch64 machines, and got the following
results.
[1] on x86 64, it does not print the "ZERO PAGE" when using 1G huge pages.
(but for 2M huge page, it works)
crash> vtop -c 2763 7fdfc0000000
VIRTUAL PHYSICAL
7fdfc0000000 300000000
PGD: 23b9ae7f8 => 8000000235031067
PUD: 235031bf8 => 80000003000008e7
PAGE: 300000000 (1GB)
PTE PHYSICAL FLAGS
80000003000008e7 300000000 (PRESENT|RW|USER|ACCESSED|DIRTY|PSE|NX)
VMA START END FLAGS FILE
ffff9d65fc8a85c0 7fdfc0000000 7fe000000000 84400fb /mnt/hugetlbfs/test
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffef30cc000000 300000000 ffff9d65f5c35850 0 2 57ffffc001000c
uptodate,dirty,head
crash> help -v|grep zero
zero_paddr: 221a37000
huge_zero_paddr: 240000000
[2] on aarch64, it does not print the "ZERO PAGE"
crash> vtop -c 23390 ffff8d600000
VIRTUAL PHYSICAL
ffff8d600000 cc800000
PAGE DIRECTORY: ffff224ba02d9000
PGD: ffff224ba02d9ff8 => 80000017b38f003
PUD: ffff224b7b38fff0 => 80000017b38e003
PMD: ffff224b7b38e358 => e80000cc800f41
PAGE: cc800000 (2MB)
PTE PHYSICAL FLAGS
e80000cc800f41 cc800000 (VALID|USER|SHARED|AF|NG|PXN|UXN|DIRTY)
VMA START END FLAGS FILE
ffff224bb315f678 ffff8d600000 ffff8d800000 4400fb /mnt/hugetlbfs/test
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffc892b320000 cc800000 ffff224b5c48ac90 0 2 7ffff80001000c
uptodate,dirty,head
crash> help -v|grep zero
zero_paddr: 142662000
huge_zero_paddr: 111400000
I have one question: can this patch print "ZERO PAGE" on x86 64 when
using 1G huge pages? Or is it expected behavior on x86 64?
And It does not work on aarch64 machine to me. Did I miss anything else?
Hi, lijiang
I find you use '/mnt/hugetlbfs/test' to test this patch, but I have not do
this on hugetlbfs, just support THP (I
You are right, Rongwei. Because the z.c test case does not work on my
machines, I wrote two test cases by myself.
z.c: https://listman.redhat.com/archives/crash-utility/2023-May/010666.html
my test cases:
[1] use the mmap() to map the memory(without the *MAP_HUGETLB* flag):
ptr = mmap(NULL, map_len, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
[2] use the madvise() as below:
posix_memalign(&ptr, huge_page_size, n);
madvise(ptr, n, MADV_HUGEPAGE);
And then read data from ptr, the [1] and [2] both can work on my X86 64
machines for 2M hugepage.
But for the 1G hugepage, I did not see the similar code change in your
patch, do you mean that this patch doesn't support for the 1G hugepage?
I can confirm that the 1G hugepage is supported on my X86 64 machine:
# cat /proc/meminfo |grep -i huge
AnonHugePages: 407552 kB
ShmemHugePages: 0 kB
FileHugePages: 63488 kB
HugePages_Total: 10
HugePages_Free: 10
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 1048576 kB
Hugetlb: 10485760 kB
indeed ignore the hugetlb when coding this function).
And I have read mm/hugetlb.c roughly, not find any zero page stuff when
page fault with read. It seems that hugetlb is not an angel user of this
function.
If the current patch does not support printing "ZERO PAGE" information
when
using hugetlbfs, it should be good to describe it in patch log(and explain
a bit *why* if possible).
If I miss something, please let me know.
BTW: could you please check the z.c test case again? Or can you share your
steps in
detail, that can help me speed up the tests on X86 64(4k/2M/1G)
and aarch64(4k or 64k/2M/512M/1G) machines.
# gcc -o z z.c
[root@hp-z640-01 crash]# ./z
zero: 7efe4cbff010 ---seems the address is problematic, not aligned
hello
Thanks.
Lianbo
Thanks for your time!
-wrw
Thanks
Lianbo
8:43 a.m.
New subject: [PATCH v3] arm64/x86_64: show zero pfn information when using vtop
On 2023/5/25 20:18, lijiang wrote:
On Thu, May 25, 2023 at 7:27 AM Rongwei Wang
<rongwei.wang(a)linux.alibaba.com> wrote:
On 2023/5/24 22:18, lijiang wrote:
> Hi, Rongwei
> Thank you for the patch.
> On Tue, May 16, 2023 at 8:00 PM
> <crash-utility-request(a)redhat.com> wrote:
>
> Date: Tue, 16 May 2023 19:40:54 +0800
> From: Rongwei Wang <rongwei.wang(a)linux.alibaba.com>
> To: crash-utility(a)redhat.com, k-hagio-ab(a)nec.com
> Subject: [Crash-utility] [PATCH v3] arm64/x86_64: show zero pfn
> information when using vtop
> Message-ID:
> <20230516114054.63844-1-rongwei.wang(a)linux.alibaba.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Now vtop can not show us the page is zero pfn
> when PTE or PMD has attached ZERO PAGE. This
> patch supports show this information directly
> when using vtop, likes:
>
> crash> vtop -c 13674 ffff8917e000
> VIRTUAL PHYSICAL
> ffff8917e000 836e71000
>
> PAGE DIRECTORY: ffff000802f8d000
> PGD: ffff000802f8dff8 => 884e29003
> PUD: ffff000844e29ff0 => 884e93003
> PMD: ffff000844e93240 => 840413003
> PTE: ffff000800413bf0 => 160000836e71fc3
> PAGE: 836e71000 (ZERO PAGE)
> ...
>
> If huge page found:
>
> crash> vtop -c 14538 ffff95800000
> VIRTUAL PHYSICAL
> ffff95800000 910c00000
>
> PAGE DIRECTORY: ffff000801fa0000
> PGD: ffff000801fa0ff8 => 884f53003
> PUD: ffff000844f53ff0 => 8426cb003
> PMD: ffff0008026cb560 => 60000910c00fc1
> PAGE: 910c00000 (2MB, ZERO PAGE)
> ...
>
>
> I did some tests on x86 64 and aarch64 machines, and got the
> following results.
>
> [1] on x86 64, it does not print the "ZERO PAGE" when using 1G
> huge pages. (but for 2M huge page, it works)
Hi, lijiang
Sorry, It seems that I miss here when I replying your previous email.
You mean 2M hugetlb will show "ZERO PAGE" when testing my patch? IMHO, I
re-read mm/hugetlb.c under kernel, but still not find any place of
allocating zero page. It's something unexpected for me.
And I test 2M hugetlb in my environment, not find "ZERO PAGE":
crash> vtop -c 4400 ffff83200000
VIRTUAL PHYSICAL
ffff83200000 10ca00000
PAGE DIRECTORY: ffff0007f860e000
PGD: ffff0007f860eff8 => 1081c3003
PUD: ffff0000c81c3ff0 => 83860c003
PMD: ffff0007f860c0c8 => 6000010ca00fc1
PAGE: 10ca00000 (2MB) <---here
my hugetlb testcase as below:
#include <sys/mman.h>
#include <stdio.h>
#include <memory.h>
int main(int argc, char *argv[])
{
char *m;
size_t s = (8UL * 1024 * 1024);
unsigned long i;
char val;
m = mmap(NULL, s, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
if (m == MAP_FAILED) {
perror("map mem");
m = NULL;
return 1;
}
for (i=0; i<s; i+=4096) {
val = *(m+i);
}
printf("addr: 0x%lx\n", (unsigned long)m);
printf("map_hugetlb ok, press ENTER to quit!\n");
getchar();
munmap(m, s);
return 0;
}
Can you help make sure the behavior of 2M hugetlb again?
> crash> vtop -c 2763 7fdfc0000000
> VIRTUAL PHYSICAL
> 7fdfc0000000 300000000
>
> PGD: 23b9ae7f8 => 8000000235031067
> PUD: 235031bf8 => 80000003000008e7
> PAGE: 300000000 (1GB)
>
> PTE PHYSICAL FLAGS
> 80000003000008e7 300000000 (PRESENT|RW|USER|ACCESSED|DIRTY|PSE|NX)
>
> VMA START END FLAGS FILE
> ffff9d65fc8a85c0 7fdfc0000000 7fe000000000 84400fb
> /mnt/hugetlbfs/test
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffef30cc000000 300000000 ffff9d65f5c35850 0 2 57ffffc001000c
> uptodate,dirty,head
>
> crash> help -v|grep zero
> zero_paddr: 221a37000
> huge_zero_paddr: 240000000
>
> [2] on aarch64, it does not print the "ZERO PAGE"
> crash> vtop -c 23390 ffff8d600000
> VIRTUAL PHYSICAL
> ffff8d600000 cc800000
>
> PAGE DIRECTORY: ffff224ba02d9000
> PGD: ffff224ba02d9ff8 => 80000017b38f003
> PUD: ffff224b7b38fff0 => 80000017b38e003
> PMD: ffff224b7b38e358 => e80000cc800f41
> PAGE: cc800000 (2MB)
>
> PTE PHYSICAL FLAGS
> e80000cc800f41 cc800000 (VALID|USER|SHARED|AF|NG|PXN|UXN|DIRTY)
>
> VMA START END FLAGS FILE
> ffff224bb315f678 ffff8d600000 ffff8d800000 4400fb /mnt/hugetlbfs/test
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fffffc892b320000 cc800000 ffff224b5c48ac90 0 2 7ffff80001000c
> uptodate,dirty,head
> crash> help -v|grep zero
> zero_paddr: 142662000
> huge_zero_paddr: 111400000
>
> I have one question: can this patch print "ZERO PAGE" on x86 64
> when using 1G huge pages? Or is it expected behavior on x86 64?
>
> And It does not work on aarch64 machine to me. Did I miss
> anything else?
Hi, lijiang
I find you use '/mnt/hugetlbfs/test' to test this patch, but I
have not do this on hugetlbfs, just support THP (I
You are right, Rongwei. Because the z.c test case does not work on my
machines, I wrote two test cases by myself.
z.c:
https://listman.redhat.com/archives/crash-utility/2023-May/010666.html
my test cases:
[1] use the mmap() to map the memory(without the *MAP_HUGETLB* flag):
ptr = mmap(NULL, map_len, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
[2] use the madvise() as below:
posix_memalign(&ptr, huge_page_size, n);
madvise(ptr, n, MADV_HUGEPAGE);
And then read data from ptr, the [1] and [2] both can work on my X86
64 machines for 2M hugepage.
But for the 1G hugepage, I did not see the similar code change in your
patch, do you mean that this patch doesn't support for the 1G hugepage?
IMHO, now linux kernel just support 1G hugetlb (no 1G THP), and
meanwhile, hugetlb has no ZERO PAGE stuff.
If I'm wrong here, please let me know.
Thanks for your careful review.
I can confirm that the 1G hugepage is supported on my X86 64 machine:
# cat /proc/meminfo |grep -i huge
AnonHugePages: 407552 kB
ShmemHugePages: 0 kB
FileHugePages: 63488 kB
HugePages_Total: 10
HugePages_Free: 10
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 1048576 kB
Hugetlb: 10485760 kB
indeed ignore the hugetlb when coding this function).
And I have read mm/hugetlb.c roughly, not find any zero page stuff
when page fault with read. It seems that hugetlb is not an angel
user of this function.
If the current patch does not support printing "ZERO PAGE" information
when using hugetlbfs, it should be good to describe it in patch
log(and explain a bit *why* if possible).
OK, I can update comments next.
If I miss something, please let me know.
BTW: could you please check the z.c test case again? Or can you share
your steps in detail, that can help me speed up the tests on X86
64(4k/2M/1G) and aarch64(4k or 64k/2M/512M/1G) machines.
# gcc -o z z.c
[root@hp-z640-01 crash]# ./z
zero: 7efe4cbff010 ---seems the address is problematic, not aligned
It's right, this address is directly return from malloc().
You can use 7efe4cc00000 or 7efe4cc01000 to check.
In a short, just use aligned (4k or 2M) address to test is ok.
Thanks,
-wrw
hello
Thanks.
Lianbo
Thanks for your time!
-wrw
>
> Thanks
> Lianbo
3:06 a.m.
New subject: [PATCH v3] arm64/x86_64: show zero pfn information when using vtop
On Thu, May 25, 2023 at 9:43 PM Rongwei Wang <rongwei.wang(a)linux.alibaba.com>
wrote:
On 2023/5/25 20:18, lijiang wrote:
Hi, lijiang
Sorry, It seems that I miss here when I replying your previous email.
You mean 2M hugetlb will show "ZERO PAGE" when testing my patch? IMHO, I
re-read mm/hugetlb.c
No. Because you mentioned that the patch does not support on hugetlbfs, I
have modified those two cases, refer to the: [1](without the *MAP_HUGETLB*
flag) and [2]:
https://listman.redhat.com/archives/crash-utility/2023-May/010696.html
And currently, the patch can work on the following cases:
[1] X86 64
[a] 4k page
[b] 2M hugepage
[2] aarch64
[a] 4k page
[b] 2M hugepage
[c] 64k-512M hugepage
For aarch64 [c], I can not test it because of Oops from kernel:
...
[ 37.939717] Internal error: Oops: 0000000096000006 [#1] SMP
[ 37.945288] Modules linked in: rfkill vfat fat nicvf cavium_rng_vf
cavium_ptp ast drm_shmem_helper i2c_algo_bit drm_kms_helper syscopyarea
sysfillrect sysimgblt nicpf ipmi_ssif cavium_rng ipmi_devintf
ipmi_msghandler fuse drm xfs libcrc32c sha2_ce crct10dif_ce ghash_ce
sha256_arm64 sha1_ce e1000e thunderx_zip thunder_bgx thunder_xcv
i2c_thunderx mdio_thunder mdio_cavium sg dm_mirror dm_region_hash dm_log
dm_mod
[ 37.981797] CPU: 7 PID: 1801 Comm: NetworkManager Not tainted 6.4.0-rc4+
#2
[ 37.988752] Hardware name: GIGABYTE R270-T61-V6-A/MT60-SC9-V6, BIOS F02
08/06/2019
[ 37.996312] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 38.003267] pc : __bitmap_weight_and+0x30/0xa0
[ 38.007719] lr : cpumask_weight_and+0x14/0x28
[ 38.012071] sp : fffffe00214cf270
[ 38.015377] x29: fffffe00214cf270 x28: fffffc01520f4c48 x27:
fffffc01520f4a28
[ 38.022511] x26: 0000000000000000 x25: fffffe0008100b30 x24:
0000000000000060
[ 38.029644] x23: fffffe0009b18c48 x22: 0000000000000000 x21:
0000000000000001
[ 38.036777] x20: 0000000000000000 x19: 0000000000000000 x18:
ffffffffffffffff
[ 38.043910] x17: 0000000000000000 x16: 0000000000000000 x15:
fffffe00a14cf33d
[ 38.051044] x14: ffffffffffffffff x13: 00302d7272652d74 x12:
0000000000000000
[ 38.058177] x11: ffffffffffffffc0 x10: 0000000000000040 x9 :
fffffe00085b77d0
[ 38.065311] x8 : fffffc01520f51e8 x7 : 0000000000000000 x6 :
0000000000000001
[ 38.072444] x5 : fffffc0128a44ac8 x4 : fffffe0008100b30 x3 :
0000000000000008
[ 38.079577] x2 : 0000000000000060 x1 : 0000000000000000 x0 :
fffffe0009b18c48
[ 38.086711] Call trace:
[ 38.089149] __bitmap_weight_and+0x30/0xa0
[ 38.093238] cpumask_weight_and+0x14/0x28
[ 38.097240] hop_cmp+0x30/0xa8
[ 38.100286] bsearch+0x48/0xa8
[ 38.103337] sched_numa_find_nth_cpu+0x80/0x138
[ 38.107864] cpumask_local_spread+0x30/0x90
[ 38.112049] nicvf_set_irq_affinity.constprop.0+0xa4/0x120 [nicvf]
[ 38.118250] nicvf_register_interrupts+0x2b8/0x2e0 [nicvf]
[ 38.123735] nicvf_open+0x258/0x5c0 [nicvf]
[ 38.127916] __dev_open+0xfc/0x210
[ 38.131314] __dev_change_flags+0x1c4/0x248
[ 38.135489] dev_change_flags+0x28/0x78
[ 38.139317] do_setlink+0x238/0xac0
[ 38.142801] __rtnl_newlink+0x430/0x518
[ 38.146629] rtnl_newlink+0x54/0x88
[ 38.150110] rtnetlink_rcv_msg+0x130/0x398
[ 38.154199] netlink_rcv_skb+0x60/0x130
[ 38.158031] rtnetlink_rcv+0x1c/0x30
[ 38.161605] netlink_unicast+0x2dc/0x338
[ 38.165519] netlink_sendmsg+0x1dc/0x448
[ 38.169434] sock_sendmsg+0x5c/0xb0
[ 38.172917] ____sys_sendmsg+0x1f0/0x2c0
[ 38.176832] ___sys_sendmsg+0x80/0xc8
[ 38.180489] __sys_sendmsg+0x5c/0xb0
[ 38.184056] __arm64_sys_sendmsg+0x28/0x38
[ 38.188144] invoke_syscall.constprop.0+0x7c/0xd0
[ 38.192851] el0_svc_common.constprop.0+0x13c/0x158
[ 38.197722] do_el0_svc+0x38/0xa8
[ 38.201030] el0_svc+0x3c/0x198
[ 38.204169] el0t_64_sync_handler+0xb4/0x130
[ 38.208432] el0t_64_sync+0x17c/0x180
[ 38.212092] Code: aa0003f7 34000395 d2800013 52800014 (f8737ac3)
[ 38.218181] ---[ end trace 0000000000000000 ]---
[ 38.222791] Kernel panic - not syncing: Oops: Fatal exception
[ 38.228529] SMP: stopping secondary CPUs
[ 38.232489] Kernel Offset: disabled
[ 38.235968] CPU features: 0x00e000,00280802,04005203
[ 38.240925] Memory Limit: none
[ 38.243973] ---[ end Kernel panic - not syncing: Oops: Fatal exception
]---
But it is another issue. And this patch looks good to me for now. Just one
thing: need add a few words to clarify them.
[1] it only supports displaying zero page for THP(except for 1G hugepage)
[2] and do not support for the hugetlb cases
So, for v3: Ack.
Thanks.
Lianbo
547
days inactive
552
days old
devel@lists.crash-utility.osci.io
4 comments
2 participants
participants (2)
-
lijiang -
Rongwei Wang