veeam/blksnap

Problems to compile on 5.17 liquorix kernels...

andymend opened this issue · 2 comments

andymend commented

I can't seem to get blksnap to compile on 5.17. I've tried a few versions-- here is the log from 5.17.0-2.3-liquorix-amd64 on Ubuntu 20.04 using gcc 9.4.0 (I get a gcc mismatch warning using gcc 11, but it still doesn't compile) :
DKMS make.log for blksnap-1.0.0.0 for kernel 5.17.0-2.3-liquorix-amd64 (x86_64)
Mon 11 Apr 2022 09:11:11 AM PDT
make: Entering directory '/usr/src/linux-headers-5.17.0-2.3-liquorix-amd64'
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/big_buffer.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/cbt_map.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/chunk.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/ctrl.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/diff_io.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/diff_area.o
CC [M] /var/lib/dkms/blksnap/1.0.0.0/build/diff_buffer.o
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:360:24: error: array type has incomplete element type ‘struct klp_func’
360 | static struct klp_func funcs[] = {
| ^~~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:362:3: error: field name not in record or union initializer
362 | .old_name = "submit_bio_noacct",
| ^
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:362:3: note: (near initialization for ‘funcs’)
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:363:3: error: field name not in record or union initializer
363 | .new_func = submit_bio_noacct_handler,
| ^
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:363:3: note: (near initialization for ‘funcs’)
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:368:26: error: array type has incomplete element type ‘struct klp_object’
368 | static struct klp_object objs[] = {
| ^~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:371:3: error: field name not in record or union initializer
371 | .funcs = funcs,
| ^
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:371:3: note: (near initialization for ‘objs’)
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:376:15: error: variable ‘patch’ has initializer but incomplete type
376 | static struct klp_patch patch = {
| ^~~~~~~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:377:3: error: ‘struct klp_patch’ has no member named ‘mod’
377 | .mod = THIS_MODULE,
| ^~~
In file included from ./include/linux/linkage.h:7,
from ./arch/x86/include/asm/cache.h:5,
from ./include/linux/cache.h:6,
from ./include/linux/time.h:5,
from ./include/linux/stat.h:19,
from ./include/linux/module.h:13,
from /var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:3:
./include/linux/export.h:17:21: warning: excess elements in struct initializer
17 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:377:9: note: in expansion of macro ‘THIS_MODULE’
377 | .mod = THIS_MODULE,
| ^~~
In file included from ./include/linux/linkage.h:7,
from ./arch/x86/include/asm/cache.h:5,
from ./include/linux/cache.h:6,
from ./include/linux/time.h:5,
from ./include/linux/stat.h:19,
from ./include/linux/module.h:13,
from /var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:3:
./include/linux/export.h:17:21: warning: excess elements in struct initializer
17 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:377:9: note: in expansion of macro ‘THIS_MODULE’
377 | .mod = THIS_MODULE,
| ^~~~~~~~~~~
./include/linux/export.h:17:21: note: (near initialization for ‘patch’)
17 | #define THIS_MODULE (&__this_module)
| ^
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:377:9: note: in expansion of macro ‘THIS_MODULE’
377 | .mod = THIS_MODULE,
| ^~~~~~~~~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:378:3: error: ‘struct klp_patch’ has no member named ‘objs’
378 | .objs = objs,
| ^~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:378:10: warning: excess elements in struct initializer
378 | .objs = objs,
| ^~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:378:10: note: (near initialization for ‘patch’)
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c: In function ‘lp_filter_init’:
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:383:9: error: implicit declaration of function ‘klp_enable_patch’ [-Werror=implicit-function-declaration]
383 | return klp_enable_patch(&patch);
| ^~~~~~~~~~~~~~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c: At top level:
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:376:25: error: storage size of ‘patch’ isn’t known
376 | static struct klp_patch patch = {
| ^~~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:368:26: warning: ‘objs’ defined but not used [-Wunused-variable]
368 | static struct klp_object objs[] = {
| ^~~~
/var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.c:360:24: warning: ‘funcs’ defined but not used [-Wunused-variable]
360 | static struct klp_func funcs[] = {
| ^~~~~
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:288: /var/lib/dkms/blksnap/1.0.0.0/build/lp_filter.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1838: /var/lib/dkms/blksnap/1.0.0.0/build] Error 2
make: Leaving directory '/usr/src/linux-headers-5.17.0-2.3-liquorix-amd64'

SergeiShtepa commented

I checked the build on vanilla kernel 5.17. This problem looks like a feature of the liquorix kernel.
Perhaps the live patching feature is disabled in it. I advise you to compare the config files of this kernel and the kernel from the Ubuntu distributive.
I will try to find time to look at the liquorix kernel in the future.

SergeiShtepa commented

I check it:

$ cat /boot/config-5.17.0-2.3-liquorix-amd64 | grep LIVEPATCH
CONFIG_HAVE_LIVEPATCH=y
# CONFIG_LIVEPATCH is not set

There are two ways to solve the problem:

  1. Enable LIVEPATCH and rebuild the kernel.
  2. Redesign the handling mechanism in lp_filter (it's will be ftrace_filter).
$ cat /boot/config-5.17.0-2.3-liquorix-amd64 | grep DYNAMIC_FTRACE_WITH_REGS
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
$ cat /boot/config-5.17.0-2.3-liquorix-amd64 | grep DYNAMIC_FTRACE_WITH_ARGS
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS=y
CONFIG_DYNAMIC_FTRACE_WITH_ARGS=y

I'll think about the second way.

Thanks for the feedback!
P.S.: You can also rebuild the kernel from the source code by applying a patch. In this case, the module will be in-tree.