Re: [Crash-utility] [RFC PATCH 08/15] Support "mod -d|-D" options
On 2023/05/30 21:30, lijiang wrote:
On Mon, May 29, 2023 at 9:03 AM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com>
wrote:
>>
>> + for (j = MOD_TEXT; j <
>>> MOD_MEM_NUM_TYPES; j++) {
>>> + lm->load_symtable[j] =
>>> NULL;
>>> + lm->load_symend[j] =
> NULL;
>>> + }
>>> + } else { /* somehow this function runs
> for
>>> unloaded modules */
>>>
>>
>> Could you please explain why it may get into the "else" code path?
And
> why
>> do we need to handle this situation for now? But not needed before the
>> module memory changes.
>
> This path is used by "mod -d|-D" and reinit_modules() for unloaded
modules.
>
> The old procedure always does the cleanup and reinstall of the hash
> entries, so kept it as it is.
>
I tried to add some debug information in the above code path, but did not
observe any output(via the mod -d/-D). It's strange.
With this change,
--- a/symbols.c
+++ b/symbols.c
@@ -13951,6 +13951,7 @@ delete_load_module(ulong base_addr)
lm->load_symend[j] = NULL;
}
} else { /* somehow this function runs for unloaded
modules */
+ fprintf(fp, "in the else block
(-D)\n");
for (j = MOD_TEXT; j < MOD_MEM_NUM_TYPES; j++)
{
if (!lm->symtable[j])
continue;
@@ -14016,6 +14017,7 @@ delete_load_module(ulong base_addr)
lm->load_symend[j] = NULL;
}
} else { /* somehow this function runs for unloaded
modules */
+ fprintf(fp, "in the else block
(-d)\n");
for (j = MOD_TEXT; j < MOD_MEM_NUM_TYPES; j++)
{
if (!lm->symtable[j])
continue;
These should be printed:
crash-6.4> mod -s dm_mod
MODULE NAME TEXT_BASE SIZE OBJECT FILE
ffffffffc042fd00 dm_mod ffffffffc0418000 237568 dm-mod.ko
crash-6.4> mod -d dm_mod
crash-6.4> mod -d dm_mod
in the else block (-d)
crash-6.4> mod -d dm_log
in the else block (-d)
crash-6.4> mod -D | head
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
in the else block (-D)
Thanks,
Kazu