Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.1] linux/spl/kmem_cache: undefine kmem_cache_alloc before defining it #15143

Conversation

RaitoBezarius
Copy link
Contributor

@RaitoBezarius RaitoBezarius commented Aug 2, 2023

Motivation and Context

When compiling a kernel with bcachefs and zfs, the two macros will collide, making it impossible to have both filesystems.

It is sufficient to just undefine the macro before calling it.

On why this should be in ZFS rather than bcachefs, currently, bcachefs is not an in-tree filesystem, but, it has a reasonably high chance of getting included soon.

This avoids the breakage in ZFS early, this patch may be distributed downstream in NixOS and is already used there.

I will send the PR for 2.2 too (on master).

Description

Undefining the macro kmem_cache_alloc before its redefinition to ensure we have "the right one".

How Has This Been Tested?

I have been running a NixOS system with a bcachefs rootfs and various ZFS external disks with it for more than 2 weeks now.
I did not run specific tests beyond workstation-class usage.

See NixOS/nixpkgs#243075 the downstream PR.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
  • Documentation (a change to man pages or other documentation)

Checklist:

@RaitoBezarius RaitoBezarius changed the title linux/spl/kmem_cache: undefine kmem_cache_alloc before defining it [2.1] linux/spl/kmem_cache: undefine kmem_cache_alloc before defining it Aug 2, 2023
When compiling a kernel with bcachefs and zfs, the two macros will collide, making it impossible
to have both filesystems.

It is sufficient to just undefine the macro before calling it.

On why this should be in ZFS rather than bcachefs, currently, bcachefs is not a in-tree filesystem, but,
it has a reasonably high chance of getting included soon.

This avoids the breakage in ZFS early, this patch may be distributed downstream in NixOS and is already used there.
Copy link
Contributor

@behlendorf behlendorf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for noticing this. Please go ahead and rebase this PR on the master branch, once it's merged we'll cherry pick it back to the 2.1 and 2.2 branches.

* or in-tree filesystem that may define kmem_cache_alloc,
* like bcachefs does it now.
*/
#undef kmem_cache_alloc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend wrapping this #undef with a #ifdef kmem_cache_alloc guard. This will avoid any pedantic compiler warnings about undef'ing a define which doesn't exist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in #15144 which is the rebased version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can close this one if you want.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great. Let's go ahead and open new PRs for the backports after it's merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants