Tags give the ability to mark specific points in history as being important
-
-
-
-
-
4.9.337-17
939a58db · · -
4.9.337-38
939a58db · · -
x86-urgent-2024-09-01
a547a588 · ·A set of X86 fixes: - x2apic_disable() clears x2apic_state and x2apic_mode unconditionally, even when the state is X2APIC_ON_LOCKED, which prevents the kernel to disable it thereby creating inconsistent state. Reorder the logic so it actually works correctly - The XSTATE logic for handling LBR is incorrect as it assumes that XSAVES supports LBR when the CPU supports LBR. In fact both conditions need to be true. Otherwise the enablement of LBR in the IA32_XSS MSR fails and subsequently the machine crashes on the next XRSTORS operation because IA32_XSS is not initialized. Cache the XSTATE support bit during init and make the related functions use this cached information and the LBR CPU feature bit to cure this. - Cure a long standing bug in KASLR KASLR uses the full address space between PAGE_OFFSET and vaddr_end to randomize the starting points of the direct map, vmalloc and vmemmap regions. It thereby limits the size of the direct map by using the installed memory size plus an extra configurable margin for hot-plug memory. This limitation is done to gain more randomization space because otherwise only the holes between the direct map, vmalloc, vmemmap and vaddr_end would be usable for randomizing. The limited direct map size is not exposed to the rest of the kernel, so the memory hot-plug and resource management related code paths still operate under the assumption that the available address space can be determined with MAX_PHYSMEM_BITS. request_free_mem_region() allocates from (1 << MAX_PHYSMEM_BITS) - 1 downwards. That means the first allocation happens past the end of the direct map and if unlucky this address is in the vmalloc space, which causes high_memory to become greater than VMALLOC_START and consequently causes iounmap() to fail for valid ioremap addresses. Cure this by exposing the end of the direct map via PHYSMEM_END and use that for the memory hot-plug and resource management related places instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END maps to a variable which is initialized by the KASLR initialization and otherwise it is based on MAX_PHYSMEM_BITS as before. - Prevent a data leak in mmio_read(). The TDVMCALL exposes the value of an initialized variabled on the stack to the VMM. The variable is only required as output value, so it does not have to exposed to the VMM in the first place. - Prevent an array overrun in the resource control code on systems with Sub-NUMA Clustering enabled because the code failed to adjust the index by the number of SNC nodes per L3 cache. -
perf-urgent-2024-09-01
25dfc9e3 · ·A single fix for x86 performance monitoring: Haswell PMUs suffer from several errata and require to limit the minimal period for counter events, otherwise they suffer from endless loops in the PMU interrupt.
-
-
asahi-6.10.7-2
32be8bcc · ·Tagging asahi-6.10.7-2 - rebase onto v6.10.7 - smc-hwmon fan control (guarded by module param) - dcp edid support (guarded by module param) - apple PMU branch (miss) counters (expected to change) - block pre M1 platforms in cpuidle driver - dropped wifi, bindgen and drm kconfig patches
-
asahi-6.10.7-1
ec32aab3 · ·Tagging asahi-6.10.7-1 - rebase onto v6.10.7 - smc-hwmon fan control (guarded by module param) - dcp edid support (guarded by module param) - apple PMU branch (miss) counters (expected to change) - block pre M1 platforms in cpuidle driver - dropped wifi, bindgen and drm kconfig patches
-
-
-
-
x86-urgent-2024-08-25
ea72ce5d · ·A set of X86 fixes: - x2apic_disable() clears x2apic_state and x2apic_mode unconditionally, even when the state is X2APIC_ON_LOCKED, which prevents the kernel to disable it thereby creating inconsistent state. Reorder the logic so it actually works correctly - The XSTATE logic for handling LBR is incorrect as it assumes that XSAVES supports LBR when the CPU supports LBR. In fact both conditions need to be true. Otherwise the enablement of LBR in the IA32_XSS MSR fails and subsequently the machine crashes on the next XRSTORS operation because IA32_XSS is not initialized. Cache the XSTATE support bit during init and make the related functions use this cached information and the LBR CPU feature bit to cure this. - Cure a long standing bug in KASLR KASLR uses the full address space between PAGE_OFFSET and vaddr_end to randomize the starting points of the direct map, vmalloc and vmemmap regions. It thereby limits the size of the direct map by using the installed memory size plus an extra configurable margin for hot-plug memory. This limitation is done to gain more randomization space because otherwise only the holes between the direct map, vmalloc, vmemmap and vaddr_end would be usable for randomizing. The limited direct map size is not exposed to the rest of the kernel, so the memory hot-plug and resource management related code paths still operate under the assumption that the available address space can be determined with MAX_PHYSMEM_BITS. request_free_mem_region() allocates from (1 << MAX_PHYSMEM_BITS) - 1 downwards. That means the first allocation happens past the end of the direct map and if unlucky this address is in the vmalloc space, which causes high_memory to become greater than VMALLOC_START and consequently causes iounmap() to fail for valid ioremap addresses. Cure this by exposing the end of the direct map via PHYSMEM_END and use that for the memory hot-plug and resource management related places instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END maps to a variable which is initialized by the KASLR initialization and otherwise it is based on MAX_PHYSMEM_BITS as before. -
locking-urgent-2024-08-25
d33d2603 · ·A single fix for rt_mutex: The deadlock detection code drops into an infinite scheduling loop while still holding rt_mutex::wait_lock, which rightfully triggers a 'scheduling in atomic' warning. Unlock it before that.
-
irq-urgent-2024-08-25
880799fc · ·A set of fixes for interrupt chip drivers: - Unbreak the PLIC driver for Allwinner D1 systems The recent conversion of the PLIC driver to a platform driver broke Allwinnder D1 systems due to the deferred probing of platform drivers. Due to that the only timer available on D1 systems cannot get an interrupt, which causes the system to hang at boot. Other RISCV platforms are not affected because they provide the architected SBI timer which uses the built in core interrupt controller. Cure this by probing PLIC early on D1 systems - Cure a regression in ARM/GIC-V3 on 32-bit ARM systems caused by the recent addition of a initialization function, which accesses system registers before they are enabled. On 64-bit ARM they are enabled prior to that by sheer luck. Ensure they are enabled. - Cure a use before check problem in the MSI library. The existing NULL pointer check is too late. - Cure a lock order inversion in the ARM/GIC-V4 driver - Fix a IS_ERR() vs. NULL pointer check issue in the RISCV APLIC driver - Plug a reference count leak in the ARM/GIC-V2 driver -
-
-