mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-05-16 03:11:11 -04:00
Commitc43267e679("Merge tag 'arm64-upstream' of git://...") had a conflict in the irq entry/exit code due to commitc5538d0141("entry: Split kernel mode logic from irqentry_{enter,exit}()") having moved the core code in irqentry_enter/exit() from kernel/entry/common.c into helper inline functions in include/linux/irq-entry-common.h. On the other side of the merge, the timer-core code had introduced deferred hrtimer rearming infrastructure in commit0e98eb1481("entry: Prepare for deferred hrtimer rearming"), adding two calls to hrtimer_rearm_deferred() in irqentry_enter(). When merging the two, moving the two calls to the new location wasn't a problem, but afterwards I had made the mistake of looking what had happened in linux-next. And linux-next had a very different merge resolution in commit 04f02dc3ea74 ("Merge tag 'entry-for-arm64-26-04-08' into sched/hrtick"), which had unified the two calls into one single call-site in irqentry_exit_to_kernel_mode_preempt(). And that merge resolution looked cleverer than the straightforward one I had done, so I re-did my merge the way it had been done in linux-next. But it turns out nobody apparently tests linux-next, and the merge in linux-next was just wrong. The difference is that hrtimer_rearm_deferred() doesn't get called at all for the case when state.exit_rcu is true, and the boot will typically fail due to timers not triggering correctly. So this undoes the "clever" merge, and does the straightforward one instead. Fixes:c43267e679("Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux" Reported-and-tested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Link: https://lore.kernel.org/all/CAADnVQJ=MoiX4=guPWhL9vtnAELkpNx=GNm8RA1-aV424UFz2A@mail.gmail.com/ Link: https://lore.kernel.org/all/CAHk-=wg8+BER4VyFKG3rnPi2gXxbf-jbHS=EU+xhFqGVQfbutw@mail.gmail.com/ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>