Namhyung Kim | 9 Jul 13:21 2016
Picon
Gravatar

[PATCH] extensions/trace: Fix ftrace_get_event_type_name()

The recent kernel change dcb0b5575d24 ("tracing: Remove
TRACE_EVENT_FL_USE_CALL_FILTER logic") changed the bit index so it makes
checking TRACE_EVENT_FL_TRACEPOINT flag failed.  It should be 0x20 for
newer kernels.  Without this patch, the crash tool refused to load
trace.so extension due to invalid access to event names:

  crash> extend trace.so
  extend: /path/to/crash/extensions/trace.so: no commands registered: shared object unloaded

Instead of using the hard-coded value, read the enum value from the
kernel dynamically.

Reported-by: Minchan Kim <minchan <at> kernel.org>
Cc: Steven Rostedt <rostedt <at> goodmis.org>
Signed-off-by: Namhyung Kim <namhyung <at> gmail.com>
---
 extensions/trace.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/extensions/trace.c b/extensions/trace.c
index 782d62f..f8ccd91 100644
--- a/extensions/trace.c
+++ b/extensions/trace.c
 <at>  <at>  -1015,8 +1015,6  <at>  <at>  static void ftrace_destroy_event_types(void)
 	free(ftrace_common_fields);
 }

-#define TRACE_EVENT_FL_TRACEPOINT 0x40
-
 static
(Continue reading)

AKASHI Takahiro | 28 Jun 06:57 2016

[PATCH v5 0/4] arm64: more improvement of bt -f

Changes in v5:
* add a workaround against an exceptional case of backtracing
  (See "FIXME" in arm64_back_trace_cmd())
* update comments in arm64_unwind_frame()
* add patch[4/4]

Changes in v4:
* use arm64_on_irq_stack() to check whether or not we are on IRQ stack.
  mistakendly used 'flags & IRQ_STACKS'.
* fix a bug at critical timing around switching stacks in arm64_unwind_frame().
  We need to take are of a possibility that we get back to process stack,
  but fp still points to IRQ stack.
* add patch[2/3]
  This should be applied even withtout patch[1/3]
* add patch[3/3]
  applying this patch would be a discussion.

AKASHI Takahiro (4):
  arm64: more improvement of bt -f
  arm64: find a correct starting stackframe at bt
  arm64: correct a PC shown in bt
  arm64: add VHE support

 arm64.c | 603 ++++++++++++++++++++++++++++++++++++++++++++--------------------
 defs.h  |   6 +
 2 files changed, 423 insertions(+), 186 deletions(-)

--

-- 
2.9.0

(Continue reading)

AKASHI Takahiro | 22 Jun 06:35 2016

[PATCH v4 0/3] arm64: more improvement of bt -f

Changes in v4:
* use arm64_on_irq_stack() to check whether or not we are on IRQ stack.
  mistakendly used 'flags & IRQ_STACKS'.
* fix a bug at critical timing around switching stacks in arm64_unwind_frame().
  We need to take are of a possibility that we get back to process stack,
  but fp still points to IRQ stack.
* add patch[2/3]
  This should be applied even withtout patch[1/3]
* add patch[3/3]
  applying this patch would be a discussion.

AKASHI Takahiro (3):
  arm64: more improvement of bt -f
  arm64: find a correct starting stackframe at bt
  arm64: correct a PC shown in bt

 arm64.c | 559 +++++++++++++++++++++++++++++++++++++++++++---------------------
 defs.h  |   6 +
 2 files changed, 379 insertions(+), 186 deletions(-)

--

-- 
2.9.0

AKASHI Takahiro | 20 Jun 07:06 2016

[PATCH v3] arm64: more improvement of bt -f

Dave,

This patch addresses all the issues that I mentioned in [1], and
re-factored arm64_back_trace_cmd() to make it simpler, while
arm64_unwind_frame() gets a bit complicated. But those changes,
I believe, make the code more readable and easily maintainable.
(The only ugly part is arm64_in_exp_entry(). I have no better ideas.)

Please pick up this patch if you like.
It is to be applied on top of your current master.

[1] https://www.redhat.com/archives/crash-utility/2016-June/msg00040.html

Thanks,
-Takahiro AKASHI

======8<======
>From c1e06fdd21bb70d247babd43cf2762e0cdf6979c Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.akashi <at> linaro.org>
Date: Thu, 16 Jun 2016 09:29:52 +0900
Subject: [PATCH v3] arm64: more improvement of bt -f

Signed-off-by: AKASHI Takahiro <takahiro.akashi <at> linaro.org>
---
 arm64.c | 486 +++++++++++++++++++++++++++++++++++++++++++---------------------
 defs.h  |   6 +
 2 files changed, 337 insertions(+), 155 deletions(-)

diff --git a/arm64.c b/arm64.c
index 06676d1..9d42fe6 100644
(Continue reading)

AKASHI Takahiro | 14 Jun 03:31 2016

