On 2023/10/27 12:44, lijiang wrote:
> On Wed, Oct 25, 2023 at 4:09 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/10/24 18:10, Lianbo Jiang wrote:
>>> This is a backport patch from gdb commit 58abdf887821 ("Verify COFF
>>> symbol stringtab offset").
Fix the following compilation error in diskdump.c and warning in
xen_hyper.c with gcc-4.8.5 (e.g. RHEL7).
- diskdump.c: In function 'try_zram_decompress':
diskdump.c:3048:3: error: 'for' loop initial declarations are only allowed in
C99 mode
for (int count = 0; count < PAGESIZE() / sizeof(
On 2023/10/24 16:12, Huang Shijie wrote:
> In the NUMA machine, it is useful to know the memory distribution of
> an inode page cache:
> How many pages in the node 0?
> How many pages in the node 1?
>
> Add "files -n" command to get the memory distribution information:
> 1.) Add
On 2023/10/24 18:10, Lianbo Jiang wrote:
> This is a backport patch from gdb commit 58abdf887821 ("Verify COFF
> symbol stringtab offset").
>
> The AddressSanitizer reports a heap-use-after-free error as below:
>gdb/coff-pe-read.c:137:27
>
> Add a COFF offset check to fix this issue.
>
> Lin
On 2023/10/07 15:24, Yulong TANG 汤玉龙 wrote:
> Hi,
>
>
> Is it possible to display the user stack trace of a process (Not kernel stack
> trace of a process) from kernel core dump using crash utility.
>
> #bt
> will display the kernel stack trace of the process pid.
>
>
> I know extension 'gcor
On 2023/10/23 17:44, Lianbo Jiang wrote:
> This is a partial backport patch from gdb commit 033bc52bb619 ("Avoid
> buffer overflow in ada_decode").
>
> The AddressSanitizer reports a dynamic-stack-buffer-overflow error as
> below:
> gdb/ada-lang.c:1388:16 in ada_decode[abi:cxx11](char const*, bool
On 2023/10/11 10:40, Huang Shijie wrote:
> In the NUMA machine, it is useful to know the memory distribution of
> an inode page cache:
> How many pages in the node 0?
> How many pages in the node 1?
>
> Add "files -n" command to get the memory distribution information:
> 1.) Add
On 2023/10/18 21:05, lijiang wrote:
> On Tue, Oct 17, 2023 at 3:52 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>>> ---
>>>defs.h | 26 +
>>>diskdump.c | 66 --
>>>2
On 2023/10/14 22:39, Aditya Gupta wrote:
> Upstream crash reports these warnings on PowerPC64:
>
> WARNING: cpu 0 invalid NT_PRSTATUS note (n_type != NT_PRSTATUS)
> ...
>
> Apart from these warnings, register values are also invalid.
>
> This warning was found in the commit:
>
>
On 2023/10/13 14:03, 陈冠有 wrote:
> Hi Kazu
>
> Thank you for your advice.
>
>
>> Does this mean that the current "memset(buf, entry, len)" is a bug,
>> because entry is ulong, right? If so, I agree.
>
>
> Yes.
>
>
> Subject: [PATCH] Fix: "rd" command to read zram buf on Linux 5.17 and later
tic long ZRAM_SAME;
in diskdump.c and get it in zram_init()?
> + && THIS_KERNEL_VERSION >= LINUX(6,1,0))
> + ZRAM_LOCK_VALUE = PAGESHIFT() + 1;
> +
> + ZRAM_SAME_PAGEFLAG = ZRAM_LOCK_VALUE + 1;
> + ZRAM_WB_PAGEFLAG = ZRAM_LOCK_VALUE + 2;
> +
>
> ZRAM_COMP_PRIORITY_BIT1, /* First bit of comp priority index */
> ZRAM_COMP_PRIORITY_BIT2, /* Second bit of comp priority index */
>
> __NR_ZRAM_PAGEFLAGS,
> };
>
> Thanks
>
>
>
> 发件人: HAGIO KAZUHITO(萩尾 一仁)
> 发送时间:
On 2023/10/10 20:16, Mathias Krause wrote:
> On 29.09.23 02:44, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> On 2023/09/21 11:00, Huang Shijie wrote:
>>> Add the clear command for crash.
>>> Use it to clear the screen.
>>
>> Sorry, but I would not like to add a command j
On 2023/10/10 15:09, lijiang wrote:
> On Tue, Oct 10, 2023 at 8:31 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/10/07 16:48, lijiang wrote:
>>> On Fri, Sep 29, 2023 at 12:30 PM HAGIO KAZUHITO(萩尾 一仁) <
>> k-hagio...@nec.com>
>>> wrote:
>>>
On 2023/10/07 12:06, lijiang wrote:
> Thank you for the update, Mathias.
>
> On Thu, Sep 28, 2023 at 5:19 PM Mathias Krause
> wrote:
>
>> This is v3 of the previous series, adding another patch (patch 1),
>> fixing build errors reported by Lianbo.
>>
>> v2:
>> https://listman.redhat.com/archives
On 2023/10/07 16:48, lijiang wrote:
> On Fri, Sep 29, 2023 at 12:30 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/09/29 9:58, Shijie Huang wrote:
>>> Hi Kazu,
>>>
>>> 在 2023/9/29 8:44, HAGIO KAZUHITO(萩尾 一仁) 写道:
>>>> On 2023/09/21 11:00, Hua
On 2023/10/05 15:53, Mathias Krause wrote:
> Hagio-san,
>
> On 05.10.23 04:47, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> Hi Mathias,
>>
>> thank you for the patch set, looks good.
>>
>> On 2023/09/28 18:19, Mathias Krause wrote:
>>> Support compiling the mo
Hi Mathias,
thank you for the patch set, looks good.
On 2023/09/28 18:19, Mathias Krause wrote:
> Support compiling the module against a different kernel version than the
> currently running one by allowing to set either KVER or KDIR variables
> on the make commandline.
>
> Also modernize the ma
On 2023/09/20 12:28, 陈冠有 wrote:
> when zspage define 'huge', crash-utility zram decompress fail.
> we need to be compatible with the previous kernel,
> so we can't define 'huge' directly in zspage.
Thank you for the patch, is this v4 patch the latest one?
>
> Before:
> crash> mod -s zram zram.ko
Hi Hatayama-san,
sorry for the delay, exceptionally busy last month..
On 2023/09/19 15:22, lijiang wrote:
>> read_diskdump() returns successfully for illegal 0-size page
>> descriptors. Page descriptors are illegal if their size member holds 0
>> because makedumpfile never puts 0 there because a
On 2023/10/02 13:10, Daisuke Hatayama (Fujitsu) wrote:
> Hagio-san,
>
> Sorry for the delayed response.
>
>>
>> From: HAGIO KAZUHITO(萩尾 一仁)
>> Sent: Thursday, September 28, 2023 9:03
>> To: Hatayama, Daisuke/畑
On 2023/09/29 9:58, Shijie Huang wrote:
> Hi Kazu,
>
> 在 2023/9/29 8:44, HAGIO KAZUHITO(萩尾 一仁) 写道:
>> On 2023/09/21 11:00, Huang Shijie wrote:
>>> Add the clear command for crash.
>>> Use it to clear the screen.
>> Sorry, but I would not like to add a
On 2023/09/21 11:00, Huang Shijie wrote:
> Add the clear command for crash.
> Use it to clear the screen.
Sorry, but I would not like to add a command just to do this.
Currently, we can run the clear command like this:
crash> !clear
If this is not acceptable to you, crash has some external c
On 2023/09/28 17:00, Guanyou Chen wrote:
> Thank you for review, Lianbo.
>
> Kazu, Can you help improve the patch log.
>
> Thanks
> Guanyou
>
> lijiang 于2023年9月27日周三 19:35写道：
>
>> Thank you for the update, Chen.
>> On Tue, Sep 26, 2023 at 8:44 PM Guanyou Chen
>> wrote:
>>
>>> arm64/pgtable: s
On 2023/09/26 19:21, Daisuke Hatayama (Fujitsu) wrote:
> Hagio-san,
>
> crash trace now results in SIGSEGV on Fedora Linux 38 as follows:
>
> crash> extend /usr/lib64/crash/extensions/trace.so
> /usr/lib64/crash/extensions/trace.so: shared object loaded
> crash> trace
> curren
On 2023/09/26 15:12, lijiang wrote:
> Hi, Aditya
> Thank you for the update.
> On Mon, Sep 25, 2023 at 5:28 PM Aditya Gupta wrote:
>
>> Currently 'crash-tool' fails on vmcore collected on upstream kernel on
>> PowerPC64 with the error:
>>
>> crash: invalid kernel virtual address: 0 type: "f
On 2023/09/20 15:29, lijiang wrote:
> On Fri, Sep 15, 2023 at 4:48 PM wrote:
>
>> Date: Fri, 15 Sep 2023 16:46:33 +0800
>> From: Shijie Huang
>> To: crash-utility@redhat.com
>> Subject: [Crash-utility] Question on crash:clear the screen
>> Message-ID:
>>
>> Content-Type: text/plain; ch
On 2023/09/13 9:11, David Mair wrote:
> verify_version() in kernel.c gets a struct syment for linux_banner using
> symbol_search() and uses the value member of the result as the address
> of linux_banner in some cases based on the type member's value in the
> same struct syment. A small number o
On 2023/09/07 19:54, Daisuke Hatayama (Fujitsu) wrote:
> Hagio-san,
>
> I'm now facing the issue on RHEL8 and RHEL9 that crash dump files are
> corrupted although makedumpfile terminated in successful status, in
> the issue which I found the issue this patch tries to fix.
>
> I made a program to
On 2023/08/28 15:39, Mathew T wrote:
> Hi,
> I am trying to figure out if I can extract the values associated with
> cgroups from kernel crash dump. I can see "cgorup" is mounted when i
> issue "mount" command in crash utility. And it shows mount/superblock
> address. How can I further dig down and
On 2023/08/29 0:23, David Mair wrote:
> On 8/20/23 19:37, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> On 2023/08/18 3:08, David Mair wrote:
>>> Hi All,
>>>
>>> Before I consider starting work on a patch for this I'd appreciate more
>>> input.
>>>
>
On 2023/08/25 15:23, Lianbo Jiang wrote:
> When a task is exiting, usually kernel marks its flags as 'PF_EXITING',
> but even so, sometimes the mm_struct has not been freed, it might still
> be valid. For such tasks, the "ps/vm" commands won't display the memory
> usage. For example:
>
>crash>
On 2023/08/24 17:29, lijiang wrote:
> On Thu, Aug 24, 2023 at 10:01 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/08/23 14:44, Lianbo Jiang wrote:
>>> When a task is exiting, usually kernel marks its flags as 'PF_EXITING',
>>> but even so, sometimes
On 2023/08/23 14:44, Lianbo Jiang wrote:
> When a task is exiting, usually kernel marks its flags as 'PF_EXITING',
> but even so, sometimes the mm_struct has not been freed, it might still
> be valid. For such tasks, the "ps/vm" commands won't display the memory
> usage. For example:
>
>crash>
On 2023/08/18 3:08, David Mair wrote:
> Hi All,
>
> Before I consider starting work on a patch for this I'd appreciate more
> input.
>
> I am seeing random cases of crash failing to load reporting an x86_64
> coredump reporting a "bad" linux_banner. However, the value displayed as
> the banner
On 2023/08/18 18:50, Song Shuai wrote:
> From: Song Shuai
>
> This patch adds KASLR support for Crash to analyze KASLR-ed vmcore
> since RISC-V Linux is already sufficiently prepared for KASLR [1].
>
> With this patch, even if the Crash '--kaslr' option is not set or Linux
> CONFIG_RANDOMIZE_BAS
On 2023/08/17 18:18, lijiang wrote:
> On Tue, Aug 15, 2023 at 10:41 AM wrote:
>
>> Date: Mon, 14 Aug 2023 09:41:12 -0400
>> From: Rafael Aquini
>> To: crash-utility@redhat.com
>> Cc: raqu...@redhat.com
>> Subject: [Crash-utility] [PATCH] deduplicate kernel_version open-coded
>> parser
>
On 2023/08/14 10:54, Lianbo Jiang wrote:
> Currently, crash-utility still depends on detecting the kernel version,
> or the asm instruction 'bswap' on X86 64/X86 architectures to decide how
> to deal with the freelist ptr obfuscation, when kernel option
> CONFIG_SLAB_FREELIST_HARDENED is enabled.
>
On 2023/08/14 22:42, Rafael Aquini wrote:
> On Mon, Aug 14, 2023 at 09:41:12AM -0400, Rafael Aquini wrote:
>> The code that parses kernel version from OSRELEASE/UTSRELEASE strings
>> and populates the global kernel table is duplicated across the codebase
>> for no good reason. This commit consolida
On 2023/08/15 21:22, lijiang wrote:
> On Tue, Aug 15, 2023 at 6:34 PM Song Shuai wrote:
>
>>
>> 在 2023/8/15 16:42, HAGIO KAZUHITO(萩尾 一仁) 写道:
>>> On 2023/08/15 15:44, lijiang wrote:
>>>> On Tue, Aug 15, 2023 at 10:40 AM Song Shuai
>> wrote:
&
On 2023/08/15 15:44, lijiang wrote:
> On Tue, Aug 15, 2023 at 10:40 AM Song Shuai wrote:
>
>>
>> 在 2023/8/14 16:27, lijiang 写道:
>>> +static void
>>> +riscv64_get_va_kernel_pa_offset(struct machine_specific *ms)
>>> +{
>>> + unsigned long kernel_version = riscv64_get_kern
On 2023/08/08 22:25, Lianbo Jiang wrote:
> Kernel commit eca56ff906bd ("mm, shmem: add internal shmem resident
> memory accounting"), which adds internal shmem resident memory
> accounting, and tallies into the mm_rss_stat counter.
>
> As a result, the "ps/vm" commands fail to show correct memory
On 2023/08/04 18:15, Song Shuai wrote:
> Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
> PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base from
> the physical start of the kernel to the actual start of the DRAM.
>
> The Crash's VTOP() still uses phys_ram_base and ker
Hi Aditya,
thank you for working on this.
On 2023/08/01 3:56, Aditya Gupta wrote:
> The Problem:
>
>
> Currently crash is unable to show function arguments and local variables, as
> gdb can do. And functionality for moving between frames ('up'/'down') is not
> working in crash.
>
>
On 2023/07/24 13:06, Song Shuai wrote:
> Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
> PUD/P4D/PGD pages for the linear mapping") changes the
> phys_ram_base from the kernel_map.phys_addr to the start of DRAM.
>
> The Crash's VTOP() still uses phys_ram_base and kernel_map.virt_ad
On 2023/08/03 12:23, lijiang wrote:
>>> + if ((fd->flags & FOREACH_STATE) &&
>>> + (!STRNEQ(task_state_string(tc->task, buf, 0),
>> fd->state)))
>>> + continue;
>>
>> Thank you for the update.
>>
>> sorry for kind of nitpicking, why is this STRNE
On 2023/08/02 17:18, Lianbo Jiang wrote:
> Currently, the "foreach DE ps -m" command may display "DE" as well as
> "ZO" state tasks as below:
>
>crash> foreach DE ps -m
>...
>[0 00:00:00.040] [ZO] PID: 11458TASK: 91c75680d280 CPU: 7
> COMMAND: "ora_w01o_p01mci"
>[0 00
On 2023/08/02 10:08, Ming Wang wrote:
>
>
> On 7/31/23 13:23, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> On 2023/07/27 21:28, Ming Wang wrote:
>>> This patch are for Crash-utility tool, it make crash tool support on
>>> loongarch64 architecture and the common commands(bt, p
On 2023/07/31 17:18, lijiang wrote:
> Thank you for the comments, Kazu.
>
> On Mon, Jul 31, 2023 at 10:08 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/07/28 20:15, Lianbo Jiang wrote:
>>> Currently, the "foreach DE ps -m" command may display "
On 2023/07/27 21:28, Ming Wang wrote:
> This patch are for Crash-utility tool, it make crash tool support on
> loongarch64 architecture and the common commands(bt, p, rd, mod, log, set,
> dis, and so on).
>
> The upstream GDB code supports the loongarch64 architecture from version 13.1.
> See: htt
On 2023/07/28 20:15, Lianbo Jiang wrote:
> Currently, the "foreach DE ps -m" command may display "DE" as well as
> "ZO" state tasks as below:
>
>crash> foreach DE ps -m
>...
>[0 00:00:00.040] [ZO] PID: 11458TASK: 91c75680d280 CPU: 7
> COMMAND: "ora_w01o_p01mci"
>[0 00
On 2023/07/24 18:05, lijiang wrote:
> On Mon, Jul 24, 2023 at 4:48 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> From: Kazuhito Hagio
>>
>> As written in the previous patch, some recent kernels do not have the
>> ".rodata" symbol. As a result, the get_linux
On 2023/07/24 17:44, Song Shuai wrote:
> 在 2023/7/24 15:41, Conor Dooley 写道:
>> Hey,
>>
>> On Mon, Jul 24, 2023 at 12:06:49PM +0800, Song Shuai wrote:
>>> Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
>>> PUD/P4D/PGD pages for the linear mapping") changes the
>>> phys_ram_base from
From: Kazuhito Hagio
As written in the previous patch, some recent kernels do not have the
".rodata" symbol. As a result, the get_linux_banner_from_vmlinux()
returns FALSE and the slower fallback routine is used.
Use "__start_rodata" symbol if the ".rodata" symbol is not available.
Reported-by
On 2023/07/24 15:52, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/07/21 13:36, Lianbo Jiang wrote:
>> Currently, the symbol ".rodata" may not be found in some vmlinux, and
>> the strings command will still be used to get the linux banner string,
>> but this gets two string
On 2023/07/24 16:33, lijiang wrote:
> On Mon, Jul 24, 2023 at 3:07 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/07/24 15:51, lijiang wrote:
>>> How about reading out the linux_banner string to a buffer with readmem()?
>>
>> No, this is a version check fo
On 2023/07/24 15:51, lijiang wrote:
>>> I think you are fixing the fallback routine and that's good, but it's
>>> better to fix get_linux_banner_from_vmlinux() first if possible. It's
>>
>
> Thank you for the comments, Kazu.
>
> They are different issues. The fallback routine(strings) also need
On 2023/07/21 13:36, Lianbo Jiang wrote:
> Currently, the symbol ".rodata" may not be found in some vmlinux, and
> the strings command will still be used to get the linux banner string,
> but this gets two strings as below:
>
># strings
> /usr/lib/debug/usr/lib/modules/6.5.0-0.rc2.17.fc39.x86
On 2023/07/24 10:17, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Lianbo,
>
> Thank you for the fix.
>
> On 2023/07/21 13:36, Lianbo Jiang wrote:
>> Currently, the symbol ".rodata" may not be found in some vmlinux, and
>> the strings command will still be used to get
Hi Lianbo,
Thank you for the fix.
On 2023/07/21 13:36, Lianbo Jiang wrote:
> Currently, the symbol ".rodata" may not be found in some vmlinux, and
> the strings command will still be used to get the linux banner string,
> but this gets two strings as below:
>
># strings
> /usr/lib/debug/usr
On 2023/07/12 17:55, lijiang wrote:
> On Mon, Jul 10, 2023 at 2:05 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> Without the patch, do_mt_entry() can call dump_struct_members_for_tree()
>> with a NULL entry, and parse_for_member_extended() will cause a
>> segmentation fault d
On 2023/07/12 18:54, lijiang wrote:
> Thank you for the update, Kazu.
> On Wed, Jul 12, 2023 at 4:55 PM wrote:
>
>> Date: Wed, 12 Jul 2023 08:55:29 +
>> From: HAGIO KAZUHITO(?)
>> To: "crash-utility@redhat.com"
>> Cc: "liji...@redhat.com"
>> Subject: [Crash-utility] [PATCH v2 2/2] Fix
From: Kazuhito Hagio
Kernel commit 721255b982 ("genirq: Use a maple tree for interrupt
descriptor management"), which is contained in Linux 6.5-rc1 and later
kernels, replaced irq_desc_tree with a maple tree sparse_irqs.
Without the patch, "irq [-a|-s]" options fail with an error, e.g. the
follo
On 2023/07/12 17:17, lijiang wrote:
> On Wed, Jul 12, 2023 at 3:49 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/07/12 16:30, lijiang wrote:
>>> On Fri, Jul 7, 2023 at 2:17 PM HAGIO KAZUHITO(萩尾 一仁) >>
>>> wrote:
>>>
>>>> From: Kazuhi
On 2023/07/12 16:30, lijiang wrote:
> On Fri, Jul 7, 2023 at 2:17 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> From: Kazuhito Hagio
>>
>> Kernel commit 721255b982 ("genirq: Use a maple tree for interrupt
>> descriptor management"), which is contained in L
On 2023/07/10 15:28, lijiang wrote:
>> @@ -112,8 +112,8 @@ vmware_vmss_init(char *filename, FILE *ofp)
>> }
>>
>> if (fread(grps, sizeof(cptgroupdesc), grpsize, fp) != grpsize) {
>> - error(INFO, LOGPRX"Failed to read '%s': [Error %d] %s\n",
>> -
Without the patch, do_mt_entry() can call dump_struct_members_for_tree()
with a NULL entry, and parse_for_member_extended() will cause a
segmentation fault during strncpy().
This is caused by "tree -t maple -s struct.member.member" style multiple
level member access:
crash> tree -t maple -s irq
On 2023/07/10 12:27, lijiang wrote:
> On Mon, Jul 10, 2023 at 9:42 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> From: Kazuhito Hagio
>>
>> Kernel commit f0dd891dd5a1d ("lib/cpumask: move some one-line wrappers
>> to header file"), which is contained
From: Kazuhito Hagio
Kernel commit f0dd891dd5a1d ("lib/cpumask: move some one-line wrappers
to header file"), which is contained in Linux 6.0 and later kernels,
inlined alloc_cpumask_var() function. As a result, the "irq -a" option
fails to determine whether cpumask_var_t is a pointer, and displ
On 2023/07/06 23:53, Dave Wysochanski wrote:
> Today if crash fails to read some structure in a vmware 'vmsn' file,
> it will throw an "No such file or directory" message. Such a generic
> message does not give any clue as to the problem, but instead sounds
> like the file may not exist when it do
From: Kazuhito Hagio
Kernel commit 721255b982 ("genirq: Use a maple tree for interrupt
descriptor management"), which is contained in Linux 6.5-rc1 and later
kernels, replaced irq_desc_tree with a maple tree sparse_irqs.
Without the patch, "irq [-a|-s]" options fails with an error, e.g. the
foll
From: Kazuhito Hagio
While the return value of do_radix_tree() and do_xarray() does not
contain NULL entries, do_maple_tree()'s one contains NULL entries.
Make this behavior consistent with the previous tree functions to make
replacement easier, especially for the following patch.
Signed-off-by
On 2023/07/05 11:02, Lianbo Jiang wrote:
> Crash-utility implemented its own strlcpy(), but for now the latest
> glibc has added the strlcpy function to POSIX version(which is derived
> from OpenBSD). Eventually this caused the follow compilation error:
Thanks for the early fix.
It looks like the
On 2023/06/26 11:56, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/06/25 17:03, lijiang wrote:
>> On Fri, Jun 23, 2023 at 3:34 PM HAGIO KAZUHITO(萩尾 一仁)
>> wrote:
>>
>>> From: Kazuhito Hagio
>>>
>>> (The following commit is now in linux-next.)
>>>
On 2023/06/25 17:03, lijiang wrote:
> On Fri, Jun 23, 2023 at 3:34 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> From: Kazuhito Hagio
>>
>> (The following commit is now in linux-next.)
>>
>>
> Thanks for the early fix, Kazu.
>
> Looks good to me. S
On 2023/06/23 11:11, lijiang wrote:
> On Thu, Jun 22, 2023 at 3:09 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> Support module memory layout change on Linux 6.4 by kernel commit
>> ac3b43283923 ("module: replace module_layout with module_memory") [1].
>> Without
From: Kazuhito Hagio
(The following commit is now in linux-next.)
Kernel commit 75eef55b ("pid: Replace struct pid 1-element array
with flex-array") changed pid.numbers[1] to pid.numbers[]. With this,
the size of struct pid does not contain the size of struct upid:
(gdb) ptype /o struct
Support module memory layout change on Linux 6.4 by kernel commit
ac3b43283923 ("module: replace module_layout with module_memory") [1].
Without the patch, crash cannot even start a session with an error
message like this:
crash: invalid structure member offset: module_core_size
FILE: k
On 2023/06/20 11:27, HAGIO KAZUHITO(萩尾 一仁) wrote:
> On 2023/06/16 20:55, Likhitha Korrapati wrote:
>> Patch removes redundant checks for PTE (Page Table Entry) because those
>> conditions are already covered.
>>
>>
On 2023/06/20 20:14, lijiang wrote:
> +#define for_each_mod_mem_type(type) \
> + for (int (type) = MOD_TEXT; (type) < MOD_MEM_NUM_TYPES;
>> (type)++)
>>
>> I found that this cannot build with an old gcc, e.g. on RHEL7.
>> Please note that -std=gnu99 or later is required for such a gc
On 2023/06/20 17:18, Sourabh Jain wrote:
> Hello All,
>
> Reporting a crash failure while debugging kernel 6.4.0-rc4 dump.
We've been working on this for a while, please try
https://listman.redhat.com/archives/crash-utility/2023-June/010806.html
or
https://github.com/k-hagio/crash/commit/d539
Hi Lianbo,
thank you for the review.
On 2023/06/20 10:46, lijiang wrote:
>>> +#define for_each_mod_mem_type(type) \
>>> + for (int (type) = MOD_TEXT; (type) < MOD_MEM_NUM_TYPES; (type)++)
I found that this cannot build with an old gcc, e.g. on RHEL7.
Please note that -std=gnu99 or later i
On 2023/06/16 20:55, Likhitha Korrapati wrote:
> Patch removes redundant checks for PTE (Page Table Entry) because those
> conditions are already covered.
>
> if (!(pte & _PAGE_PRESENT)) {
> ...
> return FALSE;
> }
>
> if (!pte)
>
On 2023/06/14 15:32, lijiang wrote:
>> On 2023/06/13 19:25, lijiang wrote:
the part that might touch invalid range of memory. The reason why I'm
trying to fix the arm64_is_kernel_exception_frame() is I found the
issue there.
>>> So far I haven't observed this issue on my si
Support module memory layout change on Linux 6.4 by kernel commit
ac3b43283923 ("module: replace module_layout with module_memory") [1].
Without the patch, crash cannot even start a session with an error
message like this:
crash: invalid structure member offset: module_core_size
FILE: k
On 2023/06/13 19:25, lijiang wrote:
>> the part that might touch invalid range of memory. The reason why I'm
>> trying to fix the arm64_is_kernel_exception_frame() is I found the
>> issue there.
>>
>>
> So far I haven't observed this issue on my side. As you mentioned, the
> corrupt stack pointer
On 2023/06/07 18:37, HATAYAMA Daisuke wrote:
> This is the second trial from the commit
> 9868ebc8e648e5791764a51567a23efae7170d9b that was reverted at the
> previous commit.
>
> As described in the previous commit, result of STACK_OFFSET_TYPE() can
> be an address out of bt->stackbuf and hence th
On 2023/06/12 15:48, lijiang wrote:
>>> I checked the crash code. For the s390x, it doesn't invoke the
>>> map_cpus_to_prstatus{_kdump_cmprs}(), so this patch should not affect
>> the
>>> s390x arch.
>>
>> My thought is that the original commit db8c030857b4 should have added
>> the initialization
On 2023/06/12 19:50, Lianbo Jiang wrote:
> Crash tool will fail to load vmcore with the following error:
>
> #crash vmlinux /var/crash/127.0.0.1-2023-06-07-22\:03\:24/vmcore -s
>crash: invalid structure size: note_buf
> FILE: diskdump.c LINE: 121 FUNCTION: have_crash_notes()
>
>
Hi Lianbo,
sorry, my company was closed last Friday.
On 2023/06/08 20:46, lijiang wrote:
> On Thu, Jun 8, 2023 at 5:56 PM lijiang wrote:
>
>> On Thu, Jun 8, 2023 at 5:02 PM HAGIO KAZUHITO(萩尾 一仁)
>> wrote:
>>
>>> On 2023/06/08 13:31, Lianbo Jiang wrote:
>>
On 2023/06/08 13:31, Lianbo Jiang wrote:
> Crash tool will fail to load vmcore with the following error:
>
> #crash vmlinux /var/crash/127.0.0.1-2023-06-07-22\:03\:24/vmcore -s
>crash: invalid structure size: note_buf
> FILE: diskdump.c LINE: 121 FUNCTION: have_crash_notes()
>
>
On 2023/06/05 12:07, lijiang wrote:
>>> -#define ORC_TYPE_CALL 0
>>> +#define ORC_TYPE_CALL ((machdep->flags & ORC_6_4) ? 2
>> : 0)
>>
>>>#define ORC_TYPE_REGS 1
>>>#define ORC_TYPE_REGS_IRET 2
>>>#define UNWIND_HINT_TY
On 2023/06/02 18:41, lijiang wrote:
> On Wed, May 31, 2023 at 2:07 PM wrote:
>
>> Date: Wed, 31 May 2023 14:01:36 +0800
>> From: Hsin-Yi Wang
>> To: crash-utility@redhat.com, k-hagio...@nec.com
>> Subject: [Crash-utility] [PATCH v2] Output prompt when stdin is not a
>> TTY.
>> Message
Hi Lianbo,
On 2023/05/18 16:53, HAGIO KAZUHITO(萩尾 一仁) wrote:
> From: Kazuhito Hagio
>
> Kernel commit fb799447ae29 ("x86,objtool: Split UNWIND_HINT_EMPTY in
> two"), which is contained in Linux 6.4 and later kernels, changed
> ORC_TYPE_CALL macro from 0 to 2. As a
On 2023/06/02 17:02, lijiang wrote:
> On Fri, Jun 2, 2023 at 12:33 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/06/02 12:46, lijiang wrote:
>>> On Fri, Jun 2, 2023 at 8:59 AM HAGIO KAZUHITO(萩尾 一仁) >>
>>> wrote:
>>>
>>>> On 2023/05/30
On 2023/06/02 13:49, lijiang wrote:
> On Fri, Jun 2, 2023 at 10:18 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/05/30 21:30, lijiang wrote:
>>> On Mon, May 29, 2023 at 9:03 AM HAGIO KAZUHITO(萩尾 一仁) <
>> k-hagio...@nec.com>
>>> wrote:
>>>
&
On 2023/06/02 12:46, lijiang wrote:
> On Fri, Jun 2, 2023 at 8:59 AM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>> On 2023/05/30 15:37, lijiang wrote:
>>> On Thu, May 25, 2023 at 10:36 AM HAGIO KAZUHITO(萩尾 一仁) <
>> k-hagio...@nec.com>
>>> wrote:
>>>
On 2023/06/01 18:59, lijiang wrote:
> On Thu, Jun 1, 2023 at 4:18 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>>>
>>> If this is not used, can we set it to an invalid value such as -1(ulong->
>>> 0x)? Otherwise we can still see a valid value by "help -
On 2023/06/01 18:52, lijiang wrote:
> On Thu, Jun 1, 2023 at 4:09 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>>> Is it possible to put the [patch 09/15] and [patch 10/15] together? They
>>> have similar changes.
>>
>> Sure.
>>
>>
> Thanks.
>
On 2023/06/01 18:46, lijiang wrote:
> On Thu, Jun 1, 2023 at 4:01 PM HAGIO KAZUHITO(萩尾 一仁)
> wrote:
>
>>>> - if (CRASHDEBUG(1)) {
>>>> + if (CRASHDEBUG(1) && lm->mod_load_symtable) {
>>>>
1 - 100 of 870 matches
Mail list logo
