Bcachefs patchset breaks the build for both kernel with default config and ZFS kmod

[extSunset]

The bcachefs patch causes problems when building the IVPU kernel module. By default, CONFIG_DRM_ACCEL_IVPU is set to m for kernel version 6.4+ (tested on 6.4.{9,10}). Build errors:

drivers/accel/ivpu/ivpu_gem.c:200:17: error: expected identifier
        ret = bo->ops->alloc_pages(bo);
                       ^
./include/linux/gfp.h:288:28: note: expanded from macro 'alloc_pages'
#define alloc_pages(...)                        alloc_hooks(alloc_pages_noprof(VA_ARGS))
                                                ^
./include/linux/alloc_tag.h:150:37: note: expanded from macro 'alloc_hooks'
#define alloc_hooks(_do_alloc)                                          \
                                                                        ^
drivers/accel/ivpu/ivpu_gem.c:200:17: error: expected expression 
./include/linux/gfp.h:288:28: note: expanded from macro 'alloc_pages'
#define alloc_pages(...)                        alloc_hooks(alloc_pages_noprof(VA_ARGS))
                                                ^
./include/linux/alloc_tag.h:151:2: note: expanded from macro 'alloc_hooks'
({                                                                      \
^
2 errors generated.

Also, the patchset prevents the ZFS kernel module from being built (tested on zfs-dkms 2.1.12 and 2.2.0-rc3, commit f9a2d94 via the internal linux-cachyos ZFS package). Build errors:

/var/lib/dkms/zfs-2.2.0/rc3/build/module/os/linux/spl/spl-kmem-cache.c:1252:10: error: call to undeclared function 'kmem_cache_alloc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                        obj = kmem_cache_alloc(slc, kmem_flags_convert(flags));
                              ^
/var/lib/dkms/zfs-2.2.0/rc3/build/module/os/linux/spl/spl-kmem-cache.c:1252:8: error: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion]
                        obj = kmem_cache_alloc(slc, kmem_flags_convert(flags));
                              ^ ~~~~~~~~~~~~

Tested when building with LLVM 15.0.7 and 16.0.3.
The issue may also apply to the LTS version of the kernel.

[sirlucjan]

I think these errors are more eligible to be reported to bcachefs developers. Regarding the lack of compatibility of bcachefs with zfs, we are unable to resolve anything.

[extSunset]

There is no support for ZFS compatibility, yes. But IVPU is an in-built kernel module, in the case of Arch Linux it is enabled by default. My suggestion for now is to mutually disable building ZFS and Bcachefs together, and when building with the latter, disable CONFIG_DRM_ACCEL_IVPU and display a warning about this issue.

[extSunset]

I will pass the problem on to the bcachefs developers.

[extSunset]

Could you please tell me the commit in the bcachefs repository that you used for patch?

[sirlucjan]

Latest one currently.

[extSunset]

Seems like there is no need for me to submit it, it's a pretty old issue: koverstreet/bcachefs#573

[extSunset]

According to the mentioned issue, cramfs doesn't build either.

[sirlucjan]

In a moment I will add an option that will prevent you from trying to build ZFS and bcachefs at the same time.

[sirlucjan]

@extSunset Could you check latest commits? I added what you asked for.

732d8ed...a353449

[extSunset]

@sirlucjan Thank you very much. I think we should leave the issue open for now, as it is more of a temporary solution than a permanent one.

[sirlucjan]

I did as much as I was able to do - the rest of the work belongs to the developers.

[sirlucjan]

@extSunset

Could you check if the error still occurs without applying this workaround? It has reportedly been resolved.

[sirlucjan]

I checked, it seems to be working.

[sirlucjan]

So I've reverted one workaround for bcachefs (related to config): a4638a2

[extSunset]

I apologise for such a late reply. It seems to be working while building with IVPU, but not with ZFS. Thank you.

[sirlucjan]

Is everything working properly now? Can we remove workaround?

[extSunset]

@sirlucjan It seems so. At least when building with GCC.

[sirlucjan]

@ptr1337 so why not remove the workaround?