Tags give the ability to mark specific points in history as being important
-
acpi-5.6-rc1-2
d8639f0d · ·More ACPI updates for 5.6-rc1 Fix up MAINTAINERS entires related to ACPI (Andy Shevchenko).
-
pm-5.6-rc1-2
82b2c6ff · ·More power manadement updates for 5.6-rc1 Prevent cpufreq from creating excessively large stack frames and fix the handling of devices deleted during system-wide resume in the PM core (Rafael Wysocki), revert a problematic commit affecting the cpupower utility and correct its man page (Thomas Renninger, Brahadambal Srinivasan), and improve the intel_pstate_tracer utility (Doug Smythies).
-
x86-pti-2020-01-28
a84de2fa · ·The performance deterioration departement provides a few non-scary fixes and improvements: - Update the cached HLE state when the TSX state is changed via the new control register. This ensures feature bit consistency. - Exclude the new Zhaoxin CPUs from Spectre V2 and SWAPGS vulnerabilities.
-
smp-core-2020-01-28
cb923159 · ·A small set of SMP core code changes: - Rework the smp function call core code to avoid the allocation of an additional cpumask. - Remove the not longer required GFP argument from on_each_cpu_cond() and on_each_cpu_cond_mask() and fixup the callers.
-
irq-core-2020-01-28
43ee7448 · ·The interrupt departement provides: - A mechanism to shield isolated tasks from managed interrupts: The affinity of managed interrupts is completely controlled by the kernel and user space has no influence on them. The reason is that the automatically assigned affinity correlates to the multi-queue CPU handling of block devices. If the generated affinity mask spaws both housekeeping and isolated CPUs the interrupt could be routed to an isolated CPU which would then be disturbed by I/O submitted by a housekeeping CPU. The new mechamism ensures that as long as one housekeeping CPU is online in the assigned affinity mask the interrupt is routed to a housekeeping CPU. If there is no online housekeeping CPU in the affinity mask, then the interrupt is routed to an isolated CPU to keep the device queue intact, but unless the isolated CPU submits I/O by itself these interrupts are not raised. - A small addon to the device tree irqdomain core code to avoid duplication in irq chip drivers - Conversion of the SiFive PLIC to hierarchical domains - The usual pile of new irq chip drivers: SiFive GPIO, Aspeed SCI, NXP INTMUX, Meson A1 GPIO - The first cut of support for the new ARM GICv4.1 - The usual pile of fixes and improvements in core and driver code
-
core-debugobjects-2020-01-28
35fd7a63 · ·A single commit for debug objects which fixes a pile of potential data races detected by KCSAN.
-
core-core-2020-01-28
11e31f60 · ·A set of watchdog/softlockup related improvements: - Enforce that the watchdog timestamp is always valid on boot. The original implementation caused a watchdog disabled gap of one second in the boot process due to truncation of the underlying sched clock. The sched clock is divided by 1e9 to convert nanoseconds to seconds. So for the first second of the boot process the result is 0 which is at the same time the indicator to disable the watchdog. The trivial fix is to change the disabled indicator to ULONG_MAX. - Two cleanup patches removing unused and redundant code which got forgotten to be cleaned up in previous changes.
-
timers-core-2020-01-27
fd928f3e · ·The timekeeping and timers departement provides: - Time namespace support: If a container migrates from one host to another then it expects that clocks based on MONOTONIC and BOOTTIME are not subject to disruption. Due to different boot time and non-suspended runtime these clocks can differ significantly on two hosts, in the worst case time goes backwards which is a violation of the POSIX requirements. The time namespace addresses this problem. It allows to set offsets for clock MONOTONIC and BOOTTIME once after creation and before tasks are associated with the namespace. These offsets are taken into account by timers and timekeeping including the VDSO. Offsets for wall clock based clocks (REALTIME/TAI) are not provided by this mechanism. While in theory possible, the overhead and code complexity would be immense and not justified by the esoteric potential use cases which were discussed at Plumbers '18. The overhead for tasks in the root namespace (host time offsets = 0) is in the noise and great effort was made to ensure that especially in the VDSO. If time namespace is disabled in the kernel configuration the code is compiled out. Kudos to Andrei Vagin and Dmitry Sofanov who implemented this feature and kept on for more than a year addressing review comments, finding better solutions. A pleasant experience. - Overhaul of the alarmtimer device dependency handling to ensure that the init/suspend/resume ordering is correct. - A new clocksource/event driver for Microchip PIT64 - Suspend/resume support for the Hyper-V clocksource - The usual pile of fixes, updates and improvements mostly in the driver code. -
timers-urgent-2020-01-27
9f24c540 · ·Two fixes for the generic VDSO code which missed 5.5: - Make the update to the coarse timekeeper unconditional. This is required because the coarse timekeeper interfaces in the VDSO do not depend on a VDSO capable clocksource. If the system does not have a VDSO capable clocksource and the update is depending on the VDSO capable clocksource, the coarse VDSO interfaces would operate on stale data forever. - Invert the logic of __arch_update_vdso_data() to avoid further head scratching. Tripped over this several times while analyzing the update problem above.