Re: [PATCH bpf-next] kallsyms: move module-related functions under correct configs

[Viktor Malik]

On 3/28/23 10:23, Daniel Borkmann wrote:
> On 3/27/23 9:28 PM, Luis Chamberlain wrote:
> > On Mon, Mar 27, 2023 at 08:20:56PM +0200, Viktor Malik wrote:
> > > On 3/27/23 19:47, Luis Chamberlain wrote:
> > > > On Mon, Mar 27, 2023 at 06:12:51PM +0200, Viktor Malik wrote:
> > > > > Functions for searching module kallsyms should have non-empty
> > > > > definitions only if CONFIG_MODULES=y and CONFIG_KALLSYMS=y. Until now,
> > > > > only CONFIG_MODULES check was used for many of these, which may have
> > > > > caused complilation errors on some configs.
> > > > >
> > > > > This patch moves all relevant functions under the correct configs.
> > > > >
> > > > > Signed-off-by: Viktor Malik <vmalik@xxxxxxxxxx>
> > > > > Reported-by: kernel test robot <lkp@xxxxxxxxx>
> > > > > Link: https://lore.kernel.org/oe-kbuild-all/202303181535.RFDCnz3E-lkp@xxxxxxxxx/
> > > >
> > > > Thanks Viktor!  Does this fix something from an existing commit? If so
> > > > which one?  The commit log should mention it.
> > >
> > > Ah, right, I forgot about that. The commit log is missing:
> > >
> > > Fixes: bd5314f8dd2d ("kallsyms, bpf: Move find_kallsyms_symbol_value out of internal header")
> > >
> > > I can post v2 but I'm also fine with maintainers applying the tag.
> >
> > That patch went through the bpf tree so its fix can go throug that tree.
> > So up to Daniel if he wants a new patch.
>
> Fixing up is fine with me. Viktor, which config combinations did you test for this
> patch and under which architectures?
>
> I suspect kbuild bot might still complain. For example, your patch moves
> dereference_module_function_descriptor() stub definition under !CONFIG_MODULES ||
> !CONFIG_KALLSYMS. Looking at ppc's dereference_module_function_descriptor()
> implementation (!CONFIG_PPC64_ELF_ABI_V2 case), it's build under CONFIG_MODULES,
> so you'll have two different implementations of the functions, the generic one
> then w/o __weak attribute.

Right, I didn't notice this one, thanks. Looks like
dereference_module_function_descriptor will need to stay in the original
place (under CONFIG_MODULES only). I'll cross-compile for arches that
redefine this function (powerpc, ia64, parisc) with relevant config
combinations and submit v2. The rest of the functions don't have
arch-dependent implementations, so they should be fine.

> Also small nit, please fix the patch up wrt indentation to align with kernel coding
> style.

Ok, will do.

Thanks,
Viktor

> Thanks,
> Daniel