From: Joe Lawrence <joe.lawrence@redhat.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: live-patching@vger.kernel.org, Jiri Kosina <jikos@kernel.org>,
Miroslav Benes <mbenes@suse.cz>, Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount
Date: Fri, 30 Jan 2026 15:38:40 -0500 [thread overview]
Message-ID: <aX0W0JWRkLbuQpGY@redhat.com> (raw)
In-Reply-To: <lqchka76tcwjxitn5tm42keexglnac6iveb44ppgx4c425qsfg@sbcdkfgmebqu>
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
next prev parent reply other threads:[~2026-01-30 20:38 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 17:59 [PATCH 0/5] objtool/klp-build: small fixups and enhancements Joe Lawrence
2026-01-30 17:59 ` [PATCH 1/5] objtool/klp: limit parent .git directory search Joe Lawrence
2026-01-30 17:59 ` [PATCH 2/5] objtool/klp: handle patches that add new files Joe Lawrence
2026-01-30 20:02 ` Josh Poimboeuf
2026-01-30 17:59 ` [PATCH 3/5] objtool/klp: validate patches with git apply --recount Joe Lawrence
2026-01-30 20:05 ` Josh Poimboeuf
2026-01-30 20:38 ` Joe Lawrence [this message]
2026-01-30 22:59 ` Josh Poimboeuf
2026-01-30 23:02 ` Josh Poimboeuf
2026-02-03 16:45 ` Joe Lawrence
2026-02-03 17:53 ` Song Liu
2026-02-03 19:47 ` Josh Poimboeuf
2026-01-30 17:59 ` [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option Joe Lawrence
2026-01-30 19:13 ` Song Liu
2026-01-30 19:58 ` Song Liu
2026-01-30 20:13 ` Joe Lawrence
2026-01-30 20:46 ` Song Liu
2026-01-30 22:54 ` Josh Poimboeuf
2026-01-30 23:20 ` Song Liu
2026-01-30 23:36 ` Josh Poimboeuf
2026-01-30 20:09 ` Josh Poimboeuf
2026-01-30 20:41 ` Joe Lawrence
2026-01-30 23:31 ` Josh Poimboeuf
2026-01-30 17:59 ` [PATCH 5/5] objtool/klp: provide friendlier error messages Joe Lawrence
2026-01-31 0:37 ` Josh Poimboeuf
2026-01-30 19:18 ` [PATCH 0/5] objtool/klp-build: small fixups and enhancements Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aX0W0JWRkLbuQpGY@redhat.com \
--to=joe.lawrence@redhat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.