Linux: Guard proc sentinel values using kernel version.

[IvanVolosyuk]

Fixes openzfs kernel module loading on 6.11+ with CONFIG_RANDSTRUCT=y

Motivation and Context

This change fixes #16620 Linux kernel after 6.1-rc1 stopped using proc sentinel records and relies on ARRAY_SIZE. ZFS still uses the sentinel values, which causes crash:

sysctl table check failed: kernel/spl/(null) No proc_handler

I bisected the kernel commit where the issue starts to occur: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d7a76ec87195ced6910b0ca10ca133bb316c90f5

Description

The fix is to guard proc sentinel values using kernel version. Ideally it should be more targeted, but I don't know how to do that and if it even possible.

How Has This Been Tested?

• Build and run both v6.10 and v6.11 linux kernel in VM within root on ZFS test system.

Types of changes

• [x] 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:

• [x] My code follows the OpenZFS code style requirements.
• [ ] I have updated the documentation accordingly.
• [x] I have read the contributing document.
• [ ] I have added tests to cover my changes.
• [ ] I have run the ZFS Test Suite with this change applied.
• [x] All commit messages are properly formatted and contain Signed-off-by.

[amotin]

I bisected the kernel commit where the issue starts to occur:

This is the commit when it stopped allow the sentinels. Instead I think you could dig deeper to find when they become optional, since that is where the KPI has changed, and I wonder if it was more documented back then. The later was just a compatibility window.

[snajpa]

Kernel versions aren't reliable, stuff can be backported to older kernels (RHEL kernels are known for that), testing a kernel version within OpenZFS code to make a decision of which code to use is thus not a good idea. It always needs a specific configure test, which affects zfs_config.h, which is what you can then use in the source to disambiguate between the different variants.

(I don't speak m4 either, I always just go looking for something in the config/ dir that is the closest to what I'm trying to do and then just copy and modify it)