8:10 p.m.
On 2022/09/27 17:56, lijiang wrote:
On Tue, Sep 27, 2022 at 4:27 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com>
wrote:
> cc Alexey, reverting this affects VMware folks.
>
> On 2022/09/27 15:27, Lianbo Jiang wrote:
>> This reverts commit 2f967fb5ebd737ce5eadba462df35935122e8865. John
>> Pittman reports that it causes a regression issue on the old Vmware
>> vmcore as below:
>>
>> crash> set scope dm_table_create
>> set: attempting to find/load "dm_mod" module debuginfo
>> MODULE NAME BASE SIZE
> OBJECT FILE
>> ffffffffa0012dc0 dm_mod ffffffffa0000000 102823
> /home/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug
>> scope: ffffffffa0006cf0 (dm_table_create)
>> crash> whatis struct dm_table
>> struct dm_table {
>> uint64_t features;
>> struct mapped_device *md;
>> unsigned int type;
>> unsigned int depth;
>> unsigned int counts[16];
>> sector_t *index[16];
>> unsigned int num_targets;
>> unsigned int num_allocated;
>> sector_t *highs;
>> struct dm_target *targets;
>> struct target_type *immutable_target_type;
>> unsigned int integrity_supported : 1;
>> unsigned int singleton : 1;
>> fmode_t mode;
>> struct list_head devices;
>> void (*event_fn)(void *);
>> void *event_context;
>> struct dm_md_mempools *mempools;
>> struct list_head target_callbacks;
>> }
>> SIZE: 312
>> crash> whatis _name_buckets --->| After using the whatis
> _name_buckets command,
>> struct list_head _name_buckets[64]; |
>> crash> whatis struct dm_table <---| it won't show the
contents
> of the dm_table struct.
>> struct dm_table {
>> int undefined__;
>> }
>> SIZE: 312
>> crash>
>>
>> With the patch, this issue disappeared.
> At first glance, I did not find any part of the patch that can cause
> the issue. Do you have any detailed information?
>
>
This issue is observed on an old Vmware vmcore, and looks like a regression
issue.
Is the vmcore a .vmss file? or one captured by kdump?
I tried to dig into the detail, the raw_supply() operation may affect
the
gdb behavior, it
will store the register values to a cache in the gdb.
So far I haven't got a good solution, let's see if Alex has a better way to
fix it, that would be welcome. Any thoughts?
I suspected that the issue might depend on the debuginfo, but could not
reproduce it with the same 2.6.32-754.35.1.el6.x86_64 vmlinux.
but even with reverting the patch, I found that "set scope 0" does not
work well, though not sure whether it's related to the issue.
crash-dev> mod -s dm_mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffffa0012dc0 dm_mod ffffffffa0000000 102823
/home/vmcore/2022-09-28-rhel610-754.35.1.el6/usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug
crash-dev> struct dm_table
struct dm_table {
int undefined__;
}
SIZE: 4
crash-dev> set scope dm_table_create
scope: ffffffffa0006cf0 (dm_table_create)
crash-dev> struct dm_table
struct dm_table {
uint64_t features;
struct mapped_device *md;
unsigned int type;
unsigned int depth;
unsigned int counts[16];
sector_t *index[16];
unsigned int num_targets;
unsigned int num_allocated;
sector_t *highs;
struct dm_target *targets;
struct target_type *immutable_target_type;
unsigned int integrity_supported : 1;
unsigned int singleton : 1;
fmode_t mode;
struct list_head devices;
void (*event_fn)(void *);
void *event_context;
struct dm_md_mempools *mempools;
struct list_head target_callbacks;
}
SIZE: 312
crash-dev> set scope 0 <<--- unset the scope
scope: 0 (not set)
crash-dev> struct dm_table
struct dm_table {
uint64_t features; <<--- but, same as above
struct mapped_device *md;
unsigned int type;
unsigned int depth;
unsigned int counts[16];
sector_t *index[16];
unsigned int num_targets;
unsigned int num_allocated;
sector_t *highs;
struct dm_target *targets;
struct target_type *immutable_target_type;
unsigned int integrity_supported : 1;
unsigned int singleton : 1;
fmode_t mode;
struct list_head devices;
void (*event_fn)(void *);
void *event_context;
struct dm_md_mempools *mempools;
struct list_head target_callbacks;
}
SIZE: 312
It looks like gdb-10.2 has some memory, other than "crash_text_scope"
in gdb-10.2/gdb/symtab.c.
On the other hand, with crash-7.3.2 "set scope 0" works as expected.
crash-7.3.2> mod -s dm_mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffffa0012dc0 dm_mod ffffffffa0000000 102823
/home/vmcore/2022-09-28-rhel610-754.35.1.el6/usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug
crash-7.3.2> struct dm_table
struct dm_table {
int undefined__;
}
SIZE: 4
crash-7.3.2> set scope dm_table_create
scope: ffffffffa0006cf0 (dm_table_create)
crash-7.3.2> struct dm_table
struct dm_table {
uint64_t features;
struct mapped_device *md;
unsigned int type;
unsigned int depth;
unsigned int counts[16];
sector_t *index[16];
unsigned int num_targets;
unsigned int num_allocated;
sector_t *highs;
struct dm_target *targets;
struct target_type *immutable_target_type;
unsigned int integrity_supported : 1;
unsigned int singleton : 1;
fmode_t mode;
struct list_head devices;
void (*event_fn)(void *);
void *event_context;
struct dm_md_mempools *mempools;
struct list_head target_callbacks;
}
SIZE: 312
crash-7.3.2> set scope 0
scope: 0 (not set)
crash-7.3.2> struct dm_table
struct dm_table {
int undefined__;
}
SIZE: 4
so I guess that "set scope" with gdb-10.2 has a problem in the
first place. The second issue above might become a clue.
Lianbo, is it possible to look into the issues more? It might
find a better implementation for "set scope".
Thanks,
Kazu