summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-06drm/xe/vf: Store the GuC FW info in guc->fwDaniele Ceraolo Spurio
The GuC compatibility version that we read from the CSS header in native/PF and the GuC VF version that we get when a VF handshakes with the GuC are the same version number, so we should store it into the same structure. This makes all the checks based on the compatibility version automatically work for VFs without having to copy the value over. For completion, also copy the wanted version and set the path to a known string to indicate that the FW is PF-loaded. This way all the info will be coherent when dumped from debugfs. v2: several code cleanups and style changes (Michal), rebase on bootstrap changes. v3: s/min/wanted/, clarify that handshake must happen before we can get the VF versions (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-10-daniele.ceraolospurio@intel.com
2025-06-06drm/xe/vf: Use uc_fw_version to store the negotiated GuC ABIDaniele Ceraolo Spurio
Instead of using a VF-specific type, we can use the common uc_fw_version structure. This also means that we can use the available macros to compare ABI versions. While at it, exit early from the bootstrap if this is not the first time we're doing it and the version hasn't changed, so we don't end up logging it multiple times. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-9-daniele.ceraolospurio@intel.com
2025-06-06drm/xe/vf: Boostrap all GTs immediately after MMIO initDaniele Ceraolo Spurio
Currently we perform the bootstrap for the primary GT early on during device init, while the media GT bootstrap happens when we try and fetch the hwconfig table. For consistency, move the bootstrap of the media GT happen at the same time as the primary GT, so that all the subsequent code can rely on both GTs being in the same state. v2: Also drop config query from min_guc_load since we now do it early (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-8-daniele.ceraolospurio@intel.com
2025-06-06drm/xe/uc: Prepare uc_fw_version for storing the VF ABI versionDaniele Ceraolo Spurio
The VF ABI version has a branch field, so to store it inside the uc_fw_version we need to add a new branch variable to the latter. Existing code needs to be updated to handle the fact that we have the new field. v2: split out to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250603235432.720833-7-daniele.ceraolospurio@intel.com
2025-06-06Merge tag 'drm-next-2025-06-06' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "This is pretty much two weeks worth of fixes, plus one thing that might be considered next: amdkfd is now able to be enabled on risc-v platforms. Otherwise, amdgpu and xe with the majority of fixes, and then a smattering all over. panel: - nt37801: fix IS_ERR - nt37801: fix KConfig connector: - Fix null deref in HDMI audio helper. bridge: - analogix_dp: fixup clk-disable removal nouveau: - minor typo fix (',' vs ';') msm: - mailmap updates i915: - Fix the enabling/disabling of DP audio SDP splitting - Fix PSR register definitions for ALPM - Fix u32 overflow in SNPS PHY HDMI PLL setup - Fix GuC pending message underflow when submit fails - Fix GuC wakeref underflow race during reset xe: - Two documentation fixes - A couple of vm init fixes - Hwmon fixes - Drop reduntant conversion to bool - Fix CONFIG_INTEL_VSEC dependency - Rework eviction rejection of bound external bos - Stop re-submitting signalled jobs - A couple of pxp fixes - Add back a fix that got lost in a merge - Create LRC bo without VM - Fix for the above fix amdgpu: - UserQ fixes - SMU 13.x fixes - VCN fixes - JPEG fixes - Misc cleanups - runtime pm fix - DCN 4.0.1 fixes - Misc display fixes - ISP fix - VRAM manager fix - RAS fixes - IP discovery fix - Cleaner shader fix for GC 10.1.x - OD fix - Non-OLED panel fix - Misc display fixes - Brightness fixes amdkfd: - Enable CONFIG_HSA_AMD on RISCV - SVM fix - Misc cleanups - Ref leak fix - WPTR BO fix radeon: - Misc cleanups" * tag 'drm-next-2025-06-06' of https://gitlab.freedesktop.org/drm/kernel: (105 commits) drm/nouveau/vfn/r535: Convert comma to semicolon drm/xe: remove unmatched xe_vm_unlock() from __xe_exec_queue_init() drm/xe: Create LRC BO without VM drm/xe/guc_submit: add back fix drm/xe/pxp: Clarify PXP queue creation behavior if PXP is not ready drm/xe/pxp: Use the correct define in the set_property_funcs array drm/xe/sched: stop re-submitting signalled jobs drm/xe: Rework eviction rejection of bound external bos drm/xe/vsec: fix CONFIG_INTEL_VSEC dependency drm/xe: drop redundant conversion to bool drm/xe/hwmon: Move card reactive critical power under channel card drm/xe/hwmon: Add support to manage power limits though mailbox drm/xe/vm: move xe_svm_init() earlier drm/xe/vm: move rebind_work init earlier MAINTAINERS: .mailmap: update Rob Clark's email address mailmap: Update entry for Akhil P Oommen MAINTAINERS: update my email address MAINTAINERS: drop myself as maintainer drm/i915/display: Fix u32 overflow in SNPS PHY HDMI PLL setup drm/amd/display: Fix default DC and AC levels ...
2025-06-06Merge tag 'mips_6.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS updates from Thomas Bogendoerfer: - Added support for EcoNet platform - Added support for parallel CPU bring up on EyeQ - Other cleanups and fixes * tag 'mips_6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (23 commits) MIPS: loongson2ef: lemote-2f: add missing function prototypes MIPS: loongson2ef: cs5536: add missing function prototypes MIPS: SMP: Move the AP sync point before the calibration delay mips: econet: Fix incorrect Kconfig dependencies MAINTAINERS: Add entry for newly added EcoNet platform. mips: dts: Add EcoNet DTS with EN751221 and SmartFiber XP8421-B board dt-bindings: vendor-prefixes: Add SmartFiber mips: Add EcoNet MIPS platform support dt-bindings: mips: Add EcoNet platform binding MIPS: bcm63xx: nvram: avoid inefficient use of crc32_le_combine() mips: dts: pic32: pic32mzda: Rename the sdhci nodename to match with common mmc-controller binding MIPS: SMP: Move the AP sync point before the non-parallel aware functions MIPS: Replace strcpy() with strscpy() in vpe_elfload() MIPS: BCM63XX: Replace strcpy() with strscpy() in board_prom_init() mips: ptrace: Improve code formatting and indentation MIPS: SMP: Implement parallel CPU bring up for EyeQ mips: Add -std= flag specified in KBUILD_CFLAGS to vdso CFLAGS MIPS: Loongson64: Add missing '#interrupt-cells' for loongson64c_ls7a mips: dts: realtek: Add MDIO controller MIPS: txx9: gpio: use new line value setter callbacks ...
2025-06-06uapi: bitops: use UAPI-safe variant of BITS_PER_LONG againThomas Weißschuh
Commit 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"") did not take in account that the usage of BITS_PER_LONG in __GENMASK() was changed to __BITS_PER_LONG for UAPI-safety in commit 3c7a8e190bc5 ("uapi: introduce uapi-friendly macros for GENMASK"). BITS_PER_LONG can not be used in UAPI headers as it derives from the kernel configuration and not from the current compiler invocation. When building compat userspace code or a compat vDSO its value will be incorrect. Switch back to __BITS_PER_LONG. Fixes: 1e7933a575ed ("uapi: Revert "bitops: avoid integer overflow in GENMASK(_ULL)"") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
2025-06-06drm/tests: bridge: add KUnit tests for devm_drm_bridge_alloc()Luca Ceresoli
Add KUnit tests for the newly introduced devm_drm_bridge_alloc(). Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-3-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/bridge: add a .destroy funcLuca Ceresoli
Some users of DRM bridges may need to execute specific code just before deallocation. As of now the only known user would be KUnit tests. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-2-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/tests: bridge: convert to devm_drm_bridge_alloc() APILuca Ceresoli
Use the new DRM bridge allocation API, which is the only supported now, for the kunit tests. This change is more massive than for the typical DRM bridge driver because struct drm_bridge_init_priv currently embeds a struct drm_bridge, which is not supported anymore. We now have to use devm_drm_bridge_alloc() to dynamically allocate a "private driver struct", which is a bit awkward here because there is no real bridge driver. Thus let's add a "dummy" DRM bridge struct to represent it. As a nice cleanup we can now move the enable_count and disable_count members, which are counting bridge-specific events, into the new "private driver struct" (and avoid adding new unnecessary indirections). Also add a trivial bridge_to_dummy_bridge() function just like many drivers do. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-1-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06Merge tag 'drm-misc-fixes-2025-06-06' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: ivpu: - gem: Use dma-resv lock - gem. Fix a warning - Trigger recovery on device engine reset/resume failure panel: - panel-simple: Fix settings for Evervision VGG644804 sysfb: - Fix screen_info type check video: - Update screen_info for relocated PCI framebuffers Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250606072853.GA13099@linux.fritz.box
2025-06-06drm/bridge: cdns-dsi: Use pre_enable/post_disable to enable/disableAradhya Bhatia
The cdns-dsi controller requires that it be turned on completely before the input DPI's source has begun streaming[0]. Not having that, allows for a small window before cdns-dsi enable and after cdns-dsi disable where the previous entity (in this case tidss's videoport) to continue streaming DPI video signals. This small window where cdns-dsi is disabled but is still receiving signals causes the input FIFO of cdns-dsi to get corrupted. This causes the colors to shift on the output display. The colors can either shift by one color component (R->G, G->B, B->R), or by two color components (R->B, G->R, B->G). Since tidss's videoport starts streaming via crtc enable hooks, we need cdns-dsi to be up and running before that. Now that the bridges are pre_enabled before crtc is enabled, and post_disabled after crtc is disabled, use the pre_enable and post_disable hooks to get cdns-dsi ready and running before the tidss videoport to get pass the color shift issues. [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM TRM Link: http://www.ti.com/lit/pdf/spruil1 Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-5-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Re-order bridge chain pre-enable and post-disableAradhya Bhatia
Move the bridge pre_enable call before crtc enable, and the bridge post_disable call after the crtc disable. The sequence of enable after this patch will look like: bridge[n]_pre_enable ... bridge[1]_pre_enable crtc_enable encoder_enable bridge[1]_enable ... bridge[n]_enable And, the disable sequence for the display pipeline will look like: bridge[n]_disable ... bridge[1]_disable encoder_disable crtc_disable bridge[1]_post_disable ... bridge[n]_post_disable The definition of bridge pre_enable hook says that, "The display pipe (i.e. clocks and timing signals) feeding this bridge will not yet be running when this callback is called". Since CRTC is also a source feeding the bridge, it should not be enabled before the bridges in the pipeline are pre_enabled. Fix that by re-ordering the sequence of bridge pre_enable and bridge post_disable. While at it, update the drm bridge API documentation as well. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-4-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Separate out bridge pre_enable/post_disable from ↵Aradhya Bhatia
enable/disable The encoder-bridge ops occur by looping over the new connector states of the display pipelines. The enable sequence runs as follows - - pre_enable(bridge), - enable(encoder), - enable(bridge), while the disable sequnce runs as follows - - disable(bridge), - disable(encoder), - post_disable(bridge). Separate out the pre_enable(bridge), and the post_disable(bridge) operations into separate functions each. This patch keeps the sequence same for any singular disaplay pipe, but changes the sequence across multiple display pipelines. This patch is meant to be an interim patch, to cleanly pave the way for the sequence re-ordering patch, and maintain bisectability in the process. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-3-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Refactor crtc & encoder-bridge op loops into separate ↵Aradhya Bhatia
functions The way any singular display pipeline, in need of a modeset, gets enabled is as follows - crtc enable (all) bridge pre-enable encoder enable (all) bridge enable - and the disable sequence is exactly the reverse of this. The crtc operations occur by looping over the old and new crtc states, while the encoder and bridge operations occur together, by looping over the connector states of the display pipelines. Refactor these operations - crtc enable/disable, and encoder & bridge (pre/post) enable/disable - into separate functions each, to make way for the re-ordering of the enable/disable sequences. This patch doesn't alter the sequence of crtc/encoder/bridge operations in any way, but helps to cleanly pave the way for the next two patches, by maintaining logical bisectability. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-2-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06net: enetc: fix the netc-lib driver build dependencyWei Fang
The kernel robot reported the following errors when the netc-lib driver was compiled as a loadable module and the enetc-core driver was built-in. ld.lld: error: undefined symbol: ntmp_init_cbdr referenced by enetc_cbdr.c:88 (drivers/net/ethernet/freescale/enetc/enetc_cbdr.c:88) ld.lld: error: undefined symbol: ntmp_free_cbdr referenced by enetc_cbdr.c:96 (drivers/net/ethernet/freescale/enetc/enetc_cbdr.c:96) Simply changing "tristate" to "bool" can fix this issue, but considering that the netc-lib driver needs to support being compiled as a loadable module and LS1028 does not need the netc-lib driver. Therefore, we add a boolean symbol 'NXP_NTMP' to enable 'NXP_NETC_LIB' as needed. And when adding NETC switch driver support in the future, there is no need to modify the dependency, just select "NXP_NTMP" and "NXP_NETC_LIB" at the same time. Reported-by: Arnd Bergmann <arnd@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505220734.x6TF6oHR-lkp@intel.com/ Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Suggested-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-06-06platform/loongarch: laptop: Get brightness setting from EC on probeYao Zi
Previously during driver probe, 1 is unconditionally taken as current brightness value and set to props.brightness, which will be considered as the brightness before suspend and restored to EC on resume. Since a brightness value of 1 almost never matches EC's state on coldboot (my laptop's EC defaults to 80), this causes surprising changes of screen brightness on the first time of resume after coldboot. Let's get brightness from EC and take it as the current brightness on probe of the laptop driver to avoid the surprising behavior. Tested on TongFang L860-T2 Loongson-3A5000 laptop. Cc: stable@vger.kernel.org Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver") Signed-off-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-06LoongArch: dts: Add PWM support to Loongson-2K2000Binbin Zhou
The module is supported, enable it. Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-06LoongArch: dts: Add PWM support to Loongson-2K1000Binbin Zhou
The module is supported, enable it. Also, add the pwm-fan and cooling-maps associated with it. Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-06LoongArch: dts: Add PWM support to Loongson-2K0500Binbin Zhou
The module is supported, enable it. Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-06LoongArch: vDSO: Correctly use asm parameters in syscall wrappersThomas Weißschuh
The syscall wrappers use the "a0" register for two different register variables, both the first argument and the return value. Here the "ret" variable is used as both input and output while the argument register is only used as input. Clang treats the conflicting input parameters as an undefined behaviour and optimizes away the argument assignment. The code seems to work by chance for the most part today but that may change in the future. Specifically clock_gettime_fallback() fails with clockids from 16 to 23, as implemented by the upcoming auxiliary clocks. Switch the "ret" register variable to a pure output, similar to the other architectures' vDSO code. This works in both clang and GCC. Link: https://lore.kernel.org/lkml/20250602102825-42aa84f0-23f1-4d10-89fc-e8bbaffd291a@linutronix.de/ Link: https://lore.kernel.org/lkml/20250519082042.742926976@linutronix.de/ Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support") Fixes: 18efd0b10e0f ("LoongArch: vDSO: Wire up getrandom() vDSO implementation") Cc: stable@vger.kernel.org Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Reviewed-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2025-06-06drm/panthor: Clean up 64-bit register definitionsKarunika Choo
With the introduction of 64-bit register accessors, the separate *_HI definitions are no longer necessary. This change removes them and renames the corresponding *_LO entries for cleaner and more consistent register definitions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add 64-bit and poll register accessorsKarunika Choo
This patch adds 64-bit register accessors to simplify register access in Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout. This patch also updates Panthor to use the new 64-bit accessors and poll functions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Fix the user MMIO offset logic for emulatorsBoris Brezillon
Currently, we pick the MMIO offset based on the size of the pgoff_t type seen by the process that manipulates the FD, such that a 32-bit process can always map the user MMIO ranges. But this approach doesn't work well for emulators like FEX, where the emulator is a 64-bit binary which might be executing 32-bit code. In that case, the kernel thinks it's the 64-bit process and assumes DRM_PANTHOR_USER_MMIO_OFFSET_64BIT is in use, but the UMD library expects DRM_PANTHOR_USER_MMIO_OFFSET_32BIT, because it can't mmap() anything above the pgoff_t size. In order to solve that, we need a way to explicitly set the user MMIO offset from the UMD, such that the kernel doesn't have to guess it from the TIF_32BIT flag set on user thread. We keep the old behavior if DRM_PANTHOR_SET_USER_MMIO_OFFSET is never called. Changes in v2: - Drop the lock/immutable fields and allow SET_USER_MMIO_OFFSET requests to race with mmap() requests - Don't do the is_user_mmio_offset test twice in panthor_mmap() - Improve the uAPI docs Changes in v3: - Bump to version 1.5 instead of 1.4 after rebasing - Add R-bs - Fix/rephrase comment as suggested by Liviu Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add missing explicit padding in drm_panthor_gpu_infoBoris Brezillon
drm_panthor_gpu_info::shader_present is currently automatically offset by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those constraints don't stand on 32-bit x86 and cause a mismatch when running an x86 binary in a user emulated environment like FEX. It's also generally agreed that uAPIs should explicitly pad their struct fields, which we originally intended to do, but a mistake slipped through during the submission process, leading drm_panthor_gpu_info::shader_present to be misaligned. This uAPI change doesn't break any of the existing users of panthor which are either arm32 or arm64 where the 64-bit alignment of u64 fields is already enforced a the compiler level. Changes in v2: - Rename the garbage field into pad0 and adjust the comment accordingly - Add Liviu's A-b Changes in v3: - Add R-bs Fixes: 0f25e493a246 ("drm/panthor: Add uAPI") Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06ceph: fix variable dereferenced before check in ceph_umount_begin()Viacheslav Dubeyko
smatch warnings: fs/ceph/super.c:1042 ceph_umount_begin() warn: variable dereferenced before check 'fsc' (see line 1041) vim +/fsc +1042 fs/ceph/super.c void ceph_umount_begin(struct super_block *sb) { struct ceph_fs_client *fsc = ceph_sb_to_fs_client(sb); doutc(fsc->client, "starting forced umount\n"); ^^^^^^^^^^^ Dereferenced if (!fsc) ^^^^ Checked too late. return; fsc->mount_state = CEPH_MOUNT_SHUTDOWN; __ceph_umount_begin(fsc); } The VFS guarantees that the superblock is still alive when it calls into ceph via ->umount_begin(). Finally, we don't need to check the fsc and it should be valid. This patch simply removes the fsc check. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202503280852.YDB3pxUY-lkp@intel.com/ Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Reviewed by: Alex Markuze <amarkuze@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2025-06-06Merge tag 'drm-misc-fixes-2025-05-28' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: drm-scheduler: - signal scheduled fence when killing job dummycon: - trigger deferred takeover when switching consoles ivpu: - improve logging - update firmware filenames - reorder steps in command-queue unregistering Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250528153550.GA21050@linux.fritz.box
2025-06-05kernel/rcu/tree_stall: add /sys/kernel/rcu_stall_countMax Kellermann
Expose a simple counter to userspace for monitoring tools. (akpm: 2536c5c7d6ae added the documentation but the code changes were lost) Link: https://lkml.kernel.org/r/20250504180831.4190860-3-max.kellermann@ionos.com Fixes: 2536c5c7d6ae ("kernel/rcu/tree_stall: add /sys/kernel/rcu_stall_count") Signed-off-by: Max Kellermann <max.kellermann@ionos.com> Cc: Core Minyard <cminyard@mvista.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Joel Granados <joel.granados@kernel.org> Cc: Max Kellermann <max.kellermann@ionos.com> Cc: Song Liu <song@kernel.org> Cc: Sourabh Jain <sourabhjain@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05MAINTAINERS: add mm swap sectionLorenzo Stoakes
In furtherance of ongoing efforts to ensure people are aware of who de-facto maintains/has an interest in specific parts of mm, as well trying to avoid get_maintainers.pl listing only Andrew and the mailing list for mm files - establish a swap memory management section and add relevant maintainers/reviewers. Link: https://lkml.kernel.org/r/20250604163139.126630-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: Chris Li <chrisl@kernel.org> Acked-by: Kairui Song <kasong@tencent.com> Acked-by: Kemeng Shi <shikemeng@huaweicloud.com> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Barry Song <baohua@kernel.org> Acked-by: Nhat Pham <nphamcs@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05kmsan: test: add module descriptionArnd Bergmann
Every module should have a description, and kbuild now warns for those that don't. WARNING: modpost: missing MODULE_DESCRIPTION() in mm/kmsan/kmsan_test.o Link: https://lkml.kernel.org/r/20250603075323.1839608-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Macro Elver <elver@google.com> Cc: Sabyrzhan Tasbolatov <snovitoll@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05MAINTAINERS: add tlb trace events to MMU GATHER AND TLB INVALIDATIONTal Zussman
The MMU GATHER AND TLB INVALIDATION entry lists other TLB-related files. Add the tlb.h tracepoint file there as well. Link: https://lore.kernel.org/linux-mm/ce048e11-f79d-44a6-bacc-46e1ebc34b24@redhat.com/ Link: https://lkml.kernel.org/r/20250603-tlb-maintainers-v1-1-726d193c6693@columbia.edu Signed-off-by: Tal Zussman <tz2294@columbia.edu> Suggested-by: David Hildenbrand <david@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast raceJann Horn
huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse. Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-2-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250527-hugetlb-fixes-splitrace-v1-2-f4136f5ec58a@google.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Oscar Salvador <osalvador@suse.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm/hugetlb: unshare page tables during VMA split, not beforeJann Horn
Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2] Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-1-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250528-hugetlb-fixes-splitrace-v2-0-1329349bad1a@google.com Link: https://lkml.kernel.org/r/20250527-hugetlb-fixes-splitrace-v1-1-f4136f5ec58a@google.com Fixes: 39dde65c9940 ("[PATCH] shared page table for hugetlb page") Signed-off-by: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> [b30c14cd6102: hugetlb: unshare some PMDs when splitting VMAs] Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05MAINTAINERS: add Alistair as reviewer of mm memory policyAlistair Popple
I'm particularly familiar with mm/migrate.c and especially mm/migrate_device.c so add myself to MAINTAINERS. Link: https://lkml.kernel.org/r/20250530014917.2946940-1-apopple@nvidia.com Signed-off-by: Alistair Popple <apopple@nvidia.com> Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05iov_iter: use iov_offset for length calculation in iov_iter_aligned_bvecNitesh Shetty
If iov_offset is non-zero, then we need to consider iov_offset in length calculation, otherwise we might pass smaller IOs such as 512 bytes, in below scenario [1]. This issue is reproducible using lib-uring test/fixed-seg.c application with fixed buffer on a 512 LBA formatted device. [1] At present we pass the alignment check, for 512 LBA formatted devices, len_mask = 511 when IO is smaller, i->count = 512 has an offset, i->io_offset = 3584 with bvec values, bvec->bv_offset = 256, bvec->bv_len = 3840. In short, the first 256 bytes are in the current page, next 256 bytes are in the another page. Ideally we expect to fail the IO. I can think of 2 userspace scenarios where we experience this. a: From userspace, we observe a different behaviour when device LBA size is 512 vs 4096 bytes. For 4096 LBA formatted device, I see the same liburing test [2] failing, whereas 512 the test passes without this. This is reproducible everytime. [2] https://github.com/axboe/liburing/ b: Although I was not able to reproduce the below condition, but I suspect below case should be possible from user space for devices with 512 LBA formatted device. Lets say from userspace while allocating a virtually single chunk of memory, if we get 2 physical chunk of memory, and IO happens to be at the boundary of first physical chunk with length crossing first chunk, then we allow IOs to proceed and hence we might map wrong physical address length and proceed with IO rather than failing. : --- a/test/fixed-seg.c : +++ b/test/fixed-seg.c : @@ -64,7 +64,7 @@ static int test(struct io_uring *ring, int fd, int : vec_off) : return T_EXIT_FAIL; : } : : - ret = read_it(ring, fd, 4096, vec_off); : + ret = read_it(ring, fd, 4096, 7*512 + 256); : if (ret) { : fprintf(stderr, "4096 0 failed\n"); : return T_EXIT_FAIL; Effectively this is a write crossing the page boundary. Link: https://lkml.kernel.org/r/20250428095849.11709-1-nj.shetty@samsung.com Fixes: 2263639f96f2 ("iov_iter: streamline iovec/bvec alignment iteration") Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm/mempolicy: fix incorrect freeing of wi_kobjJoshua Hahn
We should not free wi_group->wi_kobj here. In the error path of add_weighted_interleave_group() where this snippet is called from, kobj_{del, put} is immediately called right after this section. Thus, it is not only unnecessary but also incorrect to free it here. Link: https://lkml.kernel.org/r/20250602162345.2595696-1-joshua.hahnjy@gmail.com Fixes: e341f9c3c841 ("mm/mempolicy: Weighted Interleave Auto-tuning") Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506011545.Fduxqxqj-lkp@intel.com/ Cc: Alistair Popple <apopple@nvidia.com> Cc: Byungchul Park <byungchul@sk.com> Cc: David Hildenbrand <david@redhat.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Mathew Brost <matthew.brost@intel.com> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05alloc_tag: handle module codetag load errors as module load failuresSuren Baghdasaryan
Failures inside codetag_load_module() are currently ignored. As a result an error there would not cause a module load failure and freeing of the associated resources. Correct this behavior by propagating the error code to the caller and handling possible errors. With this change, error to allocate percpu counters, which happens at this stage, will not be ignored and will cause a module load failure and freeing of resources. With this change we also do not need to disable memory allocation profiling when this error happens, instead we fail to load the module. Link: https://lkml.kernel.org/r/20250521160602.1940771-1-surenb@google.com Fixes: 10075262888b ("alloc_tag: allocate percpu counters for module tags dynamically") Signed-off-by: Suren Baghdasaryan <surenb@google.com> Reported-by: Casey Chen <cachen@purestorage.com> Closes: https://lore.kernel.org/all/20250520231620.15259-1-cachen@purestorage.com/ Cc: Daniel Gomez <da.gomez@samsung.com> Cc: David Wang <00107082@163.com> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Luis Chamberalin <mcgrof@kernel.org> Cc: Petr Pavlu <petr.pavlu@suse.com> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm/madvise: handle madvise_lock() failure during race unwindingSeongJae Park
When unwinding race on -ERESTARTNOINTR handling of process_madvise(), madvise_lock() failure is ignored. Check the failure and abort remaining works in the case. Link: https://lkml.kernel.org/r/20250602174926.1074-1-sj@kernel.org Fixes: 4000e3d0a367 ("mm/madvise: remove redundant mmap_lock operations from process_madvise()") Signed-off-by: SeongJae Park <sj@kernel.org> Reported-by: Barry Song <21cnbao@gmail.com> Closes: https://lore.kernel.org/CAGsJ_4xJXXO0G+4BizhohSZ4yDteziPw43_uF8nPXPWxUVChzw@mail.gmail.com Reviewed-by: Jann Horn <jannh@google.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev> Reviewed-by: Barry Song <baohua@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm: fix vmstat after removing NR_BOUNCEKirill A. Shutemov
Hongyu noticed that the nr_unaccepted counter kept growing even in the absence of unaccepted memory on the machine. This happens due to a commit that removed NR_BOUNCE: it removed the counter from the enum zone_stat_item, but left it in the vmstat_text array. As a result, all counters below nr_bounce in /proc/vmstat are shifted by one line, causing the numa_hit counter to be labeled as nr_unaccepted. To fix this issue, remove nr_bounce from the vmstat_text array. Link: https://lkml.kernel.org/r/20250529103832.2937460-1-kirill.shutemov@linux.intel.com Fixes: 194df9f66db8 ("mm: remove NR_BOUNCE zone stat") Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Hongyu Ning <hongyu.ning@linux.intel.com> Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05KVM: s390: rename PROT_NONE to PROT_TYPE_DUMMYLorenzo Stoakes
The enum type prot_type declared in arch/s390/kvm/gaccess.c declares an unfortunate identifier within it - PROT_NONE. This clashes with the protection bit define from the uapi for mmap() declared in include/uapi/asm-generic/mman-common.h, which is indeed what those casually reading this code would assume this to refer to. This means that any changes which subsequently alter headers in any way which results in the uapi header being imported here will cause build errors. Resolve the issue by renaming PROT_NONE to PROT_TYPE_DUMMY. Link: https://lkml.kernel.org/r/20250519145657.178365-1-lorenzo.stoakes@oracle.com Fixes: b3cefd6bf16e ("KVM: s390: Pass initialized arg even if unused") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Suggested-by: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez@kuka.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505140943.IgHDa9s7-lkp@intel.com/ Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Ignacio Moreno Gonzalez <Ignacio.MorenoGonzalez@kuka.com> Acked-by: Yang Shi <yang@os.amperecomputing.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: <stable@vger.kernel.org> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: James Houghton <jthoughton@google.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05selftests/mm: add test about uprobe pte be orphan during vma mergePu Lehui
Add test about uprobe pte be orphan during vma merge. [akpm@linux-foundation.org: include sys/syscall.h, per Lorenzo] Link: https://lkml.kernel.org/r/20250529155650.4017699-5-pulehui@huaweicloud.com Signed-off-by: Pu Lehui <pulehui@huawei.com> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05selftests/mm: extract read_sysfs and write_sysfs into vm_utilPu Lehui
Extract read_sysfs and write_sysfs into vm_util. Meanwhile, rename the function in thuge-gen that has the same name as read_sysfs. Link: https://lkml.kernel.org/r/20250529155650.4017699-4-pulehui@huaweicloud.com Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm: expose abnormal new_pte during move_ptesPu Lehui
When executing move_ptes, the new_pte must be NULL, otherwise it will be overwritten by the old_pte, and cause the abnormal new_pte to be leaked. In order to make this problem to be more explicit, let's add WARN_ON_ONCE when new_pte is not NULL. [akpm@linux-foundation.org: s/WARN_ON_ONCE/VM_WARN_ON_ONCE/] Link: https://lkml.kernel.org/r/20250529155650.4017699-3-pulehui@huaweicloud.com Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm: fix uprobe pte be overwritten when expanding vmaPu Lehui
Patch series "Fix uprobe pte be overwritten when expanding vma". This patch (of 4): We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1 And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan. Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma. This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/ Link: https://lkml.kernel.org/r/20250529155650.4017699-1-pulehui@huaweicloud.com Link: https://lkml.kernel.org/r/20250529155650.4017699-2-pulehui@huaweicloud.com Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints") Signed-off-by: Pu Lehui <pulehui@huawei.com> Suggested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05mm/damon: s/primitives/code/ on commentsEnze Li
The word 'primitive' is not explicit. To make the code more easily understood, this commit renames 'primitives' to 'code' in header comments of some source files. Link: https://lkml.kernel.org/r/20250530053115.153238-1-lienze@kylinos.cn Signed-off-by: Enze Li <lienze@kylinos.cn> Reviewed-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-06drm/nouveau/vfn/r535: Convert comma to semicolonChen Ni
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Fixes: cd3c62282b61 ("drm/nouveau/gsp: add usermode class id to gpu hal") Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250603061027.1310267-1-nichen@iscas.ac.cn
2025-06-06Merge tag 'amd-drm-fixes-6.16-2025-06-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-6.16-2025-06-05: amdgpu: - IP discovery fix - Cleaner shader fix for GC 10.1.x - OD fix - UserQ fixes - Non-OLED panel fix - Misc display fixes - Brightness fixes amdkfd: - Enable CONFIG_HSA_AMD on RISCV Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250606015932.835829-1-alexander.deucher@amd.com
2025-06-06Merge tag 'drm-xe-next-fixes-2025-06-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - A couple of vm init fixes (Matt Auld) - Hwmon fixes (Karthik) - Drop reduntant conversion to bool (Raag) - Fix CONFIG_INTEL_VSEC dependency (Arnd) - Rework eviction rejection of bound external bos (Thomas) - Stop re-submitting signalled jobs (Matt Auld) - A couple of pxp fixes (Daniele) - Add back a fix that got lost in a merge (Matt Auld) - Create LRC bo without VM (Niranjana) - Fix for the above fix (Maciej) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/aEHq44uIAZwfK-mG@fedora
2025-06-06Merge tag 'drm-misc-next-fixes-2025-06-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-fixes for v6.16-rc1: - Fixes for nt37801 panel - Fix null deref in HDMI audio helper. - Fixes for analogix_dp. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/14c2eff8-701d-4699-b187-08862715e1ac@linux.intel.com
2025-06-05ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()Jeongjun Park
There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking. Fixes: 73f37068d540 ("ptp: support ptp physical/virtual clocks conversion") Signed-off-by: Jeongjun Park <aha310510@gmail.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Link: https://patch.msgid.link/20250520160717.7350-1-aha310510@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>