On 2023/11/08 19:00, lijiang wrote:
> Then "files -p" option also emits the same error?
>
>
Yes. It has the same error:
crash> files -p ffff8ea84c130938
INODE NRPAGES
ffff8ea84c130938 62527
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffff5168860d000 218340000 ffff8ea84c130ab0 0 5 17ffffc0012076
referenced,uptodate,lru,active,workingset,private,head
files: do_xarray: callback operation failed: entry: 1 item: 0
crash> files -n ffff8ea84c130938
INODE NRPAGES
ffff8ea84c130938 62527
files: do_xarray: callback operation failed: entry: 1 item: 0
>
Is that /proc/kcore? What is the kernel version?
>
>
Yes, the kernel version is 6.5.0-rc1.
Thanks, I found a 6.5 environment that could reproduce this.
crash> sys
KERNEL: /lib/modules/6.5.9/build/vmlinux
DUMPFILE: /proc/kcore
CPUS: 48
DATE: Wed Nov 8 23:03:48 EST 2023
UPTIME: 00:03:57
LOAD AVERAGE: 0.10, 0.21, 0.10
TASKS: 712
NODENAME: host
RELEASE: 6.5.9
VERSION: #1 SMP PREEMPT_DYNAMIC Mon Oct 30 22:15:13 EDT 2023
MACHINE: x86_64 (1800 Mhz)
MEMORY: 55.9 GB
crash> files -c
PID: 8102 TASK: ffff9570522e8000 CPU: 10 COMMAND: "crash"
ROOT: / CWD: /home/tools/crash
FD INODE I_MAPPING NRPAGES TYPE PATH
5 ffff95704e96e538 ffff95704e96e6b0 61979 REG /home/kernel/linux-6.5.9/vmlinux
crash> files -n ffff95704e96e538
INODE NRPAGES
ffff95704e96e538 61978
files: do_xarray: callback operation failed: entry: 1 item: 0
crash>
crash> address_space.i_pages -o 0xffff95704e96e6b0
struct address_space {
[ffff95704e96e6b8] struct xarray i_pages;
}
crash> tree -t x ffff95704e96e6b8
ffffd25984ea3900
0
0 // 4 pages
0
ffffd25984d1d700
10
10
10
ffffd25984d1d800
...
ffffd259850b8800
80
80
80
80
80
80
80
80 // 16 pages
80
80
80
80
80
80
80
ffffd259850b8c00
...
crash> kmem -p ffffd25984ea3900 --> has PG_head
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffd25984ea3900 13a8e4000 ffff95704e96e6b0 0 5 17ffffc0012036
referenced,uptodate,lru,active,private,head
crash> folio._folio_order ffffd25984ea3900
_folio_order = 2 '\002', --> 4 pages
crash> kmem -p ffffd259850b8800
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffd259850b8800 142e20000 ffff95704e96e6b0 20 17 17ffffc0012036
referenced,uptodate,lru,active,private,head
crash> folio._folio_order ffffd259850b8800
_folio_order = 4 '\004', --> 16 pages
At first glance, maybe XArray's way to handle compound pages changed...
I think it's better to fix this first.
Thanks,
Kazu