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