On 2022/09/29 12:32, lijiang wrote:
>>>> 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 see.
>>> 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?
Nice, "set scope 0" works well with "mod -sr dm_mod".
>> 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.
ok, they looks different.
Anyway, Alexey's patch was already released in crash-8.0.0, reverting it
will also be a regression for VMware folks. If we do it, I think at least
the necessity of reverting should be explained enough.
Thanks,
Kazu
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
