dm-vdo / kvdo

A kernel module which provide a pool of deduplicated and/or compressed block storage.
GNU General Public License v2.0
241 stars 46 forks source link

Build fails with kernel 5.14.0-503.14.1.el9_5.x86_64 #94

Open mtrojnar opened 2 days ago

mtrojnar commented 2 days ago

The following errors are returned:

  CC [M]  /home/mtrojnar/src/kvdo/vdo/logger.o
/home/mtrojnar/src/kvdo/vdo/io-factory.c: In function ‘get_block_device_from_name’:
/home/mtrojnar/src/kvdo/vdo/io-factory.c:90:33: error: implicit declaration of function ‘blkdev_get_by_dev’; did you mean ‘blkdev_get_no_open’? [-Werror=implicit-function-declaration]
   90 |                 factory->bdev = blkdev_get_by_dev(device, BLK_FMODE, NULL, &hops);
      |                                 ^~~~~~~~~~~~~~~~~
      |                                 blkdev_get_no_open
/home/mtrojnar/src/kvdo/vdo/io-factory.c:90:31: error: assignment to ‘struct block_device *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
   90 |                 factory->bdev = blkdev_get_by_dev(device, BLK_FMODE, NULL, &hops);
      |                               ^
  CC [M]  /home/mtrojnar/src/kvdo/vdo/logical-zone.o
/home/mtrojnar/src/kvdo/vdo/io-factory.c:122:33: error: implicit declaration of function ‘blkdev_get_by_path’; did you mean ‘blkdev_get_no_open’? [-Werror=implicit-function-declaration]
  122 |                 factory->bdev = blkdev_get_by_path(name, BLK_FMODE, NULL, &hops);
      |                                 ^~~~~~~~~~~~~~~~~~
      |                                 blkdev_get_no_open
/home/mtrojnar/src/kvdo/vdo/io-factory.c:122:31: error: assignment to ‘struct block_device *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
  122 |                 factory->bdev = blkdev_get_by_path(name, BLK_FMODE, NULL, &hops);
      |                               ^
/home/mtrojnar/src/kvdo/vdo/io-factory.c: In function ‘replace_uds_storage’:
/home/mtrojnar/src/kvdo/vdo/io-factory.c:197:9: error: implicit declaration of function ‘blkdev_put’; did you mean ‘bdev_fput’? [-Werror=implicit-function-declaration]
  197 |         blkdev_put(factory->bdev, NULL);
      |         ^~~~~~~~~~
      |         bdev_fput
  CC [M]  /home/mtrojnar/src/kvdo/vdo/memory-alloc.o
lorelei-sakai commented 2 days ago

Is this using the most recent release version (8.2.5.2)? From the version number, it looks like you're using an OracleLinux kernel, is that correct?

If you look in io-factory.c, you can see we do attempt to support a range of kernel versions, but we do so by relying on RHEL_RELEASE_VERSION and RHEL_RELEASE_EXTRA. If your kernel, say, doesn't define RHEL_RELEASE_EXTRA, the code could pick the wrong branch.

You could define RHEL_RELEASE_EXTRA=503 in your build, or you could edit io-factory.c to only include the branch you want (which is probably the one where all VDO_USE_ALTERNATE* symbols are undefined). The blkdev interface has been changing a lot lately and it's a bit tricky to try to keep it in sync.

mtrojnar commented 2 days ago

Your RHEL_RELEASE_EXTRA=503 workaround worked fine. Thank very much for your help.

I updated my Rocky Linux to release 9.5 today, and built the module against the latest kernel-devel package distributed with the operating system. I don't use any fancy non-standard kernel on that machine.

$ cat /etc/system-release
Rocky Linux release 9.5 (Blue Onyx)
$ dnf list installed kernel*
Installed Packages
kernel.x86_64                         5.14.0-427.40.1.el9_4           @baseos   
kernel.x86_64                         5.14.0-427.42.1.el9_4           @baseos   
kernel.x86_64                         5.14.0-503.14.1.el9_5           @baseos   
kernel-core.x86_64                    5.14.0-427.40.1.el9_4           @baseos   
kernel-core.x86_64                    5.14.0-427.42.1.el9_4           @baseos   
kernel-core.x86_64                    5.14.0-503.14.1.el9_5           @baseos   
kernel-devel.x86_64                   5.14.0-427.40.1.el9_4           @appstream
kernel-devel.x86_64                   5.14.0-427.42.1.el9_4           @appstream
kernel-devel.x86_64                   5.14.0-503.14.1.el9_5           @appstream
kernel-devel-matched.x86_64           5.14.0-503.14.1.el9_5           @appstream
kernel-headers.x86_64                 5.14.0-503.14.1.el9_5           @appstream
kernel-modules.x86_64                 5.14.0-427.40.1.el9_4           @baseos   
kernel-modules.x86_64                 5.14.0-427.42.1.el9_4           @baseos   
kernel-modules.x86_64                 5.14.0-503.14.1.el9_5           @baseos   
kernel-modules-core.x86_64            5.14.0-427.40.1.el9_4           @baseos   
kernel-modules-core.x86_64            5.14.0-427.42.1.el9_4           @baseos   
kernel-modules-core.x86_64            5.14.0-503.14.1.el9_5           @baseos   
kernel-modules-extra.x86_64           5.14.0-427.40.1.el9_4           @baseos   
kernel-modules-extra.x86_64           5.14.0-427.42.1.el9_4           @baseos   
kernel-modules-extra.x86_64           5.14.0-503.14.1.el9_5           @baseos   
kernel-srpm-macros.noarch             1.0-13.el9                      @appstream
kernel-tools.x86_64                   5.14.0-503.14.1.el9_5           @baseos   
kernel-tools-libs.x86_64              5.14.0-503.14.1.el9_5           @baseos
$ dnf provides /usr/src/kernels/5.14.0-503.14.1.el9_5.x86_64/
Last metadata expiration check: 2:35:47 ago on Fri Nov 22 16:24:15 2024.
kernel-devel-5.14.0-503.14.1.el9_5.x86_64 : Development package for building kernel modules to match the kernel
Repo        : @System
Matched from:
Other       : /usr/src/kernels/5.14.0-503.14.1.el9_5.x86_64/

kernel-devel-5.14.0-503.14.1.el9_5.x86_64 : Development package for building kernel modules to match the kernel
Repo        : appstream
Matched from:
Other       : /usr/src/kernels/5.14.0-503.14.1.el9_5.x86_64/

Also, it worked fine with the previous kernel.

lorelei-sakai commented 2 days ago

Thanks for the extra information. I'm glad it is working for you.

I'm a bit surprised that RHEL_RELEASE_EXTRA isn't propagated to the Rocky kernel, but we'll keep it in mind in the future and try not to rely on it. It isn't usually necesssary, and I think our older releases don't use it, so they didn't see this issue. I don't think it's worth doing a new release just for this, but I'll be sure to get this addressed for future releases.

mtrojnar commented 2 days ago

Rocky Linux is supposed to be built from open source RHEL SRPMs without any modifications, isn't it?

Please let me know if there is anything else I can help with.