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

[Joe Lawrence <joe.lawrence@redhat.com>]

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