[PATCH v6] arm64: fix kernel memory map handling for kaslr-enabled kernel

A quick update.

changes in v6:
* arm64_kdump_phys_offset() now falls through the default case,
  arm_kdump_phys_offset(), anyway.

changes in v5:
* Calcs PHYS_OFFSET by reading VMCOREINFO, "NUMBER(PHYS_OFFSET)"
  "memstart_addr"-based routine was also moved into arm64_kdump_phys_base().

changes in v4:
* Fixed VA_BITS calculation for v4.5 or earlier
* Added 4-level address translation with 4KB page size
* Removed "fix a renaming of a member of struct page, _count to _refcount"

Chnages in v3:
* Refined KASLR handling
  hopefully the tool works even on a live system if CONFIG_RANDOMIZE_RAM is
  not configured
* Fixed a renaming of a member of struct page
* Removed a commit message regarding an issue of backtracing a panic'ed task
  because this is not a bug in this tool, but my kdump patch's.
* Reported "kmem <vmalloc addr>" issue in a commit message

changes in v2:
* Fixed build warnings
* Moved ARM64_NEW_VMEMMAP to machdep->flags
* Show additional kaslr-related parameters in arm64_dump_machdep_table()
* Handle a VMCOREINFO, "NUMBER(kimage_voffset)"

(Continue reading)

AKASHI Takahiro | 13 Jun 10:10 2016

[PATCH v5] arm64: fix kernel memory map handling for kaslr-enabled

In my next version of kdump patch, the following VMCOREINFO will be
added:
    NUMBER(VA_BITS)
    NUMBER(kimage_voffset)
    NUMBER(PHYS_OFFSET)
    KERNELOFFSET

I think that those will also satisfy mkdumpfile requirements.
        -> Pratyush

Thanks,
-Takahiro AKASHI

changes in v5:
* Calcs PHYS_OFFSET by reading VMCOREINFO, "NUMBER(PHYS_OFFSET)"
  "memstart_addr"-based routine was also moved into arm64_calc_phys_base().

changes in v4:
* Fixed VA_BITS calculation for v4.5 or earlier
* Added 4-level address translation with 4KB page size
* Removed "fix a renaming of a member of struct page, _count to _refcount"

Chnages in v3:
* Refined KASLR handling
  hopefully the tool works even on a live system if CONFIG_RANDOMIZE_RAM is
  not configured
* Fixed a renaming of a member of struct page
* Removed a commit message regarding an issue of backtracing a panic'ed task
  because this is not a bug in this tool, but my kdump patch's.
* Reported "kmem <vmalloc addr>" issue in a commit message
(Continue reading)

AKASHI Takahiro | 13 Jun 09:13 2016

[PATCH v2] arm64: dump a stack frame based on fp

Changes in v2:
* Basically moved arm64_print_stackframe_entry() after arm64_unwind_frame()
  in arm64_back_trace_cmd() to make the output consistent with the format
  on x86
  Then, we had to calculate the end address of a stack frame, frame_top,
  for particular cases.

-Takahiro AKASHI

======8<======
>From d8683645599a238578a0f586af563bc9f847d52c Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.akashi <at> linaro.org>
Date: Wed, 8 Jun 2016 11:14:22 +0900
Subject: [PATCH v2] arm64: dump a stack frame based on fp

Signed-off-by: AKASHI Takahiro <takahiro.akashi <at> linaro.org>
---
 arm64.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++++----------------
 defs.h  |   5 +++
 2 files changed, 110 insertions(+), 35 deletions(-)

diff --git a/arm64.c b/arm64.c
index bdea79c..7b5b394 100644
--- a/arm64.c
+++ b/arm64.c
 <at>  <at>  -43,9 +43,10  <at>  <at>  static void arm64_stackframe_init(void);
 static int arm64_eframe_search(struct bt_info *);
 static int arm64_is_kernel_exception_frame(struct bt_info *, ulong);
 static int arm64_in_exception_text(ulong);
+static int arm64_in_exp_entry(ulong);
(Continue reading)

AKASHI Takahiro | 8 Jun 06:21 2016

arm64: "bt -f" output

Dave,

When I looked at the output from "bt -f" command, I found that stack dump
starts from frame.sp in arm64_print_stackframe_entry().
Usage of stack frames on arm64 is a bit different from that on x86, and
using frame.fp is, I believe, much useful (and accurate) for crash users.
See my patch attached below.

Details:
A layout of a stack frame in a function looks like:

         stack grows to lower addresses.
           /|\
            |
         |      |
new sp   +------+ <---
         |dyn   |   |
         | vars |   |
new fp   +- - - +   |
         |old fp|   | a function's stack frame
         |old lr|   |
         |static|   |
         |  vars|   |
old sp   +------+ <---
         |dyn   |
         | vars |
old fp   +------+
         |      |

* On function entry, sp is decremented down to new fp.
(Continue reading)

AKASHI Takahiro | 2 Jun 07:04 2016

arm64: odd backtrace?

Dave,

When I ran "bt" against a process running in a user mode, I got
an odd backtrace result:
===8<===
crash> ps
   ...
>  1324   1223   2  ffff80002018be80  RU   0.0     960    468  dhry
   1325      2   1  ffff800021089900  IN   0.0       0      0  [kworker/u16:0]
crash> bt 1324
PID: 1324   TASK: ffff80002018be80  CPU: 2   COMMAND: "dhry"
ffff800022f6ae08: ffff00000812ae44 (crash_save_cpu on IRQ stack)
 #0 [ffff800022f6ae10] crash_save_cpu at ffff00000812ae44
 #1 [ffff800022f6ae60] handle_IPI at ffff00000808e718
 #2 [ffff800022f6b020] gic_handle_irq at ffff0000080815f8
 #3 [ffff800022f6b050] el0_irq_naked at ffff000008084c4c
pt_regs: ffff800022f6af60
     PC: ffffffffffffffff  [unknown or invalid address]
     LR: ffff800020107ed0  [unknown or invalid address]
     SP: 0000000000000000  PSTATE: 004016a4
    X29: ffff000008084c4c  X28: ffff800022f6b080  X27: ffff000008e60c54
    X26: ffff800020107ed0  X25: 0000000000001fff  X24: 0000000000000003
    X23: ffff0000080815f8  X22: ffff800022f6b040  X21: 0000000000000000
    X20: ffff000008bce000  X19: ffff00000808e758  X18: ffff800022f6b010
    X17: ffff00000808a820  X16: ffff800022f6aff0  X15: 0000000000000000
    X14: 0000000000000000  X13: 0000000000000000  X12: 0000000000402138
    X11: ffff000008675850  X10: ffff800022f6afe0   X9: 0000000000000000
     X8: ffff800022f6afc0   X7: 0000000000000000   X6: 0000000000000000
     X5: 0000000000000000   X4: 0000000000000001   X3: 0000000000000000
     X2: 0000000000493000   X1: 0000000000498000   X0: ffffffffffffffff
(Continue reading)

Masayoshi Mizuma | 1 Jun 08:03 2016

[PATCH] pykdump: add maxel parameter to readStructNext

Hi Alex,

When I searched struct journal_head by readStructNext(), the
number of journal_head was over _MAXEL (== 10000) and the
searching was stopped.
It is good to add a parameter to change the limit.

Signed-off-by: Masayoshi Mizuma <m.mizuma <at> jp.fujitsu.com>
---
 pykdump/wrapcrash.py |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/pykdump/wrapcrash.py b/pykdump/wrapcrash.py
index 74d805e..6c83e67 100755
--- a/pykdump/wrapcrash.py
+++ b/pykdump/wrapcrash.py
 <at>  <at>  -1202,7 +1202,7  <at>  <at>  def readSUListFromHead(headaddr, listfieldname, mystruct, maxel=_MAXEL,
 # an embedded listhead. 'shead' is either a structure or tPtr pointer
 # to structure

-def readStructNext(shead, nextname, inchead = True):
+def readStructNext(shead, nextname, maxel=_MAXEL, inchead = True):
     if (not isinstance(shead, StructResult)):
         # This should be tPtr
         if (shead == 0):
 <at>  <at>  -1211,7 +1211,7  <at>  <at>  def readStructNext(shead, nextname, inchead = True):
     stype = shead.PYT_symbol
     offset = shead.PYT_sinfo[nextname].offset
     out = []
-    for p in readList(Addr(shead), offset, inchead=inchead):
(Continue reading)

AKASHI Takahiro | 30 May 08:46 2016

[PATH v4 0/2] fix kernel memory map handling for kaslr-enabled kernel

changes in v4:
* Fixed VA_BITS calculation for v4.5 or earlier
* Added 4-level address translation with 4KB page size
* Removed "fix a renaming of a member of struct page, _count to _refcount"
* Removed "kmem <vmalloc addr>" issue description from a commit message
  (This was not a bug.)

Chnages in v3:
* Refined KASLR handling
  hopefully the tool works even on a live system if CONFIG_RANDOMIZE_RAM is
  not configured
* Fixed a renaming of a member of struct page
* Removed a commit message regarding an issue of backtracing a panic'ed task
  because this is not a bug in this tool, but my kdump patch's.
* Reported "kmem <vmalloc addr>" issue in a commit message

changes in v2:
* Fixed build warnings
* Moved ARM64_NEW_VMEMMAP to machdep->flags
* Show additional kaslr-related parameters in arm64_dump_machdep_table()
* Handle a VMCOREINFO, "NUMBER(kimage_voffset)"

AKASHI Takahiro (2):
  arm64: fix kernel memory map handling for kaslr-enabled kernel
  arm64: add 4-level translation

 arm64.c   | 338 +++++++++++++++++++++++++++++++++++++++++++++++++++-----------
 defs.h    |  49 +++++++--
 main.c    |   7 +-
 symbols.c |  12 ++-
(Continue reading)


Gmane