[Crash-utility] Re: [PATCH v3] add "files -n" command for an inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




在 2023/11/9 12:37, HAGIO KAZUHITO(萩尾 一仁) 写道:
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.]


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

I only find v6.5-rc1 ~ v6.5-rc7 in Linus's tree.

What does the 6.5.9 mean?


      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.

I tried to reproduce it in 6.5 kernel, but I do not meet this issue:

kernel 6.5 with " crash_core: export vmemmap when CONFIG_SPARSEMEM_VMEMMAP is enabled"

 ----------------------------------------------------------------------------

crash> files
PID: 3153     TASK: ffff07ff900aae80  CPU: 32   COMMAND: "crash"
ROOT: /    CWD: /root/tool/crash/crash
 FD       FILE            DENTRY           INODE       TYPE PATH
  0 ffff07ff8ebb1000 ffff07ffa29dca80 ffff07ff8b7d0750 CHR /dev/pts/0
  1 ffff07ff8ebb1000 ffff07ffa29dca80 ffff07ff8b7d0750 CHR /dev/pts/0
  2 ffff07ff8ebb1000 ffff07ffa29dca80 ffff07ff8b7d0750 CHR /dev/pts/0
  3 ffff07ff8ec3a200 ffff07ff80446300 ffff07ff89980c68 CHR /dev/null
  4 ffff07ff8ec39c00 ffff3fff8a7cf980 ffff3fff942123a0 REG /proc/kcore
  5 ffff07ff8e490f00 ffff07ff8d02e6c0 ffff07ff8d026ea8 REG /root/linux-linus/vmlinux
  6 ffff07ff8f876500 ffff07ff8d02f5c0 ffff07ffa4ad8270 FIFO
  7 ffff07ff8f875500 ffff07ff8d02f5c0 ffff07ffa4ad8270 FIFO
  8 ffff07ff8f874000 ffff07ff8d02f680 ffff07ffa4ad84e0 FIFO
  9 ffff07ff8f877900 ffff07ff8d02f680 ffff07ffa4ad84e0 FIFO
 10 ffff07ff8f875b00 ffff07ff8d02f740 ffff07ffa4ad8750 FIFO
 11 ffff07ff8f874600 ffff07ff8d02f740 ffff07ffa4ad8750 FIFO
 12 ffff07ff8e493d00 ffff07ff8d02f980 ffff07ffa4ad89c0 FIFO
 13 ffff07ff8e5eab00 ffff07ff8d02f980 ffff07ffa4ad89c0 FIFO
 14 ffff07ff8e491a00 ffff07ff8d02e6c0 ffff07ff8d026ea8 REG /root/linux-linus/vmlinux
 15 ffff07ff8e491800 ffff07ffaa01e000 ffff07ffa7f08678 REG  /tmp/#68
 17 ffff07ff8e491500 ffff07ffaa01e240 ffff07ffa4ad9110 FIFO
crash> sys
      KERNEL: /root/linux-linus/vmlinux
    DUMPFILE: /proc/kcore
        CPUS: 160
        DATE: Sat Dec  2 20:58:36 CST 2023
      UPTIME: 00:02:55
LOAD AVERAGE: 0.28, 0.19, 0.08
       TASKS: 1841
    NODENAME: fedora
     RELEASE: 6.5.0-00001-gf7dc5e21620a
     VERSION: #47 SMP PREEMPT Sat Dec  2 20:51:30 CST 2023
     MACHINE: aarch64  (unknown Mhz)
      MEMORY: 510.8 GB
crash> files -n ffff07ff8d026ea8
     INODE        NRPAGES
ffff07ff8d026ea8    94121

     NODE           PAGES
      0             94121
      1                 0
time cost:0 s

crash>

-----------------------------------------------------------------------

Do I miss something?

Thanks

Huang Shijie
--
Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux