# git rev-parse -q --verify dad9774deaf1cf8e8f7483310dfb2690310193d2^{commit} # git fetch -q -n -f git://fs.ozlabs.ibm.com/kernel/linus master warning: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. # git rev-parse -q --verify dad9774deaf1cf8e8f7483310dfb2690310193d2^{commit} dad9774deaf1cf8e8f7483310dfb2690310193d2 # git checkout -q -f -B kisskb dad9774deaf1cf8e8f7483310dfb2690310193d2 # git clean -qxdf # < git log -1 # commit dad9774deaf1cf8e8f7483310dfb2690310193d2 # Merge: 007034977130 13bb06f8dd42 # Author: Linus Torvalds # Date: Wed Jun 21 12:36:34 2023 -0700 # # Merge tag 'timers-urgent-2023-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip # # Pull timer fix from Thomas Gleixner: # "A single regression fix for a regression fix: # # For a long time the tick was aligned to clock MONOTONIC so that the # tick event happened at a multiple of nanoseconds per tick starting # from clock MONOTONIC = 0. # # At some point this changed as the refined jiffies clocksource which is # used during boot before the TSC or other clocksources becomes usable, # was adjusted with a boot offset, so that time 0 is closer to the point # where the kernel starts. # # This broke the assumption in the tick code that when the tick setup # happens early on ktime_get() will return a multiple of nanoseconds per # tick. As a consequence applications which aligned their periodic # execution so that it does not collide with the tick were not longer # guaranteed that the tick period starts from time 0. # # The fix for this regression was to realign the tick when it is # initially set up to a multiple of tick periods. That works as long as # the underlying tick device supports periodic mode, but breaks under # certain conditions when the tick device supports only one shot mode. # # Depending on the offset, the alignment delta to clock MONOTONIC can # get in a range where the minimal programming delta of the underlying # clock event device is larger than the calculated delta to the next # tick. This results in a boot hang as the tick code tries to play catch # up, but as the tick never fires jiffies are not advanced so it keeps # trying for ever. # # Solve this by moving the tick alignement into the NOHZ / HIGHRES # enablement code because at that point it is guaranteed that the # underlying clocksource is high resolution capable and not longer # depending on the tick. # # This is far before user space starts, so at the point where # applications try to align their timers, the old behaviour of the tick # happening at a multiple of nanoseconds per tick starting from clock # MONOTONIC = 0 is restored" # # * tag 'timers-urgent-2023-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: # tick/common: Align tick period during sched_timer setup # < /opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux-ld --version # < git log --format=%s --max-count=1 dad9774deaf1cf8e8f7483310dfb2690310193d2 # make -s -j 32 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- x86_64_defconfig # < make -s -j 32 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- help # make -s -j 32 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- olddefconfig # make -s -j 32 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.5.0-nolibc/x86_64-linux/bin/x86_64-linux- Completed OK # rm -rf /kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 # Build took: 0:02:02.223282