Find a file
Linus Torvalds dad9774dea 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.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmSTUNQTHHRnbHhAbGlu
 dXRyb25peC5kZQAKCRCmGPVMDXSYoQQjD/4+zHK7IxRK+1k1lIStxksEudVeNuqK
 7RZKNTawZFSChrxGmv5uhmqYDK9/tudnZot+uyAXI81JHnnGSXbco+VrAA2DQ2v2
 w/oxhAHIAobJWDzUuCqT2YsseDVNoTGMrTTPrL4klXqhVtShVOLTI/603+macEiw
 Olqmd7XxlyhCloNqoMIh18EwSNIs78kP3YAQHUmq3NoRkJT5c3wWKvZy38WOxSJ9
 Jjpw75tePfcwWte9fGVq+oJ8hOWkPAKN5hFL8420RrEgdIkxKlhVmuyG48ieZKH1
 LE1brB5iaU8+M91PevZMRlD7oio8u/d6xX1vT3Cqz9UBe1NLj1I0ToX6COhwSNxm
 50U0HJ5wGlpodu4IyBHXTG45UAVwpOg/EgDlFigeP3Nxl6h45ugrA010r6FqE1zV
 KltjNGsk/OD5d8ywW+yManU2mySm9znqmWN2zbjRGm138Tuz7vglcBhFB6jEJFUF
 V8vYPLwI4J2gqifx8NoFBIfLuZp/+D4LOQiJ7XRc9CVm3JLK8Xi8fxnHGTBwJHIn
 45WU4hzmY7fjR/gGhAyG7lH6tlo7VTC9/lrO+YtAy2hL2sK14+m/ZH7836I5bAhw
 EgSyVlcfR6tgO55I3JgkbNIyO5TUAZPZIAY1TlyR53xXvMkb9aZTh9UMm1xMJ3uX
 +sQaLAuDFNUQSg==
 =/uvx
 -----END PGP SIGNATURE-----

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
2023-06-21 12:36:34 -07:00
arch hyperv-fixes for 6.4-rc8 2023-06-19 17:05:43 -07:00
block blk-cgroup: Flush stats before releasing blkcg_gq 2023-06-11 19:49:29 -06:00
certs KEYS: Add missing function documentation 2023-04-24 16:15:52 +03:00
crypto KEYS: asymmetric: Copy sig and digest in public_key_verify_signature() 2023-06-02 15:36:23 +02:00
Documentation Tracing fixes for 6.4: 2023-06-20 15:01:08 -07:00
drivers virtio: bugfix 2023-06-21 11:10:40 -07:00
fs 19 hotfixes. 8 of these are cc:stable. 2023-06-20 17:20:22 -07:00
include regulator: Fix for v6.4 2023-06-21 10:29:42 -07:00
init Objtool changes for v6.4: 2023-04-28 14:02:54 -07:00
io_uring io_uring/io-wq: clear current->worker_private on exit 2023-06-14 12:54:55 -06:00
ipc Merge branch 'work.namespace' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs 2023-02-24 19:20:07 -08:00
kernel A single regression fix for a regression fix: 2023-06-21 12:36:34 -07:00
lib 19 hotfixes. 14 are cc:stable and the remainder address issues which were 2023-06-12 16:14:34 -07:00
LICENSES LICENSES: Add the copyleft-next-0.3.1 license 2022-11-08 15:44:01 +01:00
mm 19 hotfixes. 8 of these are cc:stable. 2023-06-20 17:20:22 -07:00
net dccp: Print deprecation notice. 2023-06-15 15:08:59 -07:00
rust Rust changes for v6.4 2023-04-30 11:20:22 -07:00
samples samples/bpf: Drop unnecessary fallthrough 2023-05-16 19:44:05 +02:00
scripts scripts/gdb: fix SB_* constants parsing 2023-06-19 13:19:32 -07:00
security selinux: don't use make's grouped targets feature yet 2023-06-01 13:56:13 -04:00
sound ASoC: Fixes for v6.4 2023-06-16 09:28:27 +02:00
tools 19 hotfixes. 8 of these are cc:stable. 2023-06-20 17:20:22 -07:00
usr initramfs: Check negative timestamp to prevent broken cpio archive 2023-04-16 17:37:01 +09:00
virt KVM: Fix vcpu_array[0] races 2023-05-19 13:56:26 -04:00
.clang-format cxl for v6.4 2023-04-30 11:51:51 -07:00
.cocciconfig
.get_maintainer.ignore get_maintainer: add Alan to .get_maintainer.ignore 2022-08-20 15:17:44 -07:00
.gitattributes .gitattributes: use 'dts' diff driver for *.dtso files 2023-02-26 15:28:23 +09:00
.gitignore linux-kselftest-kunit-6.4-rc1 2023-04-24 12:31:32 -07:00
.mailmap mailmap: add entries for Ben Dooks 2023-06-19 13:19:35 -07:00
.rustfmt.toml rust: add .rustfmt.toml 2022-09-28 09:02:20 +02:00
COPYING COPYING: state that all contributions really are covered by this file 2020-02-10 13:32:20 -08:00
CREDITS MAINTAINERS: sctp: move Neil to CREDITS 2023-05-12 08:51:32 +01:00
Kbuild Kbuild updates for v6.1 2022-10-10 12:00:45 -07:00
Kconfig kbuild: ensure full rebuild when the compiler is updated 2020-05-12 13:28:33 +09:00
MAINTAINERS Tracing fixes for 6.4: 2023-06-20 15:01:08 -07:00
Makefile Linux 6.4-rc7 2023-06-18 14:06:27 -07:00
README

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.