summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-27regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexsparkhuang
regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex. Fixes: a06ccd9c3785f ("regulator: core: Add ability to create a lookup alias for supply") Signed-off-by: sparkhuang <huangshaobo3@xiaomi.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20251127025716.5440-1-huangshaobo3@xiaomi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: Use container_of_const() when all types areMark Brown
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>: Use container_of_const(), which is preferred over container_of(), when the argument 'ptr' and returned pointer are already const, for better code safety and readability. Some drivers already have const everywhere, so container_of_const can be directly used. In few other drivers, the final pointer can be constified that way.
2025-11-26regulator: pf9453: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-8-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: pca9450: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-7-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: mt6358: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-6-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: bd96801: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-5-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: bd718x7: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-4-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: bd71828: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-3-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: bd71815: Constify pointers to 'regulator_desc' wrap structKrzysztof Kozlowski
Pointer to 'struct regulator_desc' is a pointer to const and the wrapping structure (container) is not being modified, thus entire syntax can be replaced to preferred and safer container_of_const(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-2-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-26regulator: Use container_of_const() when all types are constKrzysztof Kozlowski
Use container_of_const(), which is preferred over container_of(), when the argument 'ptr' and returned pointer are already const, for better code safety and readability. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-1-eeec378144d4@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-21regulator: Add FP9931/JD9930Mark Brown
Merge series from Andreas Kemnade <andreas@kemnade.info>: Add a driver for the FP9931/JD9930 regulator which provides the comparatively high voltages needed for electronic paper displays. Datasheet for the FP9931 is at https://www.fitipower.com/dl/file/flXa6hIchVeu0W3K Although it is in English, it seems to be only downloadable from the Chinese part of that website. For the JD9930 there can be a datasheet found at https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/JD9930_2D00_0.7_2D00_JUN_2D00_2019.pdf To simplify things, include the hwmon part directly which is only one register read and there are not other functions besides regulators in this chip.
2025-11-21regulator: pca9450: Fix error code in probe()Dan Carpenter
Return "PTR_ERR(pca9450->sd_vsel_gpio)" instead of "ret". The "ret" variable is success at this point. Fixes: 3ce6f4f943dd ("regulator: pca9450: Fix control register for LDO5") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aSBqnPoBrsNB1Ale@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-20regulator: qcomm-labibb: replace use of system_wq with system_dfl_wqMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This specific workload do not benefit from a per-cpu workqueue, so use the default unbound workqueue (system_dfl_wq) instead. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20251106145003.245866-1-marco.crivellari@suse.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-20regulator: Add FP9931/JD9930 driverAndreas Kemnade
Add a driver for the FP9931/JD9930 regulator. Implement handling of the PG (power good), TS_EN (temperature sensor enable), and EN (enable regulators) pins. Implement the pair of symmetric LDOs as a single regulator because they share a single voltage set register. For simplicity, just add the temperature sensor (depending on external NTC) directly. Limitations: - As these regulators are controlled together with the VCOM regulator via the EN pin, some kind of management must be in place. As the enable op is not called when the regulator is already enabled, simple refcounting seems not to work to avoid clearing EN when one regulator is still enabled. As these regulators are typically used together, this limitation should not hurt hard, just provide the is_enabled op. - As the VCOM step is quite odd (5V/255 steps), rounding is needed. Due to some limitations in the regulator core, the max/min voltages in the devicetree must match the idea of the driver how to round things exactly. - Night mode is not implemented, so only the FP9931 compatible is needed in the driver, there is no REGULATOR_MODE_NIGHT and no clear definition in the datasheet what it does, also the XON pin which seems to be an input related to that night mode is not used. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20251115-fp9931-submit-v3-3-92f5d0772b68@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-20dt-bindings: regulator: Add Fitipower FP9931/JD9930Andreas Kemnade
Document the FP9931/JD9930. As the FP9931 is a clear subset of the JD9930, define it as a fallback compatible. GPIO names are same as in the datasheet except for the EN pad which is described as "enable". Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20251115-fp9931-submit-v3-2-92f5d0772b68@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-20dt-bindings: vendor-prefixes: Add FitipowerAndreas Kemnade
Add Fitipower Integrated Technology Inc. to the vendor prefixes. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20251115-fp9931-submit-v3-1-92f5d0772b68@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-20gpio: improve support for shared GPIOsMark Brown
Merge series from Bartosz Golaszewski <brgl@bgdev.pl>: Problem statement: GPIOs are implemented as a strictly exclusive resource in the kernel but there are lots of platforms on which single pin is shared by multiple devices which don't communicate so need some way of properly sharing access to a GPIO. What we have now is the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and doesn't do any locking or arbitration of access - it literally just hand the same GPIO descriptor to all interested users. The proposed solution is composed of three major parts: the high-level, shared GPIO proxy driver that arbitrates access to the shared pin and exposes a regular GPIO chip interface to consumers, a low-level shared GPIOLIB module that scans firmware nodes and creates auxiliary devices that attach to the proxy driver and finally a set of core GPIOLIB changes that plug the former into the GPIO lookup path. The changes are implemented in a way that allows to seamlessly compile out any code related to sharing GPIOs for systems that don't need it. The practical use-case for this are the powerdown GPIOs shared by speakers on Qualcomm db845c platform, however I have also extensively tested it using gpio-virtuser on arm64 qemu with various DT configurations.
2025-11-19regulator: make the subsystem aware of shared GPIOsBartosz Golaszewski
GPIOLIB is now aware of shared GPIOs and - for platforms where access to such pins is managed internally - we don't need to keep track of the enable count. Once all users in the kernel switch to using the new mechanism, we'll be able to drop the internal counting of users from the regulator code. Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://patch.msgid.link/20251112-gpio-shared-v4-10-b51f97b1abd8@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-18regulator: renesas-usb-vbus-regulator: Remove unused headersClaudiu Beznea
Remove unused included headers. This makes the code simpler. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20251117103205.4038600-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-18regulator: pca9450: Add support for setting debounce settingsMartijn de Gouw
Make the different debounce timers configurable from the devicetree. Depending on the board design, these have to be set different than the default register values. Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com> Link: https://patch.msgid.link/20251117202215.1936139-2-martijn.de.gouw@prodrive-technologies.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-18regulator: dt-bindings: pca9540: add debounce timer configurationMartijn de Gouw
Make the different debounce timers configurable from the devicetree. Depending on the board design, these have to be set different than the default register values. Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251117202215.1936139-1-martijn.de.gouw@prodrive-technologies.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-17gpio: provide gpiod_is_shared()Bartosz Golaszewski
Provide an interface allowing consumers to check if a GPIO descriptor represents a GPIO that can potentially be shared by multiple consumers at the same time. This is exposed to allow subsystems that already work around the limitations of the current non-exclusive GPIO handling in some ways, to gradually convert to relying on the new shared GPIO feature of GPIOLIB. Extend the gpiolib-shared module to mark the GPIO shared proxy descriptors with a flag checked by the new interface. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-6-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: support shared GPIOs in core subsystem codeBartosz Golaszewski
As the final step in adding official support for shared GPIOs, enable the previously added elements in core GPIO subsystem code. Set-up shared GPIOs when adding a GPIO chip, tear it down on removal and check if a GPIO descriptor looked up during the firmware-node stage is shared and fall-back to machine lookup in this case. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-5-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpio: shared-proxy: implement the shared GPIO proxy driverBartosz Golaszewski
Add a virtual GPIO proxy driver which arbitrates access to a single shared GPIO by multiple users. It works together with the core shared GPIO support from GPIOLIB and functions by acquiring a reference to a shared GPIO descriptor exposed by gpiolib-shared and making sure that the state of the GPIO stays consistent. In general: if there's only one user at the moment: allow it to do anything as if this was a normal GPIO (in essence: just propagate calls to the underlying real hardware driver). If there are more users: don't allow to change the direction set by the initial user, allow to change configuration options but warn about possible conflicts and finally: treat the output-high value as a reference counted, logical "GPIO enabled" setting, meaning: the GPIO value is set to high when the first user requests it to be high and back to low once the last user stops "voting" for high. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-4-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: implement low-level, shared GPIO supportBartosz Golaszewski
This module scans the device tree (for now only OF nodes are supported but care is taken to make other fwnode implementations easy to integrate) and determines which GPIO lines are shared by multiple users. It stores that information in memory. When the GPIO chip exposing shared lines is registered, the shared GPIO descriptors it exposes are marked as shared and virtual "proxy" devices that mediate access to the shared lines are created. When a consumer of a shared GPIO looks it up, its fwnode lookup is redirected to a just-in-time machine lookup that points to this proxy device. This code can be compiled out on platforms which don't use shared GPIOs. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-3-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17gpiolib: define GPIOD_FLAG_SHAREDBartosz Golaszewski
Define a new GPIO descriptor flag for marking pins that are shared by multiple consumer. This flag will be used in several places so we need to do it in advance and separately from other changes. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-2-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-17string: provide strends()Bartosz Golaszewski
Implement a function for checking if a string ends with a different string and add its kunit test cases. Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-1-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-16Linux 6.18-rc6v6.18-rc6Linus Torvalds
2025-11-16Merge tag 'perf-tools-fixes-for-v6.18-2-2025-11-16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix writing bpf_prog (infos|btfs)_cnt to data file, to not generate invalid perf.data files in some corner cases. - Fix 'perf top' segfault by ensuring libbfd is initialized. This is an opt-in feature due to license incompatibilities. - Fix segfault in 'perf lock' due to missing kernel map. - Fix 'perf lock contention' test. - Don't fail fast path detection if binutils-devel isn't available. - Sync KVM's vmx.h with the kernel to pick SEAMCALL exit reason. * tag 'perf-tools-fixes-for-v6.18-2-2025-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf libbfd: Ensure libbfd is initialized prior to use perf test: Fix lock contention test perf lock: Fix segfault due to missing kernel map tools headers UAPI: Sync KVM's vmx.h with the kernel to pick SEAMCALL exit reason perf build: Don't fail fast path feature detection when binutils-devel is not available perf header: Write bpf_prog (infos|btfs)_cnt to data file
2025-11-16Merge tag 'mm-hotfixes-stable-2025-11-16-10-40' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "7 hotfixes. 5 are cc:stable, 4 are against mm/ All are singletons - please see the respective changelogs for details" * tag 'mm-hotfixes-stable-2025-11-16-10-40' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm, swap: fix potential UAF issue for VMA readahead selftests/user_events: fix type cast for write_index packed member in perf_test lib/test_kho: check if KHO is enabled mm/huge_memory: fix folio split check for anon folios in swapcache MAINTAINERS: update David Hildenbrand's email address crash: fix crashkernel resource shrink mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb
2025-11-16Merge tag 'firewire-fixes-6.18-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fixes from Takashi Sakamoto: "This includes some fixes for the topology map, newly introduced in v6.18 kernel" * tag 'firewire-fixes-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: fix to update generation field in topology map firewire: core: Initialize topology_map.lock
2025-11-16Merge tag 'edac_urgent_for_v6.18_rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fixes from Borislav Petkov: - In Versalnet, handle the reporting of non-standard hw errors whose information can come in more than one remote processor message. - Explicitly reenable ECC checking after a warm reset in Altera OCRAM as those registers are reset to default otherwise - Fix single-bit error injection in Altera EDAC to not inject errors directly in ECC RAM and thus lead to false double-bit errors due to same ECC RAM being in concurrent use * tag 'edac_urgent_for_v6.18_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection EDAC/altera: Handle OCRAM ECC enable after warm reset EDAC/versalnet: Handle split messages for non-standard errors
2025-11-16firewire: core: fix to update generation field in topology mapTakashi Sakamoto
The generation field of topology map is updated after initialized by zero. The updated value of generation field is always zero, and is against specification. This commit fixes the bug. Fixes: 7d138cb269db ("firewire: core: use spin lock specific to topology map") Link: https://lore.kernel.org/r/20251114144421.415278-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-11-15mm, swap: fix potential UAF issue for VMA readaheadKairui Song
Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning"), the common helper for allocating and preparing a folio in the swap cache layer no longer tries to get a swap device reference internally, because all callers of __read_swap_cache_async are already holding a swap entry reference. The repeated swap device pinning isn't needed on the same swap device. Caller of VMA readahead is also holding a reference to the target entry's swap device, but VMA readahead walks the page table, so it might encounter swap entries from other devices, and call __read_swap_cache_async on another device without holding a reference to it. So it is possible to cause a UAF when swapoff of device A raced with swapin on device B, and VMA readahead tries to read swap entries from device A. It's not easy to trigger, but in theory, it could cause real issues. Make VMA readahead try to get the device reference first if the swap device is a different one from the target entry. Link: https://lkml.kernel.org/r/20251111-swap-fix-vma-uaf-v1-1-41c660e58562@tencent.com Fixes: 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning") Suggested-by: Huang Ying <ying.huang@linux.alibaba.com> Signed-off-by: Kairui Song <kasong@tencent.com> Acked-by: Chris Li <chrisl@kernel.org> Cc: Baoquan He <bhe@redhat.com> Cc: Barry Song <baohua@kernel.org> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Nhat Pham <nphamcs@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15selftests/user_events: fix type cast for write_index packed member in perf_testAnkit Khushwaha
Accessing 'reg.write_index' directly triggers a -Waddress-of-packed-member warning due to potential unaligned pointer access: perf_test.c:239:38: warning: taking address of packed member 'write_index' of class or structure 'user_reg' may result in an unaligned pointer value [-Waddress-of-packed-member] 239 | ASSERT_NE(-1, write(self->data_fd, &reg.write_index, | ^~~~~~~~~~~~~~~ Since write(2) works with any alignment. Casting '&reg.write_index' explicitly to 'void *' to suppress this warning. Link: https://lkml.kernel.org/r/20251106095532.15185-1-ankitkhushwaha.linux@gmail.com Fixes: 42187bdc3ca4 ("selftests/user_events: Add perf self-test for empty arguments events") Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com> Cc: Beau Belgrave <beaub@linux.microsoft.com> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: sunliming <sunliming@kylinos.cn> Cc: Wei Yang <richard.weiyang@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15lib/test_kho: check if KHO is enabledPasha Tatashin
We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized. Link: https://lkml.kernel.org/r/20251106220635.2608494-1-pasha.tatashin@soleen.com Fixes: b753522bed0b ("kho: add test for kexec handover") Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202511061629.e242724-lkp@intel.com Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Alexander Graf <graf@amazon.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15mm/huge_memory: fix folio split check for anon folios in swapcacheZi Yan
Both uniform and non uniform split check missed the check to prevent splitting anon folios in swapcache to non-zero order. Splitting anon folios in swapcache to non-zero order can cause data corruption since swapcache only support PMD order and order-0 entries. This can happen when one use split_huge_pages under debugfs to split anon folios in swapcache. In-tree callers do not perform such an illegal operation. Only debugfs interface could trigger it. I will put adding a test case on my TODO list. Fix the check. Link: https://lkml.kernel.org/r/20251105162910.752266-1-ziy@nvidia.com Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()") Signed-off-by: Zi Yan <ziy@nvidia.com> Reported-by: "David Hildenbrand (Red Hat)" <david@kernel.org> Closes: https://lore.kernel.org/all/dc0ecc2c-4089-484f-917f-920fdca4c898@kernel.org/ Acked-by: David Hildenbrand (Red Hat) <david@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Wei Yang <richard.weiyang@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15MAINTAINERS: update David Hildenbrand's email addressDavid Hildenbrand (Red Hat)
Switch to kernel.org email address as I will be leaving Red Hat. The old address will remain active until end of January 2026, so performing the change now should make sure that most mails will reach me. Link: https://lkml.kernel.org/r/20251103103659.379335-1-david@kernel.org Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15crash: fix crashkernel resource shrinkSourabh Jain
When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI <snip...> Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 <snip...> This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory. Link: https://lkml.kernel.org/r/20251101193741.289252-1-sourabhjain@linux.ibm.com Fixes: 16c6006af4d4 ("kexec: enable kexec_crash_size to support two crash kernel regions") Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlbDavid Hildenbrand (Red Hat)
In the past, CONFIG_ARCH_HAS_GIGANTIC_PAGE indicated that we support runtime allocation of gigantic hugetlb folios. In the meantime it evolved into a generic way for the architecture to state that it supports gigantic hugetlb folios. In commit fae7d834c43c ("mm: add __dump_folio()") we started using CONFIG_ARCH_HAS_GIGANTIC_PAGE to decide MAX_FOLIO_ORDER: whether we could have folios larger than what the buddy can handle. In the context of that commit, we started using MAX_FOLIO_ORDER to detect page corruptions when dumping tail pages of folios. Before that commit, we assumed that we cannot have folios larger than the highest buddy order, which was obviously wrong. In commit 7b4f21f5e038 ("mm/hugetlb: check for unreasonable folio sizes when registering hstate"), we used MAX_FOLIO_ORDER to detect inconsistencies, and in fact, we found some now. Powerpc allows for configs that can allocate gigantic folio during boot (not at runtime), that do not set CONFIG_ARCH_HAS_GIGANTIC_PAGE and can exceed PUD_ORDER. To fix it, let's make powerpc select CONFIG_ARCH_HAS_GIGANTIC_PAGE with hugetlb on powerpc, and increase the maximum folio size with hugetlb to 16 GiB on 64bit (possible on arm64 and powerpc) and 1 GiB on 32 bit (powerpc). Note that on some powerpc configurations, whether we actually have gigantic pages depends on the setting of CONFIG_ARCH_FORCE_MAX_ORDER, but there is nothing really problematic about setting it unconditionally: we just try to keep the value small so we can better detect problems in __dump_folio() and inconsistencies around the expected largest folio in the system. Ideally, we'd have a better way to obtain the maximum hugetlb folio size and detect ourselves whether we really end up with gigantic folios. Let's defer bigger changes and fix the warnings first. While at it, handle gigantic DAX folios more clearly: DAX can only end up creating gigantic folios with HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD. Add a new Kconfig option HAVE_GIGANTIC_FOLIOS to make both cases clearer. In particular, worry about ARCH_HAS_GIGANTIC_PAGE only with HUGETLB_PAGE. Note: with enabling CONFIG_ARCH_HAS_GIGANTIC_PAGE on powerpc, we will now also allow for runtime allocations of folios in some more powerpc configs. I don't think this is a problem, but if it is we could handle it through __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED. While __dump_page()/__dump_folio was also problematic (not handling dumping of tail pages of such gigantic folios correctly), it doesn't seem critical enough to mark it as a fix. Link: https://lkml.kernel.org/r/20251114214920.2550676-1-david@kernel.org Fixes: 7b4f21f5e038 ("mm/hugetlb: check for unreasonable folio sizes when registering hstate") Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Closes: https://lore.kernel.org/r/3e043453-3f27-48ad-b987-cc39f523060a@csgroup.eu/ Reported-by: Sourabh Jain <sourabhjain@linux.ibm.com> Closes: https://lore.kernel.org/r/94377f5c-d4f0-4c0f-b0f6-5bf1cd7305b1@linux.ibm.com/ Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Donet Tom <donettom@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-15Merge tag 's390-6.18-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fix from Heiko Carstens: - Fix a bug in the __ptep_rdp() inline assembly which may lead to missing TLB flushes * tag 's390-6.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/mm: Fix __ptep_rdp() inline assembly
2025-11-15Merge tag 'x86-urgent-2025-11-15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Update the list of AMD microcode minimum Entrysign revisions - Add additional fixed AMD RDSEED microcode revisions - Update the language transliteration for Kiryl Shutsemau's name in the MAINTAINERS entry * tag 'x86-urgent-2025-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev x86/CPU/AMD: Add additional fixed RDSEED microcode revisions MAINTAINERS: Update name spelling
2025-11-15Merge tag 'timers-urgent-2025-11-15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Ingo Molnar: "Fix a memory leak in the posix timer creation logic" * tag 'timers-urgent-2025-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: posix-timers: Plug potential memory leak in do_timer_create()
2025-11-15Merge tag 'irq-urgent-2025-11-15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "Fix an irqchip driver release bug in the riscv-intc irqchip driver" * tag 'irq-urgent-2025-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_ops
2025-11-15Merge tag 'core-urgent-2025-11-15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull core fix from Ingo Molnar: "Fix a broken #ifndef in the <linux/entry-virt.h> header. It hasn't caused problems upstream yet because no arch overrides arch_xfer_to_guest_mode_handle_work() at this moment" * tag 'core-urgent-2025-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Fix ifndef around arch_xfer_to_guest_mode_handle_work() stub
2025-11-14Merge tag 'pci-v6.18-fixes-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Cache the ASPM L0s/L1 Supported bits early so quirks can override them if necessary (Bjorn Helgaas) - Add quirks for PA Semi and Freescale Root Ports and a HiSilicon Wi-Fi device that are reported to have broken L0s and L1 (Shawn Lin, Bjorn Helgaas) * tag 'pci-v6.18-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/ASPM: Avoid L0s and L1 on Hi1105 [19e5:1105] Wi-Fi PCI/ASPM: Avoid L0s and L1 on PA Semi [1959:a002] Root Ports PCI/ASPM: Avoid L0s and L1 on Freescale [1957:0451] Root Ports PCI/ASPM: Convert quirks to override advertised link states PCI/ASPM: Add pcie_aspm_remove_cap() to override advertised link states PCI/ASPM: Cache L0s/L1 Supported so advertised link states can be overridden
2025-11-14Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds
Pull bpf fixes from Alexei Starovoitov: - Fix interaction between livepatch and BPF fexit programs (Song Liu) With Steven and Masami acks. - Fix stack ORC unwind from BPF kprobe_multi (Jiri Olsa) With Steven and Masami acks. - Fix out of bounds access in widen_imprecise_scalars() in the verifier (Eduard Zingerman) - Fix conflicts between MPTCP and BPF sockmap (Jiayuan Chen) - Fix net_sched storage collision with BPF data_meta/data_end (Eric Dumazet) - Add _impl suffix to BPF kfuncs with implicit args to avoid breaking them in bpf-next when KF_IMPLICIT_ARGS is added (Mykyta Yatsenko) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: Test widen_imprecise_scalars() with different stack depth bpf: account for current allocated stack depth in widen_imprecise_scalars() bpf: Add bpf_prog_run_data_pointers() selftests/bpf: Add mptcp test with sockmap mptcp: Fix proto fallback detection with BPF mptcp: Disallow MPTCP subflows from sockmap selftests/bpf: Add stacktrace ips test for raw_tp selftests/bpf: Add stacktrace ips test for kprobe_multi/kretprobe_multi x86/fgraph,bpf: Fix stack ORC unwind from kprobe_multi return probe Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()" bpf: add _impl suffix for bpf_stream_vprintk() kfunc bpf:add _impl suffix for bpf_task_work_schedule* kfuncs selftests/bpf: Add tests for livepatch + bpf trampoline ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct() ftrace: Fix BPF fexit with livepatch
2025-11-14Merge tag 'rust-fixes-6.18-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fix from Miguel Ojeda: - Fix a Rust 1.91.0 build issue due to 'bindings.o' not containing DWARF debug information anymore by teaching gendwarfksyms to skip object files without exports * tag 'rust-fixes-6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: gendwarfksyms: Skip files with no exports
2025-11-14Merge tag 'nfs-for-6.18-3' of git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds
Pull NFS client fixes from Anna Schumaker: - Various fixes when using NFS with TLS - Localio direct-IO fixes - Fix error handling in nfs_atomic_open_v23() - Fix sysfs memory leak when nfs_client kobject add fails - Fix an incorrect parameter when calling nfs4_call_sync() - Fix a failing LTP test when using delegated timestamps * tag 'nfs-for-6.18-3' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFS: Fix LTP test failures when timestamps are delegated NFSv4: Fix an incorrect parameter when calling nfs4_call_sync() NFS: sysfs: fix leak when nfs_client kobject add fails NFSv2/v3: Fix error handling in nfs_atomic_open_v23() nfs/localio: do not issue misaligned DIO out-of-order nfs/localio: Ensure DIO WRITE's IO on stable storage upon completion nfs/localio: backfill missing partial read support for misaligned DIO nfs/localio: add refcounting for each iocb IO associated with NFS pgio header nfs/localio: remove unecessary ENOTBLK handling in DIO WRITE support NFS: Check the TLS certificate fields in nfs_match_client() pnfs: Set transport security policy to RPC_XPRTSEC_NONE unless using TLS pnfs: Fix TLS logic in _nfs4_pnfs_v4_ds_connect() pnfs: Fix TLS logic in _nfs4_pnfs_v3_ds_connect()
2025-11-14Merge tag 'drm-fixes-2025-11-15' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly fixes, amdgpu and vmwgfx making up the most of it, along with panthor and i915/xe. Seems about right for this time of development, nothing major outstanding. client: - Fix description of module parameter panthor: - Flush writes before mapping buffers vmwgfx: - Improve command validation - Improve ref counting - Fix cursor-plane support amdgpu: - Disallow P2P DMA for GC 12 DCC surfaces - ctx error handling fix - UserQ fixes - VRR fix - ISP fix - JPEG 5.0.1 fix amdkfd: - Save area check fix - Fix GPU mappings for APU after prefetch i915: - Fix PSR's pipe to vblank conversion - Disable Panel Replay on MST links xe: - New HW workarounds affecting PTL and WCL platforms * tag 'drm-fixes-2025-11-15' of https://gitlab.freedesktop.org/drm/kernel: drm/client: fix MODULE_PARM_DESC string for "active" drm/i915/dp_mst: Disable Panel Replay drm/amdkfd: Fix GPU mappings for APU after prefetch drm/amdkfd: relax checks for over allocation of save area drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1 drm/amd/amdgpu: Ensure isp_kernel_buffer_alloc() creates a new BO drm/amd/display: Allow VRR params change if unsynced with the stream drm/amdgpu: fix lock warning in amdgpu_userq_fence_driver_process drm/amdgpu: jump to the correct label on failure drm/amdgpu: disable peer-to-peer access for DCC-enabled GC12 VRAM surfaces drm/xe/xe3lpg: Extend Wa_15016589081 for xe3lpg drm/xe/xe3: Extend wa_14023061436 drm/xe/xe3: Add WA_14024681466 for Xe3_LPG drm/i915/psr: fix pipe to vblank conversion drm/panthor: Flush shmem writes before mapping buffers CPU-uncached drm/vmwgfx: Restore Guest-Backed only cursor plane support drm/vmwgfx: Use kref in vmw_bo_dirty drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE