[PATCH 0/5] objtool/klp-build: small fixups and enhancements

[PATCH 0/5] objtool/klp-build: small fixups and enhancements

[Joe Lawrence]

Hi Josh,

While porting over some internal tests to use klp-build, I tripped over
a few small usability bugs and nits.  These are aren't show-stoppers,
but a few were pretty esoteric to debug and might lead some users down
similar rabbit holes.

Look for per-patch failure messages and reproducers in the individual
patch diffstat areas.  LMK if any of those details should make it into
the commit messages as I assumed they were only interesting for
reviewing context.

Finally these are very lightly tested, so any additional patches you'd
like to send through these changes would be welcome.

-- Joe


Joe Lawrence (5):
  objtool/klp: limit parent .git directory search
  objtool/klp: handle patches that add new files
  objtool/klp: validate patches with git apply --recount
  objtool/klp: add -z/--fuzz patch rebasing option
  objtool/klp: provide friendlier error messages

 scripts/livepatch/klp-build | 144 ++++++++++++++++++++++++++++++++----
 1 file changed, 130 insertions(+), 14 deletions(-)

-- 
2.52.0

[PATCH 1/5] objtool/klp: limit parent .git directory search

[Joe Lawrence]

When klp-build runs git commands, they may search upwards for a .git/
directory if one isn't found in the current $SRC path. This can lead to
unexpected behavior if the kernel source is nested within another git
tree.

Set and export GIT_CEILING_DIRECTORIES to the parent of $SRC to restrict
git lookups to the local kernel tree only. This ensures that git
operations remain consistent and prevents picking up repository state
from parent directories.

Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
---
 scripts/livepatch/klp-build | 3 +++
 1 file changed, 3 insertions(+)

I encountered this failure mode when running klp-build out of a kernel
source rpm extraction inside a testing git repo tree.  In this case,
there is no <kernel_dir>/.git, but there is one further up the directory
hierarchy.  This confuses the script when it tries to fixup the patch as
git commands will keep looking for a .git in parent directories unless
otherwise bounded [1].

Here's a quick repo:

  $ cd /tmp
  $ mkdir test_dir
  $ cd test_dir

  # Force a /tmp/test_dir/.git
  $ git init

  $ git clone --depth=1 --branch=v6.19-rc4 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  $ cd linux

  $ wget https://raw.githubusercontent.com/dynup/kpatch/refs/heads/master/examples/cmdline-string.patch

  # Basic config for livepatching ...
  $ make -j$(nproc) defconfig
  $ ./scripts/config --file .config \
      --set-val CONFIG_FTRACE y \
      --set-val CONFIG_KALLSYMS_ALL y \
      --set-val CONFIG_FUNCTION_TRACER y \
      --set-val CONFIG_DYNAMIC_FTRACE y \
      --set-val CONFIG_DYNAMIC_DEBUG y \
      --set-val CONFIG_LIVEPATCH y
  $ make olddefconfig

  # GOOD BUILD
  $ ./scripts/livepatch/klp-build -T cmdline-string.patch
  Validating patch(es)
  Building original kernel
  Copying original object files
  Fixing patch(es)
  Building patched kernel
  Copying patched object files
  Diffing objects
  vmlinux.o: changed function: cmdline_proc_show
  Building patch module: livepatch-cmdline-string.ko
  SUCCESS

  # BAD BUILD - remove .git/ to simulate rpm/tarball
  $ rm -rf .git
  $ ./scripts/livepatch/klp-build -T cmdline-string.patch
  Validating patch(es)
  Building original kernel
  Copying original object files
  Fixing patch(es)
  error: No valid patches in input (allow with "--allow-empty")
  error: klp-build: line 350: 'git apply "${extra_args[@]}"'
  error: klp-build: line 351: '( cd "$SRC"; sed -n '/^-- /q;p' "$patch" | git apply "${extra_args[@]}" )'

[1] https://git-scm.com/book/be/v2/Git-Internals-Environment-Variables#:~:text=GIT_DIR%20is%20the%20location,your%20shell%20prompt.

diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 882272120c9e..964f9ed5ee1b 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -52,6 +52,9 @@ PATCH_TMP_DIR="$TMP_DIR/tmp"
 
 KLP_DIFF_LOG="$DIFF_DIR/diff.log"
 
+# Restrict Git repository lookup to the local $SRC path
+export GIT_CEILING_DIRECTORIES="$(dirname "$SRC")"
+
 grep0() {
 	command grep "$@" || true
 }
-- 
2.52.0

[PATCH 2/5] objtool/klp: handle patches that add new files

[Joe Lawrence]

The klp-build script prepares a clean patch by populating two temporary
directories ('a' and 'b') with source files and diffing the result.
However, this process currently fails when a patch introduces a new
source file as the script attempts to copy files that do not yet exist
in the original source tree.

Update the file-copying logic in refresh_patch() to verify existence
before processing:

- Filter the files list to ensure only files currently present in $SRC
  are copied to the 'a' directory.
- Apply the patch, then verify file existence again before copying
  to the 'b' directory.
- Ignore "/dev/null" entries, which represent non-existent files in
  patch headers.

This allows klp-build to successfully process patches that add new
source files to the kernel.

Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
---
 scripts/livepatch/klp-build | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

This problem was found with a simple patch that included a new header
file:

  diff --git a/fs/proc/cmdline.c b/fs/proc/cmdline.c
  index a6f76121955f..d1927ad00bb3 100644
  --- a/fs/proc/cmdline.c
  +++ b/fs/proc/cmdline.c
  @@ -4,11 +4,11 @@
   #include <linux/proc_fs.h>
   #include <linux/seq_file.h>
   #include "internal.h"
  +#include "test.h"
   
   static int cmdline_proc_show(struct seq_file *m, void *v)
   {
  -       seq_puts(m, saved_command_line);
  -       seq_putc(m, '\n');
  +       seq_printf(m, test_string, saved_command_line);
          return 0;
   }
   
  diff --git a/fs/proc/test.h b/fs/proc/test.h
  new file mode 100644
  index 000000000000..94de7114cf86
  --- /dev/null
  +++ b/fs/proc/test.h
  @@ -0,0 +1 @@
  +#define test_string "%s klp=1\n"

And the build failure:

  $ ./scripts/livepatch/klp-build /tmp/new-file-test.patch
  Validating patch(es)
  error: dev/null: does not exist and --remove not passed
  fatal: Unable to process path dev/null
  error: klp-build: line 315: 'git update-index -q --refresh -- "${files[@]}"'
  error: klp-build: line 316: '( cd "$SRC"; git update-index -q --refresh -- "${files[@]}" )'
  error: fs/proc/test.h: No such file or directory
  error: patch failed: fs/proc/cmdline.c:4
  error: fs/proc/cmdline.c: patch does not apply
  error: klp-build: line 366: 'git apply --reverse "${extra_args[@]}"'
  error: klp-build: line 367: 'echo "error: $SCRIPT: $*" 1>&2'

