Messages in this thread | | | Subject | Re: [PATCH bpf-next] kallsyms: move module-related functions under correct configs | From | Daniel Borkmann <> | Date | Tue, 28 Mar 2023 10:23:10 +0200 |
| |
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@redhat.com> >>>> Reported-by: kernel test robot <lkp@intel.com> >>>> Link: https://lore.kernel.org/oe-kbuild-all/202303181535.RFDCnz3E-lkp@intel.com/ >>> >>> 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.
Also small nit, please fix the patch up wrt indentation to align with kernel coding style.
Thanks, Daniel
| |