[Bug]: Timestamp of patched files wrong if multiple patches touch the same file

[matthijskooijman]

What happened?

I added some userpatches to debug an issue, and somehow one particular source file was not recompiled and was stuck at a previous version of my patch.

Debugging the build framework showed that:

• The patch I was working on was applied, which updated the timestamp of the source file to the mtime of the patch, as expected.
• Then another patch (that I added earlier and was finished, but happened to sort after the other patch)was applied, which updated the timestamp of the source file back to an older timestamp.

Effectively this means that when I modify the first patch, the source file contents change, but the timestamp stays the same, so the kernel Makefile does not recompile it.

To fix this, I guess the patching code should keep a dict of files patched and timestamps to apply at the end, so it can take the newest timestamp of all patches modifying a file? Alternatively, it could read the timestamp before applying the patch, and only update the file if the patch timestamp is newer than the original file timestamp.

I was running this on v25.11.1 (since that was running on my test board). Haven't retested this on main, but given patching_utils.py has not been modified since 2024, I'm confident the issue still exists on main.

How to reproduce?

• Add two patches to userpatches (or probably also patch) that touch the same file
• Compile (I used ./compile.sh BOARD=rockpi-s BRANCH=current DEBUG=yes kernel)
• Modify the first patch.
• Compile again.
• See that the file is not recompiled.

Here's a snippet of my log output (with some added ls -l calls and log lines to show what happens exactly).

[[ First patch ]]
   -> 039/193: debug(:1) (+25/-31)[5M] {gpio-rockchip.c, gpiolib.c, rk3308.dtsi, gpiolib-of.c, core.c}
   Patch ->debug(:1) (+25/-31)[5M] {gpio-rockchip.c, gpiolib.c, rk3308.dtsi, gpiolib-of.c, core.c}<- needs rebase: offset/fuzz used during apply.
   Patch /armbian/userpatches/kernel/archive/rockchip64-6.12/debug.patch is newer than root Makefile, using patch date
   -rw-rw-r-- 1 root root 20609 Dec  5 10:02 /armbian/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/drivers/gpio/gpio-rockchip.c
   touching /armbian/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/drivers/gpio/gpio-rockchip.c / 1764928816.3029776
   -rw-rw-r-- 1 root root 20609 Dec  5 10:00 /armbian/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/drivers/gpio/gpio-rockchip.c

[[ Second patch ]]
   -> 042/193: fix-gpio-config(:1) (+1/-1)[1M] {gpio-rockchip.c}
   Patch /armbian/userpatches/kernel/archive/rockchip64-6.12/fix-gpio-config.patch is newer than root Makefile, using patch date
   -rw-rw-r-- 1 root root 20643 Dec  5 10:02 /armbian/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/drivers/gpio/gpio-rockchip.c
   touching /armbian/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/drivers/gpio/gpio-rockchip.c / 1764856353.3521569
   -rw-rw-r-- 1 root root 20643 Dec  4 13:52 /armbian/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/drivers/gpio/gpio-rockchip.c

Branch

other (only relevant in corner cases)

On which host OS are you running the build script and observing this problem?

Other

Are you building on Windows WSL2?

• Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Jira ticket: AR-2792

[rpardini]

Indeed. Multiple patches patching the same file will get the timestamp of the "later patch" - if you're modifying the first patch then sadness.

Keeping a running dict/state keyed by patched-file with the timestamp, and only ever bumping it, could fix this.

[matthijskooijman]

I actually thought about this a bit more and think there might be more fragility to this: If I run a compile and then add a patch with an older timestamp, the file will also be patched but not recompiled. I guess this could happen by adding a userpatch from somewhere, or if you switch to a different armbian-build branch or commit (unless there is specific code to handle that, but I'm not sure how that could work without doing a full kernel recompile - maybe it does that).

In essence, the root issue is that a makefile only supports checking file timestamps instead of file contents and assumes that file changes and timestamps updates always happen together (which is not the case in the armbian build where files are cleaned and repatched and might end up with the same content as before and should then not be recompiled...)

Still, fixing this particular variant of this issue is probably going to prevent surprise by people such as me trying to debug a patch issue :-)

[matthijskooijman]

And just got bitten by another variant of this issue: If you remove a patch from userpatches, the timestamps of the files are also not updated in a way that causes the (no longer) modified files to be recompiled.