While I don't think the script needs to handle a patch that is trying to
add completely new compilation units (that would require Makefile
changes, generate new .o files, etc.), I do think it would be helpful to
at least support patches that add new header/included files.  For
example, a common klp-macros.h file may be helpful to mimic the old
kpatch-build kpatch-macros.h, collect shadow variable IDs, etc.

diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 964f9ed5ee1b..5a8c592c4c15 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -426,6 +426,8 @@ refresh_patch() {
 	local patch="$1"
 	local tmpdir="$PATCH_TMP_DIR"
 	local files=()
+	local orig_files=()
+	local patched_files=()
 
 	rm -rf "$tmpdir"
 	mkdir -p "$tmpdir/a"
@@ -434,12 +436,20 @@ refresh_patch() {
 	# Get all source files affected by the patch
 	get_patch_files "$patch" | mapfile -t files
 
-	# Copy orig source files to 'a'
-	( cd "$SRC" && echo "${files[@]}" | xargs cp --parents --target-directory="$tmpdir/a" )
+	# Copy orig source files to 'a', filter to only existing files
+	for file in "${files[@]}"; do
+		[[ "$file" != "dev/null" ]] && [[ -f "$SRC/$file" ]] && orig_files+=("$file")
+	done
+	( cd "$SRC" && echo "${orig_files[@]}" | xargs cp --parents --target-directory="$tmpdir/a" )
 
-	# Copy patched source files to 'b'
+	# Copy patched source files to 'b', filter to only existing
+	# files after patch application
 	apply_patch "$patch" --recount
-	( cd "$SRC" && echo "${files[@]}" | xargs cp --parents --target-directory="$tmpdir/b" )
+	for file in "${files[@]}"; do
+		[[ "$file" != "dev/null" ]] && [[ -f "$SRC/$file" ]] && patched_files+=("$file")
+	done
+	( cd "$SRC" && echo "${patched_files[@]}" | xargs cp --parents --target-directory="$tmpdir/b" )
+
 	revert_patch "$patch" --recount
 
 	# Diff 'a' and 'b' to make a clean patch
-- 
2.52.0

Re: [PATCH 2/5] objtool/klp: handle patches that add new files

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 12:59:47PM -0500, Joe Lawrence wrote:
> diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> index 964f9ed5ee1b..5a8c592c4c15 100755
> --- a/scripts/livepatch/klp-build
> +++ b/scripts/livepatch/klp-build
> @@ -426,6 +426,8 @@ refresh_patch() {
>  	local patch="$1"
>  	local tmpdir="$PATCH_TMP_DIR"
>  	local files=()
> +	local orig_files=()
> +	local patched_files=()
>  
>  	rm -rf "$tmpdir"
>  	mkdir -p "$tmpdir/a"
> @@ -434,12 +436,20 @@ refresh_patch() {
>  	# Get all source files affected by the patch
>  	get_patch_files "$patch" | mapfile -t files
>  
> -	# Copy orig source files to 'a'
> -	( cd "$SRC" && echo "${files[@]}" | xargs cp --parents --target-directory="$tmpdir/a" )
> +	# Copy orig source files to 'a', filter to only existing files
> +	for file in "${files[@]}"; do
> +		[[ "$file" != "dev/null" ]] && [[ -f "$SRC/$file" ]] && orig_files+=("$file")

Can we fix get_patch_files() so it filters out /dev/null (or "dev/null"
as it appears to be for some reason)?  I don't think any of its callers
would want that.

Also I'm thinking these checks would be more precise if they parsed the
patch file directly to get the before/after file names, as that would
catch more cases of malformed patches.

So maybe we'd just need something like get_patch_input_files() and
get_patch_output_files() here (not sure about the naming)?

BTW, for the patch subject prefixes I've been using
"livepatch/klp-build" for changes to klp-build and "objtool/klp" for
objtool/klp-diff.c, so let's keep doing that unless anybody has any
better suggestions.

-- 
Josh

[PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Joe Lawrence]

The klp-build script performs a sanity check on user-provided patches
using `git apply --check`.  However, this check is less strict than the
subsequent patch fixup phase, which runs `git apply --recount`.

As a result, patches with line count drift (fuzz) may pass the initial
validation but fail during fixup. Update the initial validation phase to
include the '--recount' flag.  This ensures a consistent check across
both phases and allows the script to fail fast on malformed or drifted
patches.

Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
---
 scripts/livepatch/klp-build | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Here are the build errors:

  $ ./scripts/livepatch/klp-build -T combined.patch 
  Validating patch(es)
  Building original kernel
  
  Copying original object files
  Fixing patch(es)
  error: patch failed: fs/proc/cmdline.c:6
  error: fs/proc/cmdline.c: patch does not apply
  error: klp-build: line 350: 'git apply "${extra_args[@]}"'
  error: klp-build: line 351: '( cd "$SRC"; sed -n '/^-- /q;p' "$patch" | git apply "${extra_args[@]}" )'

This was a strange one to debug, but I finally narrowed it down to
pecular `git apply` behavior depending on the presence of the --recount
flag.

Consider a patch offset by a line:

  $ cat combined.patch
  --- src.orig/fs/proc/cmdline.c	2022-10-24 15:41:08.858760066 -0400
  +++ src/fs/proc/cmdline.c	2022-10-24 15:41:11.698715352 -0400
  @@ -6,8 +6,7 @@
  
   static int cmdline_proc_show(struct seq_file *m, void *v)
   {
  -	seq_puts(m, saved_command_line);
  -	seq_putc(m, '\n');
  +	seq_printf(m, "%s livepatch=1\n", saved_command_line);
   	return 0;
   }
  
  --- a/fs/proc/version.c
  +++ b/fs/proc/version.c
  @@ -9,6 +9,7 @@
  
   static int version_proc_show(struct seq_file *m, void *v)
   {
  +	seq_printf(m, "livepatch ");
   	seq_printf(m, linux_proc_banner,
   		utsname()->sysname,
   		utsname()->release,

GNU patch reports the offset:

  $ patch --dry-run -p1 < combined.patch
  checking file fs/proc/cmdline.c
  Hunk #1 succeeded at 7 (offset 1 line).
  checking file fs/proc/version.c

It would pass the initial check as per validate_patches():

  $ git apply --check < combined.patch && echo "ok"
  ok

But later fail the patch application by refresh_patch():

  $ git apply --check --recount < combined.patch
  error: patch failed: fs/proc/cmdline.c:6
  error: fs/proc/cmdline.c: patch does not apply

Adding the same --recount argument to validate_patches() would allow the
script to fail fast and not (cryptically) way later:

  $ ./scripts/livepatch/klp-build -T combined.patch
  Validating patch(es)
  error: patch failed: fs/proc/cmdline.c:6
  error: fs/proc/cmdline.c: patch does not apply
  error: klp-build: combined.patch doesn't apply
  error: klp-build: line 453: '( cd "$SRC"; sed -n '/^-- /q;p' "$patch" | git apply "${extra_args[@]}" || die "$patch doesn't apply" )'

diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 5a8c592c4c15..2313bc909f58 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -379,10 +379,11 @@ revert_patch() {
 }
 
 apply_patches() {
+	local extra_args=("$@")
 	local patch
 
 	for patch in "${PATCHES[@]}"; do
-		apply_patch "$patch"
+		apply_patch "$patch" "${extra_args[@]}"
 	done
 }
 
@@ -399,8 +400,8 @@ revert_patches() {
 
 validate_patches() {
 	check_unsupported_patches
-	apply_patches
-	revert_patches
+	apply_patches --recount
+	revert_patches --recount
 }
 
 do_init() {
-- 
2.52.0

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 12:59:48PM -0500, Joe Lawrence wrote:
> Consider a patch offset by a line:
> 
>   $ cat combined.patch
>   --- src.orig/fs/proc/cmdline.c	2022-10-24 15:41:08.858760066 -0400
>   +++ src/fs/proc/cmdline.c	2022-10-24 15:41:11.698715352 -0400
>   @@ -6,8 +6,7 @@
>   
>    static int cmdline_proc_show(struct seq_file *m, void *v)
>    {
>   -	seq_puts(m, saved_command_line);
>   -	seq_putc(m, '\n');
>   +	seq_printf(m, "%s livepatch=1\n", saved_command_line);
>    	return 0;
>    }
>   
>   --- a/fs/proc/version.c
>   +++ b/fs/proc/version.c
>   @@ -9,6 +9,7 @@
>   
>    static int version_proc_show(struct seq_file *m, void *v)
>    {
>   +	seq_printf(m, "livepatch ");
>    	seq_printf(m, linux_proc_banner,
>    		utsname()->sysname,
>    		utsname()->release,
> 
> GNU patch reports the offset:
> 
>   $ patch --dry-run -p1 < combined.patch
>   checking file fs/proc/cmdline.c
>   Hunk #1 succeeded at 7 (offset 1 line).
>   checking file fs/proc/version.c
> 
> It would pass the initial check as per validate_patches():
> 
>   $ git apply --check < combined.patch && echo "ok"
>   ok
> 
> But later fail the patch application by refresh_patch():
> 
>   $ git apply --check --recount < combined.patch
>   error: patch failed: fs/proc/cmdline.c:6
>   error: fs/proc/cmdline.c: patch does not apply

Hm, isn't the whole point of --recount that it ignores the line numbers?
Or does it just ignore the numbers after the commas (the counts)?

-- 
Josh

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Joe Lawrence]

On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 12:59:48PM -0500, Joe Lawrence wrote:
> > Consider a patch offset by a line:
> > 
> >   $ cat combined.patch
> >   --- src.orig/fs/proc/cmdline.c	2022-10-24 15:41:08.858760066 -0400
> >   +++ src/fs/proc/cmdline.c	2022-10-24 15:41:11.698715352 -0400
> >   @@ -6,8 +6,7 @@
> >   
> >    static int cmdline_proc_show(struct seq_file *m, void *v)
> >    {
> >   -	seq_puts(m, saved_command_line);
> >   -	seq_putc(m, '\n');
> >   +	seq_printf(m, "%s livepatch=1\n", saved_command_line);
> >    	return 0;
> >    }
> >   
> >   --- a/fs/proc/version.c
> >   +++ b/fs/proc/version.c
> >   @@ -9,6 +9,7 @@
> >   
> >    static int version_proc_show(struct seq_file *m, void *v)
> >    {
> >   +	seq_printf(m, "livepatch ");
> >    	seq_printf(m, linux_proc_banner,
> >    		utsname()->sysname,
> >    		utsname()->release,
> > 
> > GNU patch reports the offset:
> > 
> >   $ patch --dry-run -p1 < combined.patch
> >   checking file fs/proc/cmdline.c
> >   Hunk #1 succeeded at 7 (offset 1 line).
> >   checking file fs/proc/version.c
> > 
> > It would pass the initial check as per validate_patches():
> > 
> >   $ git apply --check < combined.patch && echo "ok"
> >   ok
> > 
> > But later fail the patch application by refresh_patch():
> > 
> >   $ git apply --check --recount < combined.patch
> >   error: patch failed: fs/proc/cmdline.c:6
> >   error: fs/proc/cmdline.c: patch does not apply
> 
> Hm, isn't the whole point of --recount that it ignores the line numbers?
> Or does it just ignore the numbers after the commas (the counts)?
> 

I don't know exactly.  As I continue digging into the test that sent me
down this path, I just found that `git apply --recount` doesn't like
some output generated by `combinediff -q --combine` even with NO line
drift... then if I manually added in corresponding diff command lines
(to make it look more like a .patch file generated by `diff -Nu`), ie:

  diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c     <---
  --- src.orig/fs/proc/array.c
  +++ src/fs/proc/array.c

Suddenly `git apply --recount` is happy with the patch.

So I suspect that I started with git not liking the hunks generated by
combinediff and drove it to the rebase feature, which solves a more
interesting problem, but by side effect smoothed over this format
issue when it recreated the patch with git.

Anyway, I think this patch still stands on it's own: perform the same
apply/revert check as what would happen in the fixup steps to fail
faster for the user?

--
Joe 

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote:
> On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
> > Hm, isn't the whole point of --recount that it ignores the line numbers?
> > Or does it just ignore the numbers after the commas (the counts)?
> > 
> 
> I don't know exactly.  As I continue digging into the test that sent me
> down this path, I just found that `git apply --recount` doesn't like
> some output generated by `combinediff -q --combine` even with NO line
> drift... then if I manually added in corresponding diff command lines
> (to make it look more like a .patch file generated by `diff -Nu`), ie:
> 
>   diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c     <---
>   --- src.orig/fs/proc/array.c
>   +++ src/fs/proc/array.c
> 
> Suddenly `git apply --recount` is happy with the patch.
> 
> So I suspect that I started with git not liking the hunks generated by
> combinediff and drove it to the rebase feature, which solves a more
> interesting problem, but by side effect smoothed over this format
> issue when it recreated the patch with git.
> 
> Anyway, I think this patch still stands on it's own: perform the same
> apply/revert check as what would happen in the fixup steps to fail
> faster for the user?

If we just run fix_patches() at the beginning then can we just get rid
of validate_patches() altogether?

-- 
Josh

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 02:59:53PM -0800, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote:
> > On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
> > > Hm, isn't the whole point of --recount that it ignores the line numbers?
> > > Or does it just ignore the numbers after the commas (the counts)?
> > > 
> > 
> > I don't know exactly.  As I continue digging into the test that sent me
> > down this path, I just found that `git apply --recount` doesn't like
> > some output generated by `combinediff -q --combine` even with NO line
> > drift... then if I manually added in corresponding diff command lines
> > (to make it look more like a .patch file generated by `diff -Nu`), ie:
> > 
> >   diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c     <---
> >   --- src.orig/fs/proc/array.c
> >   +++ src/fs/proc/array.c
> > 
> > Suddenly `git apply --recount` is happy with the patch.
> > 
> > So I suspect that I started with git not liking the hunks generated by
> > combinediff and drove it to the rebase feature, which solves a more
> > interesting problem, but by side effect smoothed over this format
> > issue when it recreated the patch with git.
> > 
> > Anyway, I think this patch still stands on it's own: perform the same
> > apply/revert check as what would happen in the fixup steps to fail
> > faster for the user?
> 
> If we just run fix_patches() at the beginning then can we just get rid
> of validate_patches() altogether?

Or at least validate_patches() could be replaced with
check_unsupported_patches(), as the apply/revert test wouldn't be needed
since the actual apply/revert would happen immediately after that in
fix_patches().

-- 
Josh

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Joe Lawrence]

On 1/30/26 6:02 PM, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 02:59:53PM -0800, Josh Poimboeuf wrote:
>> On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote:
>>> On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
>>>> Hm, isn't the whole point of --recount that it ignores the line numbers?
>>>> Or does it just ignore the numbers after the commas (the counts)?
>>>>
>>>
>>> I don't know exactly.  As I continue digging into the test that sent me
>>> down this path, I just found that `git apply --recount` doesn't like
>>> some output generated by `combinediff -q --combine` even with NO line
>>> drift... then if I manually added in corresponding diff command lines
>>> (to make it look more like a .patch file generated by `diff -Nu`), ie:
>>>
>>>   diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c     <---
>>>   --- src.orig/fs/proc/array.c
>>>   +++ src/fs/proc/array.c
>>>
>>> Suddenly `git apply --recount` is happy with the patch.
>>>
>>> So I suspect that I started with git not liking the hunks generated by
>>> combinediff and drove it to the rebase feature, which solves a more
>>> interesting problem, but by side effect smoothed over this format
>>> issue when it recreated the patch with git.
>>>
>>> Anyway, I think this patch still stands on it's own: perform the same
>>> apply/revert check as what would happen in the fixup steps to fail
>>> faster for the user?
>>
>> If we just run fix_patches() at the beginning then can we just get rid
>> of validate_patches() altogether?
> 
> Or at least validate_patches() could be replaced with
> check_unsupported_patches(), as the apply/revert test wouldn't be needed
> since the actual apply/revert would happen immediately after that in
> fix_patches().
> 

Currently fix_patches runs in short-circuit step (2) after building the
original kernel.  But what if the user runs:

 $ klp-build -T 0001.patch
 $ klp-build -S 2 0002.patch

If we move fix_patches() to step (1) to fail fast and eliminate a
redundant apply/revert, aren't we then going to miss it if the user
jumps to step (2)?

Is there a way to check without actually doing it if we're going to
build the original kernel first?

And while we're here, doesn't this mean that we're currently not running
validate_patches() when skipping to step (2)?

-- 
Joe

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Song Liu]

On Tue, Feb 3, 2026 at 8:45 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
[...]
> > Or at least validate_patches() could be replaced with
> > check_unsupported_patches(), as the apply/revert test wouldn't be needed
> > since the actual apply/revert would happen immediately after that in
> > fix_patches().
> >
>
> Currently fix_patches runs in short-circuit step (2) after building the
> original kernel.  But what if the user runs:
>
>  $ klp-build -T 0001.patch
>  $ klp-build -S 2 0002.patch

On one hand, I think this is a user mistake that we need the users
to avoid by themselves. If the user do

   $ klp-build -T 0001.patch
   $ klp-build -S 3 0002.patch

Even when 0001.patch and 0002.patch are totally valid, the end
result will be very confusing (it is the result of 0001.patch, not 0002).

> If we move fix_patches() to step (1) to fail fast and eliminate a
> redundant apply/revert, aren't we then going to miss it if the user
> jumps to step (2)?
>
> Is there a way to check without actually doing it if we're going to
> build the original kernel first?
>
> And while we're here, doesn't this mean that we're currently not running
> validate_patches() when skipping to step (2)?

On the other hand, I guess we can always run fix_patches. If any
-S is given, we compare the fixed new patches against fixed saved
patches. If they are not identical, we fail fast.

Thanks,
Song

Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount

[Josh Poimboeuf]

On Tue, Feb 03, 2026 at 09:53:04AM -0800, Song Liu wrote:
> On Tue, Feb 3, 2026 at 8:45 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> [...]
> > > Or at least validate_patches() could be replaced with
> > > check_unsupported_patches(), as the apply/revert test wouldn't be needed
> > > since the actual apply/revert would happen immediately after that in
> > > fix_patches().
> > >
> >
> > Currently fix_patches runs in short-circuit step (2) after building the
> > original kernel.  But what if the user runs:
> >
> >  $ klp-build -T 0001.patch
> >  $ klp-build -S 2 0002.patch
> 
> On one hand, I think this is a user mistake that we need the users
> to avoid by themselves. If the user do
> 
>    $ klp-build -T 0001.patch
>    $ klp-build -S 3 0002.patch
> 
> Even when 0001.patch and 0002.patch are totally valid, the end
> result will be very confusing (it is the result of 0001.patch, not 0002).

Right, I consider it a power tool, use at your own discretion...
starting at step 2 overwrites the previous step 2.

> > If we move fix_patches() to step (1) to fail fast and eliminate a
> > redundant apply/revert, aren't we then going to miss it if the user
> > jumps to step (2)?

fix_patches() would still *conceptually* be part of step 2.  But as an
implementation detail (so that it fail fasts with a bad patch), step 2
would be split into two phases: before step 1 and after step 1.

if (( SHORT_CIRCUIT <= 2 )); then
	# validate and fix patches
fi

if (( SHORT_CIRCUIT <= 1 )); then
	# build orig kernel
fi

if (( SHORT_CIRCUIT <= 2 )); then
	# apply patches and build patched kernel
fi

> > Is there a way to check without actually doing it if we're going to
> > build the original kernel first?
> >
> > And while we're here, doesn't this mean that we're currently not running
> > validate_patches() when skipping to step (2)?

No, it would still run for -S2, see above.

> On the other hand, I guess we can always run fix_patches. If any
> -S is given, we compare the fixed new patches against fixed saved
> patches. If they are not identical, we fail fast.

I don't think that's worth the trouble.  If you want to change the
patches, re-run step 2.  Otherwise, just skip to step 3 or 4 (where the
patch argument just gets ignored).  Again, just a power tool for those
of us who are impatient ;-)

-- 
Josh

[PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Joe Lawrence]

The klp-build script is currently very strict with input patches,
requiring them to apply cleanly via `git apply --recount`.  This
prevents the use of patches with minor contextual fuzz relative to the
target kernel sources.

Add an optional -z/--fuzz option to allow klp-build to "rebase" input
patches within its klp-tmp/ scratch space.  When enabled, the script
utilizes GNU patch's fuzzy matching to apply changes to a temporary
directory and then creates a normalized version of the patch using `git
diff --no-index`.

This rebased patch contains the exact line counts and context required
for the subsequent klp-build fixup and build steps, allowing users to
reuse a patch across similar kernel streams.

Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
---
 scripts/livepatch/klp-build | 105 +++++++++++++++++++++++++++++++++++-
 1 file changed, 103 insertions(+), 2 deletions(-)

Using the same 1-line-offset input combined.patch from the previous
patch in this set and adding --fuzz, we can successfully now build it:

  $ ./scripts/livepatch/klp-build -T --fuzz combined.patch
  Rebasing 1 patch(es)
  -> combined.patch
  patching file fs/proc/cmdline.c
  Hunk #1 succeeded at 7 (offset 1 line).
  patching file fs/proc/version.c
  patching file fs/proc/cmdline.c
  Hunk #1 succeeded at 7 (offset 1 line).
  patching file fs/proc/version.c
  Validating patch(es)
  Building original kernel
  Copying original object files
  Fixing patch(es)
  Building patched kernel
  Copying patched object files
  Diffing objects
  vmlinux.o: changed function: cmdline_proc_show
  vmlinux.o: changed function: version_proc_show
  Building patch module: livepatch-combined.ko
  SUCCESS 

diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 2313bc909f58..535ca18e32c5 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -26,6 +26,7 @@ REPLACE=1
 SHORT_CIRCUIT=0
 JOBS="$(getconf _NPROCESSORS_ONLN)"
 VERBOSE="-s"
+FUZZ_FACTOR=""
 shopt -o xtrace | grep -q 'on' && XTRACE=1
 
 # Avoid removing the previous $TMP_DIR until args have been fully processed.
@@ -49,6 +50,7 @@ KMOD_DIR="$TMP_DIR/kmod"
 STASH_DIR="$TMP_DIR/stash"
 TIMESTAMP="$TMP_DIR/timestamp"
 PATCH_TMP_DIR="$TMP_DIR/tmp"
+REBASE_DIR="$TMP_DIR/rebase"
 
 KLP_DIFF_LOG="$DIFF_DIR/diff.log"
 
@@ -131,6 +133,7 @@ Advanced Options:
 				   3|diff	Diff objects
 				   4|kmod	Build patch module
    -T, --keep-tmp		Preserve tmp dir on exit
+   -z, --fuzz[=NUM]		Rebase patches using fuzzy matching [default: 2]
 
 EOF
 }
@@ -145,8 +148,8 @@ process_args() {
 	local long
 	local args
 
-	short="hfj:o:vdS:T"
-	long="help,show-first-changed,jobs:,output:,no-replace,verbose,debug,short-circuit:,keep-tmp"
+	short="hfj:o:vdS:Tz::"
+	long="help,show-first-changed,jobs:,output:,no-replace,verbose,debug,short-circuit:,keep-tmp,fuzz::"
 
 	args=$(getopt --options "$short" --longoptions "$long" -- "$@") || {
 		echo; usage; exit
@@ -204,6 +207,14 @@ process_args() {
 				keep_tmp=1
 				shift
 				;;
+			-z | --fuzz)
+				if [[ -n "$2" ]]; then
+					FUZZ_FACTOR="$2"
+				else
+					FUZZ_FACTOR=2
+				fi
+				shift 2
+				;;
 			--)
 				shift
 				break
@@ -304,6 +315,94 @@ get_patch_files() {
 		| sort -u
 }
 
+# Rebase a patch using GNU patch with fuzz
+# Outputs path to rebased patch on success, non-zero on failure
+rebase_patch() {
+	local idx="$1"
+	local input_patch="$2"
+	local patch_name="$(basename "$input_patch" .patch)"
+	local work_dir="$REBASE_DIR/$idx-$patch_name"
+	local output_patch="$work_dir/rebased.patch"
+	local files=()
+	local file
+
+	rm -rf "$work_dir"
+	mkdir -p "$work_dir/orig" "$work_dir/patched"
+
+	get_patch_files "$input_patch" | mapfile -t files
+
+	# Copy original files (before patch)
+	for file in "${files[@]}"; do
+		[[ "$file" == "dev/null" ]] && continue
+		if [[ -f "$SRC/$file" ]]; then
+			mkdir -p "$work_dir/orig/$(dirname "$file")"
+			cp -f "$SRC/$file" "$work_dir/orig/$file"
+		fi
+	done
+
+	# Apply with fuzz
+	(
+		cd "$SRC"
+		sed -n '/^-- /q;p' "$input_patch" | \
+			patch -p1 \
+				-F"$FUZZ_FACTOR" \
+				--no-backup-if-mismatch \
+				-r /dev/null \
+				--forward >&2
+	) || return 1
+
+	# Copy patched files (after patch)
+	for file in "${files[@]}"; do
+		[[ "$file" == "dev/null" ]] && continue
+		if [[ -f "$SRC/$file" ]]; then
+			mkdir -p "$work_dir/patched/$(dirname "$file")"
+			cp -f "$SRC/$file" "$work_dir/patched/$file"
+		fi
+	done
+
+	# Revert with fuzz
+	(
+		cd "$SRC"
+		sed -n '/^-- /q;p' "$input_patch" | \
+			patch -p1 -R \
+				-F"$FUZZ_FACTOR" \
+				--no-backup-if-mismatch \
+				-r /dev/null >&2
+	) || {
+		warn "fuzzy revert failed; source tree may be corrupted"
+		return 1
+	}
+
+	# Generate clean patch from captured state
+	( cd "$work_dir" && git diff --no-index --no-prefix orig patched ) > "$output_patch" || true
+
+	echo "$output_patch"
+}
+
+# If the user specified --fuzz, iterate through PATCHES and rebase them
+# Updates PATCHES array in-place with rebased patch paths
+maybe_rebase_patches() {
+	local i
+	local idx
+	local patch
+	local rebased
+
+	[[ -z "$FUZZ_FACTOR" ]] && return 0
+
+	status "Rebasing ${#PATCHES[@]} patch(es)"
+
+	mkdir -p "$REBASE_DIR"
+
+	idx=0001
+	for i in "${!PATCHES[@]}"; do
+		patch="${PATCHES[$i]}"
+		echo "-> $(basename "$patch")"
+		rebased=$(rebase_patch "$idx" "$patch") || die "rebase failed: $patch"
+		PATCHES[i]="$rebased"
+		idx=$(printf "%04d" $(( 10#$idx + 1 )))
+	done
+}
+
 # Make sure git re-stats the changed files
 git_refresh() {
 	local patch="$1"
@@ -807,6 +906,8 @@ build_patch_module() {
 process_args "$@"
 do_init
 
+maybe_rebase_patches
+
 if (( SHORT_CIRCUIT <= 1 )); then
 	status "Validating patch(es)"
 	validate_patches
-- 
2.52.0

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Song Liu]

On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
>
> The klp-build script is currently very strict with input patches,
> requiring them to apply cleanly via `git apply --recount`.  This
> prevents the use of patches with minor contextual fuzz relative to the
> target kernel sources.
>
> Add an optional -z/--fuzz option to allow klp-build to "rebase" input
> patches within its klp-tmp/ scratch space.  When enabled, the script
> utilizes GNU patch's fuzzy matching to apply changes to a temporary
> directory and then creates a normalized version of the patch using `git
> diff --no-index`.
>
> This rebased patch contains the exact line counts and context required
> for the subsequent klp-build fixup and build steps, allowing users to
> reuse a patch across similar kernel streams.
>
> Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>

LTGM.

Acked-by: Song Liu <song@kernel.org>

With one nitpick below.
[...]
>
> +# Rebase a patch using GNU patch with fuzz
> +# Outputs path to rebased patch on success, non-zero on failure
> +rebase_patch() {
> +       local idx="$1"
> +       local input_patch="$2"
> +       local patch_name="$(basename "$input_patch" .patch)"
> +       local work_dir="$REBASE_DIR/$idx-$patch_name"
> +       local output_patch="$work_dir/rebased.patch"
> +       local files=()
> +       local file
> +
> +       rm -rf "$work_dir"
> +       mkdir -p "$work_dir/orig" "$work_dir/patched"
> +
> +       get_patch_files "$input_patch" | mapfile -t files
> +
> +       # Copy original files (before patch)
> +       for file in "${files[@]}"; do
> +               [[ "$file" == "dev/null" ]] && continue
> +               if [[ -f "$SRC/$file" ]]; then
> +                       mkdir -p "$work_dir/orig/$(dirname "$file")"
> +                       cp -f "$SRC/$file" "$work_dir/orig/$file"
> +               fi
> +       done
> +
> +       # Apply with fuzz
> +       (
> +               cd "$SRC"
> +               sed -n '/^-- /q;p' "$input_patch" | \
> +                       patch -p1 \

I think we should add -s here, and.

> +                               -F"$FUZZ_FACTOR" \
> +                               --no-backup-if-mismatch \
> +                               -r /dev/null \
> +                               --forward >&2
> +       ) || return 1
> +
> +       # Copy patched files (after patch)
> +       for file in "${files[@]}"; do
> +               [[ "$file" == "dev/null" ]] && continue
> +               if [[ -f "$SRC/$file" ]]; then
> +                       mkdir -p "$work_dir/patched/$(dirname "$file")"
> +                       cp -f "$SRC/$file" "$work_dir/patched/$file"
> +               fi
> +       done
> +
> +       # Revert with fuzz
> +       (
> +               cd "$SRC"
> +               sed -n '/^-- /q;p' "$input_patch" | \
> +                       patch -p1 -R \

.. here, so that we can avoid a bunch of "patching file" messages.

> +                               -F"$FUZZ_FACTOR" \
> +                               --no-backup-if-mismatch \
> +                               -r /dev/null >&2
> +       ) || {
> +               warn "fuzzy revert failed; source tree may be corrupted"
> +               return 1
> +       }

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Song Liu]

On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
[...]
> @@ -807,6 +906,8 @@ build_patch_module() {
>  process_args "$@"
>  do_init
>
> +maybe_rebase_patches
> +
>  if (( SHORT_CIRCUIT <= 1 )); then

I think we should call maybe_rebase_patches within this
if condition.

Thanks,
Song

>         status "Validating patch(es)"
>         validate_patches

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Joe Lawrence]

On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> [...]
> > @@ -807,6 +906,8 @@ build_patch_module() {
> >  process_args "$@"
> >  do_init
> >
> > +maybe_rebase_patches
> > +
> >  if (( SHORT_CIRCUIT <= 1 )); then
> 
> I think we should call maybe_rebase_patches within this
> if condition.
> 

Hi Song,

Ah yeah I stumbled on this, probably overthinking it:

  - we want to validate rebased patches (when requested)
  - validate_patches() isn't really required for step 1 (building the
    original kernel) but ...
  - it's nice to check the patches before going off and building a full
    kernel
  - the patches are needed in step 2 (building the patched kernel) but ...
  - patch validation occurs in step 1

so given the way the short circuiting works, I didn't see a good way to
fold it in there.  The user might want to jump right to building the
patched kernel with patch rebasing.  Maybe that's not valid thinking if
the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
jumping to step 2 will just use the patches in the scratch dir and not
command line?).  It's Friday, maybe I'm missing something obvious? :)

--
Joe

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Song Liu]

On Fri, Jan 30, 2026 at 12:14 PM Joe Lawrence <joe.lawrence@redhat.com> wrote:
>
> On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> > On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > [...]
> > > @@ -807,6 +906,8 @@ build_patch_module() {
> > >  process_args "$@"
> > >  do_init
> > >
> > > +maybe_rebase_patches
> > > +
> > >  if (( SHORT_CIRCUIT <= 1 )); then
> >
> > I think we should call maybe_rebase_patches within this
> > if condition.
> >
>
> Hi Song,
>
> Ah yeah I stumbled on this, probably overthinking it:
>
>   - we want to validate rebased patches (when requested)
>   - validate_patches() isn't really required for step 1 (building the
>     original kernel) but ...
>   - it's nice to check the patches before going off and building a full
>     kernel
>   - the patches are needed in step 2 (building the patched kernel) but ...
>   - patch validation occurs in step 1

Hmm.. I see your point now.

> so given the way the short circuiting works, I didn't see a good way to
> fold it in there.  The user might want to jump right to building the
> patched kernel with patch rebasing.  Maybe that's not valid thinking if
> the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
> jumping to step 2 will just use the patches in the scratch dir and not
> command line?).  It's Friday, maybe I'm missing something obvious? :)

Maybe we should add another SHORT_CIRCUIT level for the validate
and rebase step? It could be step 0, or we can shift all existing steps.

Thanks,
Song

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 12:46:19PM -0800, Song Liu wrote:
> On Fri, Jan 30, 2026 at 12:14 PM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> >
> > On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> > > On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > > [...]
> > > > @@ -807,6 +906,8 @@ build_patch_module() {
> > > >  process_args "$@"
> > > >  do_init
> > > >
> > > > +maybe_rebase_patches
> > > > +
> > > >  if (( SHORT_CIRCUIT <= 1 )); then
> > >
> > > I think we should call maybe_rebase_patches within this
> > > if condition.
> > >
> >
> > Hi Song,
> >
> > Ah yeah I stumbled on this, probably overthinking it:
> >
> >   - we want to validate rebased patches (when requested)
> >   - validate_patches() isn't really required for step 1 (building the
> >     original kernel) but ...
> >   - it's nice to check the patches before going off and building a full
> >     kernel
> >   - the patches are needed in step 2 (building the patched kernel) but ...
> >   - patch validation occurs in step 1
> 
> Hmm.. I see your point now.
> 
> > so given the way the short circuiting works, I didn't see a good way to
> > fold it in there.  The user might want to jump right to building the
> > patched kernel with patch rebasing.  Maybe that's not valid thinking if
> > the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
> > jumping to step 2 will just use the patches in the scratch dir and not
> > command line?).  It's Friday, maybe I'm missing something obvious? :)
> 
> Maybe we should add another SHORT_CIRCUIT level for the validate
> and rebase step? It could be step 0, or we can shift all existing steps.

I don't see how that solves the problem?  For --short-circuit=1 and
--short-circuit=2 we still want to validate and rebase the patches
because they are used in step 2.  But as Joe mentioned, that can be done
before step 1 to catch any patch errors quickly.

Something like this?

if (( SHORT_CIRCUIT <= 2 )); then
	status "Validating patch(es)"
	validate_patches
	fix_patches	# including fixing fuzz???
fi

if (( SHORT_CIRCUIT <= 1 )); then
	status "Building original kernel"
	clean_kernel
	build_kernel "Original"
	status "Copying original object files"
	copy_orig_objects
fi

if (( SHORT_CIRCUIT <= 2 )); then
	status "Building patched kernel"
	apply_patches
	build_kernel "Patched"
	...
fi



-- 
Josh

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Song Liu]

On Fri, Jan 30, 2026 at 2:54 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Fri, Jan 30, 2026 at 12:46:19PM -0800, Song Liu wrote:
> > On Fri, Jan 30, 2026 at 12:14 PM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > >
> > > On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> > > > On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > > > [...]
> > > > > @@ -807,6 +906,8 @@ build_patch_module() {
> > > > >  process_args "$@"
> > > > >  do_init
> > > > >
> > > > > +maybe_rebase_patches
> > > > > +
> > > > >  if (( SHORT_CIRCUIT <= 1 )); then
> > > >
> > > > I think we should call maybe_rebase_patches within this
> > > > if condition.
> > > >
> > >
> > > Hi Song,
> > >
> > > Ah yeah I stumbled on this, probably overthinking it:
> > >
> > >   - we want to validate rebased patches (when requested)
> > >   - validate_patches() isn't really required for step 1 (building the
> > >     original kernel) but ...
> > >   - it's nice to check the patches before going off and building a full
> > >     kernel
> > >   - the patches are needed in step 2 (building the patched kernel) but ...
> > >   - patch validation occurs in step 1
> >
> > Hmm.. I see your point now.
> >
> > > so given the way the short circuiting works, I didn't see a good way to
> > > fold it in there.  The user might want to jump right to building the
> > > patched kernel with patch rebasing.  Maybe that's not valid thinking if
> > > the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
> > > jumping to step 2 will just use the patches in the scratch dir and not
> > > command line?).  It's Friday, maybe I'm missing something obvious? :)
> >
> > Maybe we should add another SHORT_CIRCUIT level for the validate
> > and rebase step? It could be step 0, or we can shift all existing steps.
>
> I don't see how that solves the problem?  For --short-circuit=1 and
> --short-circuit=2 we still want to validate and rebase the patches
> because they are used in step 2.  But as Joe mentioned, that can be done
> before step 1 to catch any patch errors quickly.
>
> Something like this?
>
> if (( SHORT_CIRCUIT <= 2 )); then
>         status "Validating patch(es)"
>         validate_patches
>         fix_patches     # including fixing fuzz???
> fi

I was thinking to change the above as
   if (( SHORT_CIRCUIT <= 0 ))

Then we can save the fixed version of all the patches.

But I think "SHORT_CIRCUIT <= 2" is cleaner, so this version is better.

Thanks,
Song

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 03:20:22PM -0800, Song Liu wrote:
> On Fri, Jan 30, 2026 at 2:54 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > Something like this?
> >
> > if (( SHORT_CIRCUIT <= 2 )); then
> >         status "Validating patch(es)"
> >         validate_patches
> >         fix_patches     # including fixing fuzz???
> > fi
> 
> I was thinking to change the above as
>    if (( SHORT_CIRCUIT <= 0 ))
> 
> Then we can save the fixed version of all the patches.
> 
> But I think "SHORT_CIRCUIT <= 2" is cleaner, so this version is better.

Right.  Just to clarify, the point of doing --short-circuit=2 (from my
experience) is you want to use a new .patch file which is different from
the one used by the previous klp-build incantation, but you don't want
to wait for the original build again.  Putting that behind
"SHORT_CIRCUIT <= 0" would prevent the use of the new .patch file.

-- 
Josh

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 12:59:49PM -0500, Joe Lawrence wrote:
> @@ -131,6 +133,7 @@ Advanced Options:
>  				   3|diff	Diff objects
>  				   4|kmod	Build patch module
>     -T, --keep-tmp		Preserve tmp dir on exit
> +   -z, --fuzz[=NUM]		Rebase patches using fuzzy matching [default: 2]

Ideally I think klp-build should accept a patch level fuzz of 2 by
default.  If we just made that the default then maybe we don't need this
option?

-- 
Josh

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Joe Lawrence]

On Fri, Jan 30, 2026 at 12:09:35PM -0800, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 12:59:49PM -0500, Joe Lawrence wrote:
> > @@ -131,6 +133,7 @@ Advanced Options:
> >  				   3|diff	Diff objects
> >  				   4|kmod	Build patch module
> >     -T, --keep-tmp		Preserve tmp dir on exit
> > +   -z, --fuzz[=NUM]		Rebase patches using fuzzy matching [default: 2]
> 
> Ideally I think klp-build should accept a patch level fuzz of 2 by
> default.  If we just made that the default then maybe we don't need this
> option?
> 

Do you mean to drop the optional level value, or to just perform level-2
fuzz rebasing as a matter of course (so no -z option altogether)?

--
Joe

Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 03:41:31PM -0500, Joe Lawrence wrote:
> On Fri, Jan 30, 2026 at 12:09:35PM -0800, Josh Poimboeuf wrote:
> > On Fri, Jan 30, 2026 at 12:59:49PM -0500, Joe Lawrence wrote:
> > > @@ -131,6 +133,7 @@ Advanced Options:
> > >  				   3|diff	Diff objects
> > >  				   4|kmod	Build patch module
> > >     -T, --keep-tmp		Preserve tmp dir on exit
> > > +   -z, --fuzz[=NUM]		Rebase patches using fuzzy matching [default: 2]
> > 
> > Ideally I think klp-build should accept a patch level fuzz of 2 by
> > default.  If we just made that the default then maybe we don't need this
> > option?
> > 
> 
> Do you mean to drop the optional level value, or to just perform level-2
> fuzz rebasing as a matter of course (so no -z option altogether)?

Sorry, I was a bit confused by the previous patch.  I was thinking "git
apply" already has a default fuzz level of 2, and that --recount made it
stricter somehow.  But now I see that the "git apply" default is *no*
fuzz, as opposed to GNU patch which defaults to fuzz 2.

For kpatch-build we used GNU patch, should we just change klp-build to
use that as well?  It worked well for 10+ years and the defaults were
fine.  We could maybe use patchutils to fix up the line numbers/counts.

Then we presumably wouldn't need the --fuzz option as there would be
sane defaults already.  I think some fuzz is acceptable, especially
since patch shows a warning message when it happens.

-- 
Josh

[PATCH 5/5] objtool/klp: provide friendlier error messages

[Joe Lawrence]

Provide a little bit more context behind some of the klp-build failure
modes clarify which of the user-provided patches is unsupported,
doesn't apply, and which kernel build failed.

Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
---
 scripts/livepatch/klp-build | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 535ca18e32c5..64a18c2ae1ba 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -429,7 +429,7 @@ check_unsupported_patches() {
 		for file in "${files[@]}"; do
 			case "$file" in
 				lib/*|*.S)
-					die "unsupported patch to $file"
+					die "$patch unsupported patch to $file"
 					;;
 			esac
 		done
@@ -449,7 +449,7 @@ apply_patch() {
 		# The sed strips the version signature from 'git format-patch',
 		# otherwise 'git apply --recount' warns.
 		sed -n '/^-- /q;p' "$patch" |
-			git apply "${extra_args[@]}"
+			git apply "${extra_args[@]}" || die "$patch doesn't apply (retry with --fuzz?)"
 	)
 
 	APPLIED_PATCHES+=("$patch")
@@ -601,6 +601,7 @@ clean_kernel() {
 }
 
 build_kernel() {
+	local build="$1"
 	local log="$TMP_DIR/build.log"
 	local objtool_args=()
 	local cmd=()
@@ -638,7 +639,7 @@ build_kernel() {
 		"${cmd[@]}"							\
 			1> >(tee -a "$log")					\
 			2> >(tee -a "$log" | grep0 -v "modpost.*undefined!" >&2)
-	)
+	) || die "$build kernel build failed"
 }
 
 find_objects() {
@@ -913,7 +914,7 @@ if (( SHORT_CIRCUIT <= 1 )); then
 	validate_patches
 	status "Building original kernel"
 	clean_kernel
-	build_kernel
+	build_kernel "Original"
 	status "Copying original object files"
 	copy_orig_objects
 fi
@@ -923,7 +924,7 @@ if (( SHORT_CIRCUIT <= 2 )); then
 	fix_patches
 	apply_patches
 	status "Building patched kernel"
-	build_kernel
+	build_kernel "Patched"
 	revert_patches
 	status "Copying patched object files"
 	copy_patched_objects
-- 
2.52.0

Re: [PATCH 5/5] objtool/klp: provide friendlier error messages

[Josh Poimboeuf]

On Fri, Jan 30, 2026 at 12:59:50PM -0500, Joe Lawrence wrote:
> @@ -913,7 +914,7 @@ if (( SHORT_CIRCUIT <= 1 )); then
>  	validate_patches
>  	status "Building original kernel"
>  	clean_kernel
> -	build_kernel
> +	build_kernel "Original"
>  	status "Copying original object files"
>  	copy_orig_objects
>  fi
> @@ -923,7 +924,7 @@ if (( SHORT_CIRCUIT <= 2 )); then
>  	fix_patches
>  	apply_patches
>  	status "Building patched kernel"
> -	build_kernel
> +	build_kernel "Patched"

nit: these should be lowercase for consistency with other error
messages:

  error: klp-build: original kernel build failed

-- 
Josh

Re: [PATCH 0/5] objtool/klp-build: small fixups and enhancements

[Song Liu]

On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
>
> Hi Josh,
>
> While porting over some internal tests to use klp-build, I tripped over
> a few small usability bugs and nits.  These are aren't show-stoppers,
> but a few were pretty esoteric to debug and might lead some users down
> similar rabbit holes.
>
> Look for per-patch failure messages and reproducers in the individual
> patch diffstat areas.  LMK if any of those details should make it into
> the commit messages as I assumed they were only interesting for
> reviewing context.

The commit messages look good to me. We can add some of those
extra contexts in selftests.

For the set
Acked-by: Song Liu <song@kernel.org>