On 2022/09/27 17:56, lijiang wrote:
> On Tue, Sep 27, 2022 at 4:27 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@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?
It's a .vmss file.
> 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.
There may be a different issue, the 'set scope 0' can work in my case. Can you try the '-r' option to work around your 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.
The behavior is different between the gdb-10.2 and gdb-7.6, we had encountered several cases. But I'm not sure which one may affect this issue.
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".
Sure. Will try it. But it might be another issue. In my case, after reverting the commit, it can not be reproduced, otherwise, it is always reproduced.
Thanks.
Lianbo
Thanks,
Kazu