Hi, Tao
Thanks for the work.
On Mon, Sep 19, 2022 at 11:10 PM <crash-utility-request(a)redhat.com> wrote:
Date: Mon, 19 Sep 2022 23:10:22 +0800
From: Tao Liu <ltao(a)redhat.com>
To: crash-utility(a)redhat.com
Subject: [Crash-utility] [RFC] [PATCH 0/6] Add maple tree vma
iteration support for crash
Message-ID: <20220919151028.25830-1-ltao(a)redhat.com>
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@oracle....
[2]:
https://github.com/oracle/linux-uek/commit/d19703645b80abe35dff1a88449d07...
[3]:
https://github.com/oracle/linux-uek/commit/91dee01f1ebb6b6587463b6ee6f7bb...
[4]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/snaps...
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