[Crash-utility] [PATCH v4 1/4] Improve the performance of symbol searching for kernel modules

[HAGIO KAZUHITO(萩尾 一仁)]

-----Original Message-----
> Hi Kazu,
> 
> Sorry for the late reply, it was a public holiday for the past few days...

No problem.

> 
> On Tue, Oct 5, 2021 at 4:51 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab at nec.com> wrote:
> >
> > Hi Tao,
> >
> > Found another issue.
> >
> > The first symbol of duplicated ones will not be shown by sym command
> > after mod -s.
> >
> > # crash -s
> > crash> sym cleanup_module | head -n 1
> > ffffffffc02527ff (t) cleanup_module [fuse]
> > crash> mod -s fuse
> >      MODULE       NAME                         BASE           SIZE  OBJECT FILE
> > ffffffffc025eac0  fuse                   ffffffffc023f000   151552
> /usr/lib/debug/lib/modules/4.18.0-305.el8.x86_64/kernel/fs/fuse/fuse.ko.debug
> > crash> sym cleanup_module | grep fuse
> >
> > It looks like symbol_search() has to return the lowest address symbol and
> > symbol_search_next() returns the next lowest symbol, so removing/installing
> > module symbols from/to the hash table breaks this.
> >
> > The patch will need sorted installation or other solution.
> >
> 
> Agreed, I haven't considered this case. Yes, a sorting installation is
> necessary.
> 
> > Also, I've not looked at this enough, but kallsyms_module_symbol() changes
> > spx->cnt from lm->mod_ext_symtable.  Is there no interference with the
> > patch?
> >
> 
> No, this patch didn't interfere with it. Actually I didn't notice
> kallsyms_module_symbol() also changed spx->cnt, so the patch
> definitely needs further improvement. I will think of a better
> solution for handling sp->cnt field, please wait for a while before I
> send the v5 patch.

ok..

fyi, store_load_module_symbols() also changes(clears) spx->cnt from
lm->mod_ext_symtable:

        for (spx = lm->mod_ext_symtable; spx <= lm->mod_ext_symend; spx++)
                spx->cnt = 0;

Thanks,
Kazu