Tested as part of this WIP branch for 8.4 integration test rebase: https://github.com/joe-lawrence/kpatch/tree/rhel-8.4-284-no-klp-arch (final 8.4 kernel TBD)

When trying this out, I think I found that kernel_is_rhel() is broken for z-stream kernels. It expects a "." after the el8, like .el8., but z-stream kernels have the minor version appended to the major version like .el8_3.. Am I crazy or does this mean that --klp-arch is already unintentionally disabled for all z-stream kernels?? edit: at least all RHEL8 z-stream kernels... RHEL7 z-stream kernels don't have this quirk.

Also I'm wondering how those tests passed ;-) edit: probably tested with a GA kernel?

Good catch.

Previous to this PR, the only callers of kernel_is_rhel are:

if grep -q "CONFIG_LIVEPATCH=y" "$CONFIGFILE" && (kernel_is_rhel || kernel_version_gte 4.9.0); then

	USE_KLP=1

	if kernel_is_rhel || ! kernel_version_gte 5.8.0; then
		USE_KLP_ARCH=1
		KPATCH_LDFLAGS="--unique=.parainstructions --unique=.altinstructions"
		CDO_FLAGS="--klp-arch"
	fi

which is only working by accident:

1. rhel-7 z-stream kernels should pass kernel_is_rhel as they are only tagged with .el7, never .el7_X
2. rhel-8 z-stream kernels may fail kernel_is_rhel, but they start at 4.18, so they will pass kernel_version_gte 4.9.0 and then later ! kernel_version_gte 5.8.0 conditions

However, you were correct to flag this bug since this PR introduces code which finally demonstrates the problem:

use_klp_arch()
{
	if kernel_is_rhel; then
		! rhel_kernel_version_gte 4.18.0-240.el8
	else
		! kernel_version_gte 5.8.0
	fi
}

this will incorrectly return false for z-stream rhel kernels greater than 4.18.0-240.el8. Since none exist yet, this was not tested.

To fix this, I can add a prep commit to this PR, how about a relaxed regex like:

	[[ "$ARCHVERSION" =~ \.el[78](_[0-9]+)? ]]

and if that is too permissive, this would take into account rhel-alt and kernels with non-empty build-ids (like .dt1 or .bz123):

	[[ "$ARCHVERSION" =~ \.el[78](_[0-9]+)?a?([A-Za-z0-9_.]+)?\. ]]

Ah good, glad I misread the severity of the bug :-) The more relaxed regex looks good to me.

Looking at it again this morning, the suggested regex would be equivalent to just removing the trailing dot:
[[ "$ARCHVERSION" =~ \.el[78] ]] which is to say any release with a .el7 or .el8 substring would match.

Tests for ("kpatch-build: fix kernel_is_rhel() for rhel-8 z-stream kernels"):

(Before) [[ "$ARCHVERSION" =~ \.el[78]\. ]]

!kernel_is_rhel 5.10.19-100.fc32.x86_64
!kernel_is_rhel 4.18.0-239.1.1.el8_1.x86_64
!kernel_is_rhel 4.18.0-239.1.1.el8_1build_ID123.x86_64
!kernel_is_rhel 4.18.0-239.1.1.el8_1.build_ID123.x86_64
!kernel_is_rhel 4.18.0-239.2.1.el8_2.x86_64
kernel_is_rhel  4.18.0-240.el8.x86_64
!kernel_is_rhel 4.18.0-240.1.1.el8_1.x86_64
!kernel_is_rhel 4.18.0-240.1.1.el8_1build_ID123.x86_64
!kernel_is_rhel 4.18.0-240.1.1.el8_1.build_ID123.x86_64
!kernel_is_rhel 4.18.0-240.2.1.el8_2.x86_64
kernel_is_rhel  4.18.0-241.el8.x86_64
!kernel_is_rhel 4.18.0-241.1.1.el8_1.x86_64
!kernel_is_rhel 4.18.0-241.1.1.el8_1build_ID123.x86_64
!kernel_is_rhel 4.18.0-241.1.1.el8_1.build_ID123.x86_64
!kernel_is_rhel 4.18.0-241.2.1.el8_2.x86_64

(After) [[ "$ARCHVERSION" =~ \.el[78] ]]

!kernel_is_rhel 5.10.19-100.fc32.x86_64
kernel_is_rhel  4.18.0-239.1.1.el8_1.x86_64
kernel_is_rhel  4.18.0-239.1.1.el8_1build_ID123.x86_64
kernel_is_rhel  4.18.0-239.1.1.el8_1.build_ID123.x86_64
kernel_is_rhel  4.18.0-239.2.1.el8_2.x86_64
kernel_is_rhel  4.18.0-240.el8.x86_64
kernel_is_rhel  4.18.0-240.1.1.el8_1.x86_64
kernel_is_rhel  4.18.0-240.1.1.el8_1build_ID123.x86_64
kernel_is_rhel  4.18.0-240.1.1.el8_1.build_ID123.x86_64
kernel_is_rhel  4.18.0-240.2.1.el8_2.x86_64
kernel_is_rhel  4.18.0-241.el8.x86_64
kernel_is_rhel  4.18.0-241.1.1.el8_1.x86_64
kernel_is_rhel  4.18.0-241.1.1.el8_1build_ID123.x86_64
kernel_is_rhel  4.18.0-241.1.1.el8_1.build_ID123.x86_64
kernel_is_rhel  4.18.0-241.2.1.el8_2.x86_64

Looks good to me, While we're at it, might as well make kernel_is_rhel() work for .el9 to avoid any subtle future breakage?

Added .el9 to the regex