Re: [RFC] [PATCH 0/6] Add maple tree vma iteration support for crash

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

 



Hi, Tao
Thanks for the work.
On Mon, Sep 19, 2022 at 11:10 PM <crash-utility-request@xxxxxxxxxx> wrote:
Date: Mon, 19 Sep 2022 23:10:22 +0800
From: Tao Liu <ltao@xxxxxxxxxx>
To: crash-utility@xxxxxxxxxx
Subject: [RFC] [PATCH 0/6] Add maple tree vma
        iteration support for crash
Message-ID: <20220919151028.25830-1-ltao@xxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"; x-default=true

Patchset [1] introduces maple tree data structure for linux, and the
modification on mm subsystem.

The main impact on crash utility, is the modification on vm_area_struct.
Patch [2][3] removed the rbtree and linked list iteration of
vm_area_struct, making it impossible for crash to iterate vma
in the traditional way. For example, we can observe the failing
of crash cmd vm/fuser on kernel which has integrated with patchset [1].

This patchset deals with the issue by porting and adapting
kernel's maple tree vma iteration code to crash utility. It has been
tested on linux-next-next-20220914 [4].


Good job. But I still have several questions about the patchset.

Can you help try to tidy up the following patches? For example:
Step 1:     
  - introduce the maple tree data structures and iterative algorithms as one patch.
  - (they include two files: maple_tree.c, maple_tree.h)

Patch 1: the pure copy-and-paste work, extracting related kernel
         structures, functions, constants to crash.
Patch 2: minimal code modification for crash adaption, kernel
         structures are kept for member resolving.
Patch 3: modification on crash memory.c to use the maple vma
         iteration.

The idea is to make patch 1-3 a POC work.


Step 2:
  - imitate the do_rbtree(), do_radix_tree(), do_xarray()..., you could refer to the filesys.c/tools.c
  - the maple tree can be considered as a new structure and algorithm, just like the rbtree, radix_tree and xarray..., crash can keep the same code style.
  - the advantage is that it is easy to maintain in the future.
 
Step 3:
  - call the do_maple_tree(),... in crash code, etc...
  - enable the maple tree support for crash-utility

That is my concern. But this may increase the difficulty of implementation, can you also evaluate if it is doable?

Thanks.
Lianbo

Patch 4: Get rid of kernel structures by rewriting the structure
         member resolving code into the crash way, aka change
         "node->member" into "readmem(node) and OFFSET(member)"
Patch 5: print the added variables of offset/size table 
Patch 6: Get rid of the compiling-time assgined arrays.

Patch 4-6 will make the POC work formal for use.


[1]: https://lore.kernel.org/all/20220906194824.2110408-1-Liam.Howlett@xxxxxxxxxx/
[2]: https://github.com/oracle/linux-uek/commit/d19703645b80abe35dff1a88449d074b0b5b1bb1
[3]: https://github.com/oracle/linux-uek/commit/91dee01f1ebb6b6587463b6ee6f7bbc4965f91d5
[4]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/snapshot/linux-next-next-20220914.tar.gz

Tao Liu (6):
  Port linux maple tree related files to crash
  Maple tree kernel code modification for step 1
  Introduce maple tree vma iteration to memory.c
  Maple tree kernel code modification for step 2
  Dump maple tree offset variables by help -o
  Remove mt_slots and mt_pivots array assignment

 Makefile         |  12 +-
 defs.h           |  19 ++
 maple_tree.c     | 824 +++++++++++++++++++++++++++++++++++++++++++++++
 maple_tree.h     | 109 +++++++
 maple_tree_vma.h |  34 ++
 memory.c         | 315 ++++++++++--------
 symbols.c        |  34 ++
 xarray.h         |  70 ++++
 8 files changed, 1285 insertions(+), 132 deletions(-)
 create mode 100644 maple_tree.c
 create mode 100644 maple_tree.h
 create mode 100644 maple_tree_vma.h
 create mode 100644 xarray.h

--
2.33.1
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
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