Merge ACPICA updates for 7.2-rc1 including the following changes:
- Add support for the Legacy Virtual Register (LVR) field in I2C serial
bus resource descriptors to ACPICA (Akhil R)
- Fix multiple issues related to bounds checks, input validation,
use-after-free, and integer overflow checks in the AML interpreter
in ACPICA (ikaros)
- Update the copyright year to 2026 in ACPICA files and make minor
changes related to ACPI 6.6 support (Pawel Chmielewski)
- Remove spurious precision from format used to dump parse trees in
ACPICA (David Laight)
- Add modern standby DSM GUIDs to ACPICA header files (Daniel Schaefer)
- Fix FADT 32/64X length mismatch warning in ACPICA (Abdelkader Boudih)
- Update D3hot/cold device power states definitions in ACPICA header
files (Aymeric Wibo)
- Fix NULL pointer dereference in acpi_ns_custom_package() (Weiming
Shi)
- Update ACPICA version to 20260408 (Saket Dumbre)
* acpica: (27 commits)
ACPICA: add boundary checks in two places
ACPICA: Add package limit checks in parser functions
ACPICA: Update version to 20260408
ACPICA: Update the copyright year to 2026
ACPICA: Remove spurious precision from format used to dump parse trees
ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op()
ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()
ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()
ACPICA: Add validation for node in acpi_ns_build_normalized_path()
ACPICA: validate handler object type in two places
ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()
ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)
ACPICA: Prevent adding invalid references
ACPICA: add boundary checks in acpi_ps_get_next_field()
ACPICA: validate byte_count in acpi_ps_get_next_package_length()
ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()
ACPICA: fix I2C LVR item count in the conversion table
ACPICA: Mention the LVR bits
ACPICA: Change LVR to 8 bit value
ACPICA: Fetch LVR I2C resource descriptor
...
kvm_io_bus_register_dev() and kvm_io_bus_unregister_dev() should be
called under kvm->slots_lock. The unregister calls in ipi.c, eiointc.c
and pch_pic.c were also missing this protection. Add it to match the
register side.
Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Sashiko reported that the irqchip index is not validated for LoongArch.
Add validation and reject out-of-range irqchip indexes to avoid indexing
past the routing table's chip array.
Cc: stable@vger.kernel.org
Fixes: 1928254c5c ("LoongArch: KVM: Add irqfd support")
Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/
Reported-by: Sashiko <sashiko-bot@kernel.org>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The LoongArch CSRXCHG instruction returns the full old CSR value in rd
after applying the masked update. kvm_emu_xchg_csr() currently masks
the saved value before returning it to the guest, so rd receives only
the bits selected by the write mask.
That breaks the architectural behavior and makes a zero mask return 0
instead of the previous CSR value. So, keep the masked CSR update, but
return the unmodified old CSR value.
Cc: stable@vger.kernel.org
Fixes: da50f5a693 ("LoongArch: KVM: Implement handle csr exception")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
put_user() may return -EFAULT, so, when the user space address is
invalid, the caller should return -EFAULT.
Cc: stable@vger.kernel.org
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The software timer emulation is to wake up vCPU when the vCPU executes
idle instruction and gives up host CPU, the vCPU timer tick value and
interrupt is set when vCPU is scheduled in.
It is not necessary to inject timer interrupt when SW timer is expired.
Here remove it, also use common API kvm_vcpu_wake_up() to wake up vCPU.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Interrupt delivery should be called after IN_GUEST_MODE is set. Other
threads may be posting interrupt however does not send IPI to the vCPU,
since the vCPU is not in IN_GUEST_MODE yet.
Here move function call with kvm_deliver_intr() after IN_GUEST_MODE is
set, and set mode with OUTSIDE_GUEST_MODE with atomic method.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
When set CSR.ESTAT register in function _kvm_setcsr(), valid bit check
is added here. Also interrupt CPU_AVEC is checked by msgint feature.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
With bitmask method, interrupts can be injected with batch mode rather
than one by one. Also remove unused array priority_to_irq[] here.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Interrupt AVEC is valid only if VM has msgint feature, and this feature
is checked in interrupt handling. Since interrupt handling is executing
in VM context switch, and it is hot path, here move the feature checking
in interrupt post rather than interrupt handling.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Function kvm_vcpu_ioctl_interrupt() can be called from userspace, here
add irq validility cheking in kvm_vcpu_ioctl_interrupt().
Cc: stable@vger.kernel.org
Fixes: f45ad5b8aa ("LoongArch: KVM: Implement vcpu interrupt operations")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
With interrupt post, register CSR.GINTC and CSR.ESTAT is used, and
CSR.ESTAT is used for percpu interrupt injection and CSR.GINTC is for
external hardware interrupt injection.
Here use existing macro about interrupt bit of register CSR.GINTC and
CSR.ESTAT, rather than hard coded constant value.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
At the beginning, only 64 bit FPU is supported. With FPU register get
interface, 64 bit FPU data is copied to user space, the same with FPU
register set API. However with LSX and LASX supported in later, there
should be FPU data copied with bigger width. So here fixes this issue,
copy the whole 256 bit FPU data from/to user space.
Cc: stable@vger.kernel.org
Fixes: db1ecca22e ("LoongArch: KVM: Add LSX (128bit SIMD) support")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
In kvm_lose_fpu() FPU state is save in vcpu::arch::fpu, its FPU status
comes from vcpu->arch.aux_inuse. Instead existing API vm_guest_has_xxx()
can be used also, moreover, the bits KVM_LARCH_LSX and KVM_LARCH_LASX in
arch.aux_inuse are removed. It makes the logic simpler than ever.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
With max VM supported FPU type enabled, if VM supports LASX, there is
only NONE --> LASX, no middle FPU state such as NONE --> FPU --> LASX
or NONE --> FPU --> LSX --> LASX. Here remove the middle FPU states in
function kvm_own_lsx() and kvm_own_lasx(). And it becomes simpler than
before.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
There are three FPU types FPU/LSX/LASX, which represents FPU64, FPU128
and FPU256, and now lazy FPU method is used with FPU enabling. There are
three different HW FPU exception code with different FPU type.
The exising method is to enable specified FPU type with responding FPU
exeception. Supposing application uses FPU64 and FPU256, there will be
FPU256 exception when FPU256 type is used.
Here enable FPU with the max VM supported type directly, so it can avoid
unnecessary FPU exception in future if further FPU type is used.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
There are different structures with FPU and LBT register restore, with
FPU the structure is vcpu::arch::fpu, with LBT the structure is vcpu::
arch::lbt. Moreover, FPU/LSX/LASX saving and restoring share the common
structure vcpu::arch::fpu.
New request bit KVM_REQ_LBT_LOAD is used for LBT register restore, and
rename KVM_REQ_AUX_LOAD with KVM_REQ_FPU_LOAD for FPU register restore.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The macros QUP_I3C and UFS_RESET are defined in some platforms
and yet not used. Remove these macros as they are unnecessary.
Signed-off-by: Navya Malempati <navya.malempati@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The NVIDIA Tegra264 MAIN, AON, and UPHY pin controllers are only present
on NVIDIA Tegra264 SoCs. Hence add a dependency on ARCH_TEGRA, to
prevent asking the user about this driver when configuring a kernel
without NVIDIA Tegra SoC support.
Fixes: c985062069 ("pinctrl: tegra: Add Tegra264 pinmux driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The NVIDIA Tegra238 MAIN and AON pin controllers are only present on
NVIDIA Tegra238 SoCs. Hence add a dependency on ARCH_TEGRA, to prevent
asking the user about this driver when configuring a kernel without
NVIDIA Tegra SoC support.
Fixes: 25cac7292d ("pinctrl: tegra: Add Tegra238 pinmux driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add 24 pin groups on ports EE, FF, GG and HH to the AON pin controller
group table (tegra238_aon_groups[]). Their pin arrays, drive-group
macros and pin descriptors were already defined, but the matching
PINGROUP() entries were not present, so these pins could not be muxed
or configured through the AON pin controller.
The pin arrays were not referenced, so the build emitted
-Wunused-const-variable warnings, and commit 119de2c33d ("pinctrl:
tegra238: remove unused entries") removed three of them. Restore those
arrays and add the full set of PINGROUP() entries to make the pins
usable.
Fixes: 25cac7292d ("pinctrl: tegra: Add Tegra238 pinmux driver")
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add 24 pin groups, and their matching drive groups, on ports EE, FF,
GG and HH to the Tegra238 AON pinmux binding. These groups are present
on the AON pin controller, so device trees that mux these pins through
it validate against the schema.
Fixes: 9323f8a0e1 ("dt-bindings: pinctrl: Document Tegra238 pin controllers")
Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Comments in drivers/platform/x86/dell/dell-wmi-privacy.h incorrectly
refer to CONFIG_DELL_PRIVACY instead of CONFIG_DELL_WMI_PRIVACY.
Correct them.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Link: https://patch.msgid.link/20260611001238.391045-1-enelsonmoore@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add TDP power limits and fan curve requirements for the ASUS ROG Strix
G16 G614PR laptop model.
The ASUS ROG Strix G16 G614PR requires specific AC/DC power limits
(PPT PL1/PL2/PL3, dynamic boost, and NV TGP targets) to function
correctly under various power profiles. Without these limits, the Asus
Armoury driver cannot configure the correct power envelopes or enable custom
fan curves, leading to suboptimal performance or noise management.
This patch adds the corresponding DMI board name matching entry ("G614PR")
under the power_limits table in asus-armoury.h, populating the AC and DC
limits based on the platform's hardware specification.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260610152130.25892-1-scardracs@disroot.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
pcm_spi_int, pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4 pin groups are not
defined, so pcm_spi function can't be applied to these groups.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
phy1_led1 pin function wrongly refers to gpio1 instead of gpio11.
Fix it.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
gpio22 pin group is missed, fix it.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
gpio21 pin group refers to gpio22 pin, this is wrong.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
AN7581 have 47 valid GPIOs only (gpio0-gpio46), so gpio47 is a fiction.
AN7583 have 49 valid GPIOs (gpio0-gpio48), so gpio48 is missed
To fix an issue
* create AN7583 specific pwm pin function,
* remove gpio47 from AN7581 pwm pin function.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Linus Walleij <linusw@kernel.org>
phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
Fixes: 579839c954 ("pinctrl: airoha: convert PHY LED GPIO to macro")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
a proper bit number in the configuration register.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
a proper bit number in the configuration register.
Fixes: 1c8ace2d07 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
gpio32 pin group is missed for an7583 SoC. This patch add it.
Fixes: 3ffeb17a9a ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
gpio32 pin group is missed for an7581 SoC. This patch add it.
Fixes: 1c8ace2d07 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The ASUS Keystone is a physical NFC-like dongle that slots into supported
ASUS laptops. The EC fires WMI notify code 0xB4 on insert/remove events.
Expose the current insert state via a sysfs attribute by querying WMI
device ID 0x00120091 (DSTS). This devid does not follow the standard DSTS
convention: PRESENCE_BIT (0x00010000) encodes the insert state rather than
feature presence, and STATUS_BIT is never set. Presence of a keystone slot
is detected by a successful DSTS call.
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Signed-off-by: Dariusz Figzał <dariuszfigzal@gmail.com>
Link: https://patch.msgid.link/20260610164942.74956-1-dariuszfigzal@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Use kvm_s390_mmu_cache_alloc_rmap() to allocate the rmap in
gmap_insert_rmap(), instead of a normal kzalloc_obj() with GFP_ATOMIC.
This guarantees forward progress.
Fixes: a2c17f9270 ("KVM: s390: New gmap code")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-6-imbrenda@linux.ibm.com>
Add missing radix_tree_preload() in _gaccess_shadow_fault() to
guarantee forward progress. The core of _gaccess_shadow_fault() has
been split into ___gaccess_shadow_fault() in order to simplify locking.
Fixes: e38c884df9 ("KVM: s390: Switch to new gmap")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-5-imbrenda@linux.ibm.com>
The allocation size for struct vsie_rmap in kvm_s390_mmu_cache_topup()
was wrong due to a copy-paste error.
Fix it by using the type name.
Fixes: 12f2f61a9e ("KVM: s390: KVM page table management functions: allocation")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-4-imbrenda@linux.ibm.com>
Fix an unlikely race in try_get_locked_pte(), which could have happened
if puds or pmds get unmapped between the p?dp_get() and p?d_offset()
functions.
Fixes: 89fa757931 ("KVM: s390: Avoid potentially sleeping while atomic when zapping pages")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-3-imbrenda@linux.ibm.com>
While dat_crstep_xchg_atomic() is marked as __must_check, in this
particular case the return value should be ignored.
Silence potential compiler warnings with a pointless check, and add a
comment to explain the situation.
Fixes: d1adc098ce ("KVM: s390: Fix _gmap_crstep_xchg_atomic()")
CC: stable@vger.kernel.org # 7.1
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260611104850.110313-2-imbrenda@linux.ibm.com>
The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
instance, but it skips the first bank (PortA), so their index goes from
1 to 10. The same is actually true for the IRQ banks: there are registers
for 11 banks, though the first bank is not implemented (RAZ/WI).
In contrast to previous SoCs, the count of the IRQ banks starts with this
first unimplemented bank, so we need to provide an interrupt for it.
And indeed the A523 user manual lists an interrupt number for PortA, so we
need to increase the maximum number of interrupts per pin controller to 11,
to be able to assign the correct interrupt number for each bank.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
that line is muxed for IRQ triggering (muxval 6), but only if it's
explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
behaviour, so we added a optional workaround, triggered by a quirk bit,
which triggers remuxing the pin when it's configured for IRQ, while we
need to read its value.
For some reasons this quirk flag was copied over to newer SoCs, even
though they don't show this behaviour, and the GPIO data register
reflects the true GPIO state even with a pin muxed to IRQ trigger.
Remove the unneeded quirk from the A523 family, where it's definitely
not needed (confirmed by experiments), and where it actually breaks,
because the workaround is not compatible with the newer generation
pinctrl IP used in that chip.
Together with a DT change this fixes GPIO IRQ operation on the A523
family of SoCs, as for instance used for the SD card detection.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fixes: b8a51e95b3 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Chen-Yu Tsai <wens@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add the contended_release trace event. This tracepoint fires on the
holder side when a contended lock is released, complementing the
existing contention_begin/contention_end tracepoints which fire on the
waiter side.
This enables correlating lock hold time under contention with waiter
events by lock address.
Add trace_contended_release()/trace_call__contended_release() calls to
the slowpath unlock paths of sleepable locks: mutex, rtmutex, semaphore,
rwsem, percpu-rwsem, and RT-specific rwbase locks.
Where possible, trace_contended_release() fires before the lock is
released and before the waiter is woken. For some lock types, the
tracepoint fires after the release but before the wake. Making the
placement consistent across all lock types is not worth the added
complexity.
For reader/writer locks, the tracepoint fires for every reader releasing
while a writer is waiting, not only for the last reader.
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/02f4f6c5ce6761e7f6587cf0ff2289d962ecddd4.1780506267.git.d@ilvokhin.com
Move the percpu_up_read() slowpath out of the inline function into a new
__percpu_up_read() to avoid binary size increase from adding a
tracepoint to an inlined function.
Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/3dd2a1b9ab4f469e1892766cb63f41d6b0f53d29.1780506267.git.d@ilvokhin.com
Breno reported significant c2c HITM in a futex hash heavy workload.
It turns out that the hash bucket to private hash table reverse pointer
(futex_hash_bucket::priv) was to blame. Notably when the hash buckets are
heavily contended, the: 'fph = bh->priv;' load in futex_hash() will typically
miss and consequently become quite expensive.
Since this load in particular is quite superfluous, removing it is fairly
straight forward. However, removing it does not in fact achieve anything much.
The pain moves to the next user, notably: futex_hash_put().
Therefore rework the whole private hash refcounting to avoid needing this back
pointer (and removing it). Instead of passing around 'struct futex_hash_bucket
*hb', pass around a new structure that contains it and the related 'struct
futex_private_hash *fph' pointer in tandem.
Funnily this turns out to remove more code than it adds and significantly
improves futex hash performance (as measured by 'perf bench futex hash'):
SKL dual socket 112 threads:
Baseline Patched
shared (16k) 1571857 1641435 + 4.4%
autosize (512) 646390 903371 +39.7%
-b 256 464395 587014 +26.4%
-b 512 715687 995943 +39.2%
-b 1024 995085 1396328 +40.3%
-b 2048 1293114 1668395 +29.0%
-b 4096 2124438 2240228 + 5.5%
Zen3 dual socket 256 threads:
Baseline Patched
shared (16k) 1275840 1381279 + 8.2%
autosize (512) 1252745 1482179 +18.3%
-b 256 856274 955455 +11.5%
-b 512 1267490 1544010 +21.8%
-b 1024 1424013 1625424 +14.1%
-b 2048 1505181 1669342 +10.9%
-b 4096 1465993 1688932 +15.2%
AMD EPYC 9D64 (Zen4, single socket) 176 threads:
Baseline Patched Delta
shared (16k) 1,230,599 1,368,655 +11.2%
autosize (1024) 1,285,440 1,556,946 +21.1%
-b 256 1,341,471 1,520,303 +13.3%
-b 512 1,438,330 1,599,319 +11.2%
-b 1024 1,443,772 1,622,493 +12.4%
-b 2048 1,472,108 1,643,975 +11.7%
-b 4096 1,333,098 1,570,897 +17.8%
Reported-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Breno Leitao <leitao@debian.org>
Tested-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260610135510.GB1430057@noisy.programming.kicks-ass.net
While testing Prateek's throttle series, I noticed a panic issue when
coresched is enabled and bisected to this patch.
I fed the panic log and this patch to an agent and its analysis looks
correct to me(cpu56 and cpu57 are siblings in a VM):
cpu57 (holds core-wide lock)
pick_next_task() [core scheduling]
for_each_cpu_wrap(i, smt_mask, 57):
i=57: pick_task(rq_57)
pick_task_fair(rq_57)
-> picks task A
rq_57->core_pick = task A
// task_rq(A) == rq_57
i=56: pick_task(rq_56)
pick_task_fair(rq_56)
cfs_rq->nr_queued == 0
goto idle
sched_balance_newidle(rq_56)
raw_spin_rq_unlock(rq_56)
// core-wide lock released
newidle_balance() pulls
task A: rq_57 -> rq_56
// task_rq(A) == rq_56 now
raw_spin_rq_lock(rq_56)
// core-wide lock re-acquired
return > 0
goto again
pick_task_fair(rq_56)
-> picks task A
rq_56->core_pick = task A
// first loop done
// rq_57->core_pick is still task A (set before lock release)
// but task_rq(A) == rq_56 now
next = rq_57->core_pick // = task A
put_prev_set_next_task(rq_57, prev, task A)
__set_next_task_fair(rq_57, task A)
hrtick_start_fair(rq_57, task A)
WARN_ON_ONCE(task_rq(task A) != rq_57)
// task_rq(A) == rq_56
IOW: by allowing pick_task_fair() to do newidle_balance and not returning
RETRY_TASK, it can end up selecting the same task on two CPUs. Restore the
previous state by never doing newidle when core scheduling is enabled.
Tested-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: "Aaron Lu" <ziqianlu@bytedance.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260603095108.GA1684319@bytedance.com
Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.
Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
