6.18.7-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 146/198 mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
commit 9814cc832b88bd040fc2a1817c2b5469d0f7e862 upstream.
When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked.
Cleanup the directories under such failures.
--- mm/damon/sysfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
mm/damon/sysfs.c +3 -2
@@ -922,7 +922,7 @@ static int damon_sysfs_context_add_dirs( err =damon_sysfs_context_set_targets (context);if (err) - goto put_attrs_out; + goto rmdir_put_attrs_out; err =damon_sysfs_context_set_schemes (context);if (err)
@@ -932,7 +932,8 @@ static int damon_sysfs_context_add_dirs( put_targets_attrs_out:kobject_put (&context->targets->kobj); context->targets =NULL ; -put_attrs_out: +rmdir_put_attrs_out: +damon_sysfs_attrs_rm_dirs (context->attrs);kobject_put (&context->attrs->kobj); context->attrs =NULL ;return err;
Greg Kroah-Hartman
maintainerPATCH 147/198 LoongArch: Fix PMU counter allocation for mixed-type event groups
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lisa Robinson <[email protected]>
commit a91f86e27087f250a5d9c89bb4a427b9c30fd815 upstream.
When validating a perf event group, validate_group() unconditionally attempts to allocate hardware PMU counters for the leader, sibling events and the new event being added.
This is incorrect for mixed-type groups. If a PERF_TYPE_SOFTWARE event is part of the group, the current code still tries to allocate a hardware PMU counter for it, which can wrongly consume hardware PMU resources and cause spurious allocation failures.
Fix this by only allocating PMU counters for hardware events during group validation, and skipping software events.
A trimmed down reproducer is as simple as this:
#include <stdio.h>
#include <assert.h>
#include <unistd.h>
#include <string.h>
#include <sys/syscall.h>
#include <linux/perf_event.h>
int main (int argc, char *argv[])
{
struct perf_event_attr attr = { 0 };
int fds[5];
attr.disabled = 1;
attr.exclude_kernel = 1;
attr.exclude_hv = 1;
attr.read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
PERF_FORMAT_TOTAL_TIME_RUNNING | PERF_FORMAT_ID | PERF_FORMAT_GROUP;
attr.size = sizeof (attr);
attr.type = PERF_TYPE_SOFTWARE;
attr.config = PERF_COUNT_SW_DUMMY;
fds[0] = syscall (SYS_perf_event_open, &attr, 0, -1, -1, 0);
assert (fds[0] >= 0);
attr.type = PERF_TYPE_HARDWARE;
attr.config = PERF_COUNT_HW_CPU_CYCLES;
fds[1] = syscall (SYS_perf_event_open, &attr, 0, -1, fds[0], 0);
assert (fds[1] >= 0);
attr.type = PERF_TYPE_HARDWARE;
attr.config = PERF_COUNT_HW_INSTRUCTIONS;
fds[2] = syscall (SYS_perf_event_open, &attr, 0, -1, fds[0], 0);
assert (fds[2] >= 0);
attr.type = PERF_TYPE_HARDWARE;
attr.config = PERF_COUNT_HW_BRANCH_MISSES;
fds[3] = syscall (SYS_perf_event_open, &attr, 0, -1, fds[0], 0);
assert (fds[3] >= 0);
attr.type = PERF_TYPE_HARDWARE;
attr.config = PERF_COUNT_HW_CACHE_REFERENCES;
fds[4] = syscall (SYS_perf_event_open, &attr, 0, -1, fds[0], 0);
assert (fds[4] >= 0);
printf ("PASSED\n");
return 0;
}--- arch/loongarch/kernel/perf_event.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
arch/loongarch/kernel/perf_event.c +18 -3
@@ -626,6 +626,18 @@ static const struct loongarch_perf_eventreturn pev; } +static inline bool loongarch_pmu_event_requires_counter (const struct perf_event *event) +{ +switch (event->attr.type) { +case PERF_TYPE_HARDWARE : +case PERF_TYPE_HW_CACHE : +case PERF_TYPE_RAW : +return true; +default : +return false; + } +} +static int validate_group (struct perf_event *event) {struct cpu_hw_events fake_cpuc;
@@ -633,15 +645,18 @@ static int validate_group(struct perf_evmemset (&fake_cpuc,0 ,sizeof (fake_cpuc)); -if (loongarch_pmu_alloc_counter (&fake_cpuc, &leader->hw) <0 ) +if (loongarch_pmu_event_requires_counter (leader) && +loongarch_pmu_alloc_counter (&fake_cpuc, &leader->hw) <0 )return -EINVAL ;for_each_sibling_event (sibling, leader) { -if (loongarch_pmu_alloc_counter (&fake_cpuc, &sibling->hw) <0 ) +if (loongarch_pmu_event_requires_counter (sibling) && +loongarch_pmu_alloc_counter (&fake_cpuc, &sibling->hw) <0 )return -EINVAL ; } -if (loongarch_pmu_alloc_counter (&fake_cpuc, &event->hw) <0 ) +if (loongarch_pmu_event_requires_counter (event) && +loongarch_pmu_alloc_counter (&fake_cpuc, &event->hw) <0 )return -EINVAL ;return 0 ;
Greg Kroah-Hartman
maintainerPATCH 148/198 LoongArch: dts: Describe PCI sideband IRQ through interrupt-extended
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yao Zi <[email protected]>
commit 762cf75bec2ad9d17899087899a34336b1757238 upstream.
SoC integrated peripherals on LS2K1000 and LS2K2000 could be discovered as PCI devices, but require sideband interrupts to function, which are previously described by interrupts and interrupt-parent properties.
However, pci/pci-device.yaml allows interrupts property to only specify PCI INTx interrupts, not sideband ones. Convert these devices to use interrupt-extended property, which describes sideband interrupts used by PCI devices since dt-schema commit e6ea659d2baa ("schemas: pci-device:
Allow interrupts-extended for sideband interrupts"), eliminating dtbs_check warnings.
--- arch/loongarch/boot/dts/loongson-2k1000.dtsi | 25 +++++++-------------- arch/loongarch/boot/dts/loongson-2k2000.dtsi | 32 ++++++++++----------------- 2 files changed, 21 insertions(+), 36 deletions(-)
arch/loongarch/boot/dts/loongson-2k1000.dtsi +9 -16
@@ -437,54 +437,47 @@ gmac0: ethernet@3,0 { reg = <0x1800 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc0>; - interrupts = <12 IRQ_TYPE_LEVEL_HIGH>, - <13 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc0 12 IRQ_TYPE_LEVEL_HIGH>, + <&liointc0 13 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq", "eth_lpi"; status = "disabled"; }; gmac1: ethernet@3,1 { reg = <0x1900 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc0>; - interrupts = <14 IRQ_TYPE_LEVEL_HIGH>, - <15 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc0 14 IRQ_TYPE_LEVEL_HIGH>, + <&liointc0 15 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq", "eth_lpi"; status = "disabled"; }; ehci0: usb@4,1 { reg = <0x2100 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc1>; - interrupts = <18 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc1 18 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; ohci0: usb@4,2 { reg = <0x2200 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc1>; - interrupts = <19 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc1 19 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; display@6,0 { reg = <0x3000 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc0>; - interrupts = <28 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc0 28 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; hda@7,0 { reg = <0x3800 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc0>; - interrupts = <4 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc0 4 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; sata: sata@8,0 { reg = <0x4000 0x0 0x0 0x0 0x0>; - interrupt-parent = <&liointc0>; - interrupts = <19 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&liointc0 19 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; };
arch/loongarch/boot/dts/loongson-2k2000.dtsi +12 -20
@@ -291,65 +291,57 @@ gmac0: ethernet@3,0 { reg = <0x1800 0x0 0x0 0x0 0x0>; - interrupts = <12 IRQ_TYPE_LEVEL_HIGH>, - <13 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&pic 12 IRQ_TYPE_LEVEL_HIGH>, + <&pic 13 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq", "eth_lpi"; - interrupt-parent = <&pic>; status = "disabled"; }; gmac1: ethernet@3,1 { reg = <0x1900 0x0 0x0 0x0 0x0>; - interrupts = <14 IRQ_TYPE_LEVEL_HIGH>, - <15 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&pic 14 IRQ_TYPE_LEVEL_HIGH>, + <&pic 15 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq", "eth_lpi"; - interrupt-parent = <&pic>; status = "disabled"; }; gmac2: ethernet@3,2 { reg = <0x1a00 0x0 0x0 0x0 0x0>; - interrupts = <17 IRQ_TYPE_LEVEL_HIGH>, - <18 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&pic 17 IRQ_TYPE_LEVEL_HIGH>, + <&pic 18 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq", "eth_lpi"; - interrupt-parent = <&pic>; status = "disabled"; }; xhci0: usb@4,0 { reg = <0x2000 0x0 0x0 0x0 0x0>; - interrupts = <48 IRQ_TYPE_LEVEL_HIGH>; - interrupt-parent = <&pic>; + interrupts-extended = <&pic 48 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; xhci1: usb@19,0 { reg = <0xc800 0x0 0x0 0x0 0x0>; - interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; - interrupt-parent = <&pic>; + interrupts-extended = <&pic 22 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; display@6,1 { reg = <0x3100 0x0 0x0 0x0 0x0>; - interrupts = <28 IRQ_TYPE_LEVEL_HIGH>; - interrupt-parent = <&pic>; + interrupts-extended = <&pic 28 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; }; i2s@7,0 { reg = <0x3800 0x0 0x0 0x0 0x0>; - interrupts = <78 IRQ_TYPE_LEVEL_HIGH>, - <79 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended = <&pic 78 IRQ_TYPE_LEVEL_HIGH>, + <&pic 79 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "tx", "rx"; - interrupt-parent = <&pic>; status = "disabled"; }; sata: sata@8,0 { reg = <0x4000 0x0 0x0 0x0 0x0>; - interrupts = <16 IRQ_TYPE_LEVEL_HIGH>; - interrupt-parent = <&pic>; + interrupts-extended = <&pic 16 IRQ_TYPE_LEVEL_HIGH>; status = "disabled"; };
Greg Kroah-Hartman
maintainerPATCH 149/198 drm/amd/display: Bump the HDMI clock to 340MHz
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit fee50077656d8a58011f13bca48f743d1b6d6015 upstream.
[Why]
DP-HDMI dongles can execeed bandwidth requirements on high resolution monitors. This can lead to pruning the high resolution modes.
HDMI 1.3 bumped the clock to 340MHz, but display code never matched it.
[How]
Set default to (DVI) 165MHz. Once HDMI display is identified update to 340MHz.
--- drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h | 2 +- drivers/gpu/drm/amd/display/dc/link/link_detection.c | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h +1 -1
@@ -41,7 +41,7 @@/* kHZ*/ #define DP_ADAPTOR_DVI_MAX_TMDS_CLK 165000/* kHZ*/ -#define DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK 165000 +#define DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK 340000struct dp_hdmi_dongle_signature_data {int8_t id[15 ];/* "DP-HDMI ADAPTOR"*/
drivers/gpu/drm/amd/display/dc/link/link_detection.c +3 -1
@@ -332,7 +332,7 @@ static void query_dp_dual_mode_adaptor(/* Assume we have no valid DP passive dongle connected */ *dongle =DISPLAY_DONGLE_NONE ; - sink_cap->max_hdmi_pixel_clock =DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK ; + sink_cap->max_hdmi_pixel_clock =DP_ADAPTOR_DVI_MAX_TMDS_CLK ;/* Read DP-HDMI dongle I2c (no response interpreted as DP-DVI dongle)*/ if (!i2c_read(
@@ -388,6 +388,8 @@ static void query_dp_dual_mode_adaptor( } } +if (is_valid_hdmi_signature) + sink_cap->max_hdmi_pixel_clock =DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK ;if (is_type2_dongle) { uint32_t max_tmds_clk =
Greg Kroah-Hartman
maintainerPATCH 150/198 drm/amd/display: Initialise backlight level values from hw
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivek Das Mohapatra <[email protected]>
commit 52d3d115e9cc975b90b1fc49abf6d36ad5e8847a upstream.
Internal backlight levels are initialised from ACPI but the values are sometimes out of sync with the levels in effect until there has been a read from hardware (eg triggered by reading from sysfs).
This means that the first drm_commit can cause the levels to be set to a different value than the actual starting one, which results in a sudden change in brightness.
This path shows the problem (when the values are out of sync):
amdgpu_dm_atomic_commit_tail()
-> amdgpu_dm_commit_streams()
-> amdgpu_dm_backlight_set_level(..., dm->brightness[n])
This patch calls the backlight ops get_brightness explicitly at the end of backlight registration to make sure dm->brightness[n] is in sync with the actual hardware levels.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +17 -1
@@ -5193,6 +5193,8 @@ amdgpu_dm_register_backlight_device(strustruct amdgpu_dm_backlight_caps *caps;char bl_name[16 ];int min, max; +int real_brightness; +int init_brightness;if (aconnector->bl_idx ==-1 )return ;
@@ -5217,6 +5219,8 @@ amdgpu_dm_register_backlight_device(stru }else props.brightness = props.max_brightness =MAX_BACKLIGHT_LEVEL ; + init_brightness = props.brightness; +if (caps->data_points && !(amdgpu_dc_debug_mask &DC_DISABLE_CUSTOM_BRIGHTNESS_CURVE )) {drm_info (drm,"Using custom brightness curve\n" ); props.scale =BACKLIGHT_SCALE_NON_LINEAR ;
@@ -5235,8 +5239,20 @@ amdgpu_dm_register_backlight_device(struif (IS_ERR (dm->backlight_dev[aconnector->bl_idx])) {drm_err (drm,"DM: Backlight registration failed!\n" ); dm->backlight_dev[aconnector->bl_idx] =NULL ; - }else + }else { +/* +* dm->brightness[x] can be inconsistent just after startup until +* ops.get_brightness is called. +*/ + real_brightness = + amdgpu_dm_backlight_ops.get_brightness (dm->backlight_dev[aconnector->bl_idx]); + +if (real_brightness != init_brightness) { + dm->actual_brightness[aconnector->bl_idx] = real_brightness; + dm->brightness[aconnector->bl_idx] = real_brightness; + }drm_dbg_driver (drm,"DM: Registered Backlight device: %s\n" , bl_name); + } } static int initialize_plane(struct amdgpu_display_manager *dm,
Greg Kroah-Hartman
maintainerPATCH 151/198 drm/amd: Clean up kfd node on surprise disconnect
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello (AMD) <[email protected]>
commit 28695ca09d326461f8078332aa01db516983e8a2 upstream.
When an eGPU is unplugged the KFD topology should also be destroyed for that GPU. This never happens because the fini_sw callbacks never get to run. Run them manually before calling amdgpu_device_ip_fini_early() when a device has already been disconnected.
This location is intentionally chosen to make sure that the kfd locking refcount doesn't get incremented unintentionally.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +8 -0
@@ -4985,6 +4985,14 @@ void amdgpu_device_fini_hw(struct amdgpuamdgpu_ttm_set_buffer_funcs_status (adev, false); +/* +* device went through surprise hotplug; we need to destroy topology +* before ip_fini_early to prevent kfd locking refcount issues by calling +* amdgpu_amdkfd_suspend() +*/ +if (drm_dev_is_unplugged (adev_to_drm (adev))) +amdgpu_amdkfd_device_fini_sw (adev); +amdgpu_device_ip_fini_early (adev);amdgpu_irq_fini_hw (adev);
Greg Kroah-Hartman
maintainerPATCH 152/198 drm/amdgpu: Fix gfx9 update PTE mtype flag
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Philip Yang <[email protected]>
commit 292e5757b2229c0c6f1d059123a85f8a28f4464d upstream.
Fix copy&paste error, that should have been an assignment instead of an or, otherwise MTYPE_UC 0x3 can not be updated to MTYPE_RW 0x1.
--- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +4 -4
@@ -1233,16 +1233,16 @@ static void gmc_v9_0_get_vm_pte(struct a *flags =AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_NC );break ;case AMDGPU_VM_MTYPE_WC : - *flags |=AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_WC ); + *flags =AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_WC );break ;case AMDGPU_VM_MTYPE_RW : - *flags |=AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_RW ); + *flags =AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_RW );break ;case AMDGPU_VM_MTYPE_CC : - *flags |=AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_CC ); + *flags =AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_CC );break ;case AMDGPU_VM_MTYPE_UC : - *flags |=AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_UC ); + *flags =AMDGPU_PTE_MTYPE_VG10 (*flags,MTYPE_UC );break ; }
Greg Kroah-Hartman
maintainerPATCH 153/198 drm/amdgpu: make sure userqs are enabled in userq IOCTLs
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit b6dff005fcf32dd072f6f2d08ca461394a21bd4f upstream.
These IOCTLs shouldn't be called when userqs are not enabled. Make sure they are enabled before executing the IOCTLs.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 16 ++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 6 ++++++ 3 files changed, 23 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c +16 -0
@@ -681,12 +681,28 @@ static int amdgpu_userq_input_args_validreturn 0 ; } +bool amdgpu_userq_enabled (struct drm_device *dev) +{ +struct amdgpu_device *adev =drm_to_adev (dev); +int i; + +for (i =0 ; i <AMDGPU_HW_IP_NUM ; i++) { +if (adev->userq_funcs[i]) +return true; + } + +return false; +} +int amdgpu_userq_ioctl (struct drm_device *dev,void *data,struct drm_file *filp) {union drm_amdgpu_userq *args = data;int r; +if (!amdgpu_userq_enabled (dev)) +return -ENOTSUPP ; +if (amdgpu_userq_input_args_validate (dev, args, filp) <0 )return -EINVAL ;
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h +1 -0
@@ -135,6 +135,7 @@ uint64_t amdgpu_userq_get_doorbell_index struct drm_file *filp);u32 amdgpu_userq_get_supported_ip_mask (struct amdgpu_device *adev); +bool amdgpu_userq_enabled (struct drm_device *dev);int amdgpu_userq_suspend (struct amdgpu_device *adev);int amdgpu_userq_resume (struct amdgpu_device *adev);
drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c +6 -0
@@ -472,6 +472,9 @@ int amdgpu_userq_signal_ioctl(struct drmstruct drm_exec exec;u64 wptr; +if (!amdgpu_userq_enabled (dev)) +return -ENOTSUPP ; + num_syncobj_handles = args->num_syncobj_handles; syncobj_handles =memdup_user (u64_to_user_ptr (args->syncobj_handles),size_mul (sizeof (u32), num_syncobj_handles));
@@ -654,6 +657,9 @@ int amdgpu_userq_wait_ioctl(struct drm_dint r, i, rentry, wentry, cnt;struct drm_exec exec; +if (!amdgpu_userq_enabled (dev)) +return -ENOTSUPP ; + num_read_bo_handles = wait_info->num_bo_read_handles; bo_handles_read =memdup_user (u64_to_user_ptr (wait_info->bo_read_handles),size_mul (sizeof (u32), num_read_bo_handles));
Greg Kroah-Hartman
maintainerPATCH 154/198 drm/amdkfd: fix a memory leak in device_queue_manager_init()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit 80614c509810fc051312d1a7ccac8d0012d6b8d0 upstream.
If dqm->ops.initialize() fails, add deallocate_hiq_sdma_mqd() to release the memory allocated by allocate_hiq_sdma_mqd(). Move deallocate_hiq_sdma_mqd() up to ensure proper function visibility at the point of use.
--- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 19 ++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c +11 -8
@@ -2905,6 +2905,14 @@ static int allocate_hiq_sdma_mqd(structreturn retval; } +static void deallocate_hiq_sdma_mqd (struct kfd_node *dev, +struct kfd_mem_obj *mqd) +{ +WARN (!mqd,"No hiq sdma mqd trunk to free" ); + +amdgpu_amdkfd_free_gtt_mem (dev->adev, &mqd->gtt_mem); +} +struct device_queue_manager *device_queue_manager_init (struct kfd_node *dev) {struct device_queue_manager *dqm;
@@ -3028,19 +3036,14 @@ struct device_queue_manager *device_queureturn dqm; } +if (!dev->kfd->shared_resources.enable_mes) +deallocate_hiq_sdma_mqd (dev, &dqm->hiq_sdma_mqd); + out_free:kfree (dqm);return NULL ; } -static void deallocate_hiq_sdma_mqd (struct kfd_node *dev, -struct kfd_mem_obj *mqd) -{ -WARN (!mqd,"No hiq sdma mqd trunk to free" ); - -amdgpu_amdkfd_free_gtt_mem (dev->adev, &mqd->gtt_mem); -} -void device_queue_manager_uninit (struct device_queue_manager *dqm) { dqm->ops.stop (dqm);
Greg Kroah-Hartman
maintainerPATCH 155/198 drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lyude Paul <[email protected]>
commit 9e9bc6be0fa0b6b6b73f4f831f3b77716d0a8d9e upstream.
For a while, I've been seeing a strange issue where some (usually not all) of the display DMA channels will suddenly hang, particularly when there is a visible cursor on the screen that is being frequently updated, and especially when said cursor happens to go between two screens. While this brings back lovely memories of fixing Intel Skylake bugs, I would quite like to fix it :).
It turns out the problem that's happening here is that we're managing to reach nv50_head_flush_set() in our atomic commit path without actually holding nv50_disp->mutex. This means that cursor updates happening in parallel (along with any other atomic updates that need to use the core channel) will race with eachother, which eventually causes us to corrupt the pushbuffer - leading to a plethora of various GSP errors, usually:
nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 00000218 00102680 00000004 00800003 nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 0000021c 00040509 00000004 00000001 nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 00000000 00000000 00000001 00000001
The reason this is happening is because generally we check whether we need to set nv50_atom->lock_core at the end of nv50_head_atomic_check(). However, curs507a_prepare is called from the fb_prepare callback, which happens after the atomic check phase. As a result, this can lead to commits that both touch the core channel but also don't grab nv50_disp->mutex.
So, fix this by making sure that we set nv50_atom->lock_core in cus507a_prepare().
--- drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/nouveau/dispnv50/curs507a.c +1 -0
@@ -84,6 +84,7 @@ curs507a_prepare(struct nv50_wndw *wndw, asyh->curs.handle = handle; asyh->curs.offset = offset; asyh->set.curs = asyh->curs.visible; +nv50_atom (asyh->state.state)->lock_core = true; } }
Greg Kroah-Hartman
maintainerPATCH 156/198 drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Vasut <[email protected]>
commit 6ab3d4353bf75005eaa375677c9fed31148154d6 upstream.
The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work:
"
WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8
"
The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.
--- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/panel/panel-simple.c +1 -0
@@ -1900,6 +1900,7 @@ static const struct panel_desc dataimage }, .bus_format = MEDIA_BUS_FMT_RGB888_1X24, .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE, + .connector_type = DRM_MODE_CONNECTOR_DPI, };static const struct display_timing dlc_dlc0700yzg_1_timing = {
Greg Kroah-Hartman
maintainerPATCH 157/198 drm/panel: simple: restore connector_type fallback
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <[email protected]>
commit 9380dc33cd6ae4a6857818fcefce31cf716f3fae upstream.
The switch from devm_kzalloc() + drm_panel_init() to devm_drm_panel_alloc() introduced a regression.
Several panel descriptors do not set connector_type. For those panels, panel_simple_probe() used to compute a connector type (currently DPI as a fallback) and pass that value to drm_panel_init(). After the conversion to devm_drm_panel_alloc(), the call unconditionally used desc->connector_type instead, ignoring the computed fallback and potentially passing DRM_MODE_CONNECTOR_Unknown, which drm_panel_bridge_add() does not allow.
Move the connector_type validation / fallback logic before the devm_drm_panel_alloc() call and pass the computed connector_type to devm_drm_panel_alloc(), so panels without an explicit connector_type once again get the DPI default.
--- drivers/gpu/drm/panel/panel-simple.c | 89 +++++++++++++++++------------------ 1 file changed, 44 insertions(+), 45 deletions(-)
drivers/gpu/drm/panel/panel-simple.c +44 -45
@@ -623,49 +623,6 @@ static struct panel_simple *panel_simpleif (IS_ERR (desc))return ERR_CAST (desc); - panel = devm_drm_panel_alloc(dev, struct panel_simple, base, - &panel_simple_funcs, desc->connector_type); -if (IS_ERR (panel)) -return ERR_CAST (panel); - - panel->desc = desc; - - panel->supply =devm_regulator_get (dev,"power" ); -if (IS_ERR (panel->supply)) -return ERR_CAST (panel->supply); - - panel->enable_gpio =devm_gpiod_get_optional (dev,"enable" , -GPIOD_OUT_LOW ); -if (IS_ERR (panel->enable_gpio)) -return dev_err_cast_probe (dev, panel->enable_gpio, -"failed to request GPIO\n" ); - - err =of_drm_get_panel_orientation (dev->of_node, &panel->orientation); -if (err) { -dev_err (dev,"%pOF: failed to get orientation %d\n" , dev->of_node, err); -return ERR_PTR (err); - } - - ddc =of_parse_phandle (dev->of_node,"ddc-i2c-bus" ,0 ); -if (ddc) { - panel->ddc =of_find_i2c_adapter_by_node (ddc); -of_node_put (ddc); - -if (!panel->ddc) -return ERR_PTR (-EPROBE_DEFER ); - } - -if (!of_device_is_compatible (dev->of_node,"panel-dpi" ) && - !of_get_display_timing (dev->of_node,"panel-timing" , &dt)) -panel_simple_parse_panel_timing_node (dev, panel, &dt); - -if (desc->connector_type ==DRM_MODE_CONNECTOR_LVDS ) { -/* Optional data-mapping property for overriding bus format */ - err =panel_simple_override_nondefault_lvds_datamapping (dev, panel); -if (err) - goto free_ddc; - } - connector_type = desc->connector_type;/* Catch common mistakes for panels. */ switch (connector_type) {
@@ -690,8 +647,7 @@ static struct panel_simple *panel_simplebreak ;case DRM_MODE_CONNECTOR_eDP:dev_warn (dev,"eDP panels moved to panel-edp\n" ); - err = -EINVAL ; - goto free_ddc; +return ERR_PTR (-EINVAL );case DRM_MODE_CONNECTOR_DSI :if (desc->bpc !=6 && desc->bpc !=8 )dev_warn (dev,"Expected bpc in {6,8} but got: %u\n" , desc->bpc);
@@ -720,6 +676,49 @@ static struct panel_simple *panel_simplebreak ; } + panel = devm_drm_panel_alloc(dev, struct panel_simple, base, + &panel_simple_funcs, connector_type); +if (IS_ERR (panel)) +return ERR_CAST (panel); + + panel->desc = desc; + + panel->supply =devm_regulator_get (dev,"power" ); +if (IS_ERR (panel->supply)) +return ERR_CAST (panel->supply); + + panel->enable_gpio =devm_gpiod_get_optional (dev,"enable" , +GPIOD_OUT_LOW ); +if (IS_ERR (panel->enable_gpio)) +return dev_err_cast_probe (dev, panel->enable_gpio, +"failed to request GPIO\n" ); + + err =of_drm_get_panel_orientation (dev->of_node, &panel->orientation); +if (err) { +dev_err (dev,"%pOF: failed to get orientation %d\n" , dev->of_node, err); +return ERR_PTR (err); + } + + ddc =of_parse_phandle (dev->of_node,"ddc-i2c-bus" ,0 ); +if (ddc) { + panel->ddc =of_find_i2c_adapter_by_node (ddc); +of_node_put (ddc); + +if (!panel->ddc) +return ERR_PTR (-EPROBE_DEFER ); + } + +if (!of_device_is_compatible (dev->of_node,"panel-dpi" ) && + !of_get_display_timing (dev->of_node,"panel-timing" , &dt)) +panel_simple_parse_panel_timing_node (dev, panel, &dt); + +if (desc->connector_type ==DRM_MODE_CONNECTOR_LVDS ) { +/* Optional data-mapping property for overriding bus format */ + err =panel_simple_override_nondefault_lvds_datamapping (dev, panel); +if (err) + goto free_ddc; + } +dev_set_drvdata (dev, panel);/*
Greg Kroah-Hartman
maintainerPATCH 158/198 drm/sysfb: Remove duplicate declarations
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit b91a565ed14fcf900b4d95e86882b4b763860986 upstream.
Commit 6046b49bafff ("drm/sysfb: Share helpers for integer validation") and commit e8c086880b2b ("drm/sysfb: Share helpers for screen_info validation") added duplicate function declarations. Remove the latter ones.
--- drivers/gpu/drm/sysfb/drm_sysfb_helper.h | 9 --------- 1 file changed, 9 deletions(-)
drivers/gpu/drm/sysfb/drm_sysfb_helper.h +0 -9
@@ -48,15 +48,6 @@ const struct drm_format_info *drm_sysfb_#endif /* -* Input parsing -*/ - -int drm_sysfb_get_validated_int (struct drm_device *dev,const char *name, -u64 value,u32 max); -int drm_sysfb_get_validated_int0 (struct drm_device *dev,const char *name, -u64 value,u32 max); - -/* * Display modes */
Greg Kroah-Hartman
maintainerPATCH 159/198 drm/vmwgfx: Fix an error return check in vmw_compat_shader_add()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit bf72b4b7bb7dbb643d204fa41e7463894a95999f upstream.
In vmw_compat_shader_add(), the return value check of vmw_shader_alloc() is not proper. Modify the check for the return pointer 'res'.
Found by code review and compiled on ubuntu 20.04.
--- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c +3 -1
@@ -923,8 +923,10 @@ int vmw_compat_shader_add(struct vmw_prittm_bo_unreserve (&buf->tbo); res =vmw_shader_alloc (dev_priv, buf, size,0 , shader_type); -if (unlikely (ret !=0 )) +if (IS_ERR (res)) { + ret =PTR_ERR (res); goto no_reserve; + } ret = vmw_cmdbuf_res_add(man, vmw_cmdbuf_res_shader, vmw_shader_key(user_key, shader_type),
Greg Kroah-Hartman
maintainerPATCH 160/198 LoongArch: dts: loongson-2k0500: Add default interrupt controller address cells
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Binbin Zhou <[email protected]>
commit c4461754e6fe7e12a3ff198cce4707e3e20e43d4 upstream.
Add missing address-cells 0 to the Local I/O and Extend I/O interrupt controller node to silence W=1 warning:
loongson-2k0500.dtsi:513.5-51: Warning (interrupt_map): /bus@10000000/pcie@1a000000/pcie@0,0:interrupt-map:
Missing property '#address-cells' in node /bus@10000000/interrupt-controller@1fe11600, using 0 as fallback
Value '0' is correct because:
1. The Local I/O & Extend I/O interrupt controller do not have children,
2. interrupt-map property (in PCI node) consists of five components and the fourth component "parent unit address", which size is defined by '#address-cells' of the node pointed to by the interrupt-parent component, is not used (=0)
--- arch/loongarch/boot/dts/loongson-2k0500.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/loongarch/boot/dts/loongson-2k0500.dtsi +3 -0
@@ -131,6 +131,7 @@ reg-names = "main", "isr0"; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <2>; interrupt-parent = <&cpuintc>; interrupts = <2>;
@@ -149,6 +150,7 @@ reg-names = "main", "isr0"; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <2>; interrupt-parent = <&cpuintc>; interrupts = <4>;
@@ -164,6 +166,7 @@ compatible = "loongson,ls2k0500-eiointc"; reg = <0x0 0x1fe11600 0x0 0xea00>; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <1>; interrupt-parent = <&cpuintc>; interrupts = <3>;
Greg Kroah-Hartman
maintainerPATCH 161/198 LoongArch: dts: loongson-2k1000: Add default interrupt controller address cells
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Binbin Zhou <[email protected]>
commit 81e8cb7e504a5adbcc48f7f954bf3c2aa9b417f8 upstream.
Add missing address-cells 0 to the Local I/O interrupt controller node to silence W=1 warning:
loongson-2k1000.dtsi:498.5-55: Warning (interrupt_map): /bus@10000000/pcie@1a000000/pcie@9,0:interrupt-map:
Missing property '#address-cells' in node /bus@10000000/interrupt-controller@1fe01440, using 0 as fallback
Value '0' is correct because:
1. The Local I/O interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and the fourth component "parent unit address", which size is defined by '#address-cells' of the node pointed to by the interrupt-parent component, is not used (=0)
--- arch/loongarch/boot/dts/loongson-2k1000.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/loongarch/boot/dts/loongson-2k1000.dtsi +2 -0
@@ -114,6 +114,7 @@ <0x0 0x1fe01140 0x0 0x8>; reg-names = "main", "isr0", "isr1"; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <2>; interrupt-parent = <&cpuintc>; interrupts = <2>;
@@ -131,6 +132,7 @@ <0x0 0x1fe01148 0x0 0x8>; reg-names = "main", "isr0", "isr1"; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <2>; interrupt-parent = <&cpuintc>; interrupts = <3>;
Greg Kroah-Hartman
maintainerPATCH 162/198 LoongArch: dts: loongson-2k1000: Fix i2c-gpio node names
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Binbin Zhou <[email protected]>
commit 14ea5a3625881d79f75418c66e3a7d98db8518e1 upstream.
The binding wants the node to be named "i2c-number", but those are named "i2c-gpio-number" instead.
Thus rename those to i2c-0, i2c-1 to adhere to the binding and suppress dtbs_check warnings.
--- arch/loongarch/boot/dts/loongson-2k1000.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/loongarch/boot/dts/loongson-2k1000.dtsi +2 -2
@@ -46,7 +46,7 @@ }; /* i2c of the dvi eeprom edid */ - i2c-gpio-0 { + i2c-0 { compatible = "i2c-gpio"; scl-gpios = <&gpio0 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; sda-gpios = <&gpio0 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
@@ -57,7 +57,7 @@ }; /* i2c of the eeprom edid */ - i2c-gpio-1 { + i2c-1 { compatible = "i2c-gpio"; scl-gpios = <&gpio0 33 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; sda-gpios = <&gpio0 32 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
Greg Kroah-Hartman
maintainerPATCH 163/198 LoongArch: dts: loongson-2k2000: Add default interrupt controller address cells
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Binbin Zhou <[email protected]>
commit e65df3f77ecd59d3a8647d19df82b22a6ce210a9 upstream.
Add missing address-cells 0 to the Local I/O, Extend I/O and PCH-PIC Interrupt Controller node to silence W=1 warning:
loongson-2k2000.dtsi:364.5-49: Warning (interrupt_map): /bus@10000000/pcie@1a000000/pcie@9,0:interrupt-map:
Missing property '#address-cells' in node /bus@10000000/interrupt-controller@10000000, using 0 as fallback
Value '0' is correct because:
1. The LIO/EIO/PCH interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and the fourth component "parent unit address", which size is defined by '#address-cells' of the node pointed to by the interrupt-parent component, is not used (=0)
--- arch/loongarch/boot/dts/loongson-2k2000.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/loongarch/boot/dts/loongson-2k2000.dtsi +3 -0
@@ -126,6 +126,7 @@ reg = <0x0 0x1fe01400 0x0 0x64>; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <2>; interrupt-parent = <&cpuintc>; interrupts = <2>;
@@ -140,6 +141,7 @@ compatible = "loongson,ls2k2000-eiointc"; reg = <0x0 0x1fe01600 0x0 0xea00>; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <1>; interrupt-parent = <&cpuintc>; interrupts = <3>;
@@ -149,6 +151,7 @@ compatible = "loongson,pch-pic-1.0"; reg = <0x0 0x10000000 0x0 0x400>; interrupt-controller; + #address-cells = <0>; #interrupt-cells = <2>; loongson,pic-base-vec = <0>; interrupt-parent = <&eiointc>;
Greg Kroah-Hartman
maintainerPATCH 164/198 LoongArch: KVM: Fix kvm_device leak in kvm_eiointc_destroy()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiang Ma <[email protected]>
commit 7d8553fc75aefa7ec936af0cf8443ff90b51732e upstream.
In kvm_ioctl_create_device(), kvm_device has allocated memory, kvm_device->destroy() seems to be supposed to free its kvm_device struct, but kvm_eiointc_destroy() is not currently doing this, that would lead to a memory leak.
So, fix it.
--- arch/loongarch/kvm/intc/eiointc.c | 1 + 1 file changed, 1 insertion(+)
arch/loongarch/kvm/intc/eiointc.c +1 -0
@@ -679,6 +679,7 @@ static void kvm_eiointc_destroy(struct kkvm_io_bus_unregister_dev (kvm,KVM_IOCSR_BUS , &eiointc->device);kvm_io_bus_unregister_dev (kvm,KVM_IOCSR_BUS , &eiointc->device_vext);kfree (eiointc); +kfree (dev); }static struct kvm_device_ops kvm_eiointc_dev_ops = {
Greg Kroah-Hartman
maintainerPATCH 165/198 LoongArch: KVM: Fix kvm_device leak in kvm_ipi_destroy()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiang Ma <[email protected]>
commit 0bf58cb7288a4d3de6d8ecbb3a65928a9362bf21 upstream.
In kvm_ioctl_create_device(), kvm_device has allocated memory, kvm_device->destroy() seems to be supposed to free its kvm_device struct, but kvm_ipi_destroy() is not currently doing this, that would lead to a memory leak.
So, fix it.
--- arch/loongarch/kvm/intc/ipi.c | 1 + 1 file changed, 1 insertion(+)
arch/loongarch/kvm/intc/ipi.c +1 -0
@@ -459,6 +459,7 @@ static void kvm_ipi_destroy(struct kvm_d ipi = kvm->arch.ipi;kvm_io_bus_unregister_dev (kvm,KVM_IOCSR_BUS , &ipi->device);kfree (ipi); +kfree (dev); }static struct kvm_device_ops kvm_ipi_dev_ops = {
Greg Kroah-Hartman
maintainerPATCH 166/198 LoongArch: KVM: Fix kvm_device leak in kvm_pch_pic_destroy()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiang Ma <[email protected]>
commit 1cf342a7c3adc5877837b53bbceb5cc9eff60bbf upstream.
In kvm_ioctl_create_device(), kvm_device has allocated memory, kvm_device->destroy() seems to be supposed to free its kvm_device struct, but kvm_pch_pic_destroy() is not currently doing this, that would lead to a memory leak.
So, fix it.
--- arch/loongarch/kvm/intc/pch_pic.c | 1 + 1 file changed, 1 insertion(+)
arch/loongarch/kvm/intc/pch_pic.c +1 -0
@@ -475,6 +475,7 @@ static void kvm_pch_pic_destroy(struct k/* unregister pch pic device and free it's memory */ kvm_io_bus_unregister_dev (kvm,KVM_MMIO_BUS , &s->device);kfree (s); +kfree (dev); }static struct kvm_device_ops kvm_pch_pic_dev_ops = {
Greg Kroah-Hartman
maintainerPATCH 167/198 dmaengine: apple-admac: Add "apple,t8103-admac" compatible
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Janne Grunau <[email protected]>
commit 76cba1e60b69c9cd53b9127d017a7dc5945455b1 upstream.
After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,admac" anymore [1]. Use "apple,t8103-admac" as base compatible as it is the SoC the driver and bindings were written for.
[1]: https://lore.kernel.org/asahi/[email protected]/
--- drivers/dma/apple-admac.c | 1 + 1 file changed, 1 insertion(+)
drivers/dma/apple-admac.c +1 -0
@@ -936,6 +936,7 @@ static void admac_remove(struct platform }static const struct of_device_id admac_of_match[] = { + { .compatible ="apple,t8103-admac" , }, { .compatible ="apple,admac" , }, { } };
Greg Kroah-Hartman
maintainerPATCH 168/198 dmaengine: at_hdmac: fix device leak on of_dma_xlate()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit b9074b2d7a230b6e28caa23165e9d8bc0677d333 upstream.
Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources.
Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.
--- drivers/dma/at_hdmac.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/dma/at_hdmac.c +7 -2
@@ -1765,6 +1765,7 @@ static int atc_alloc_chan_resources(strustatic void atc_free_chan_resources (struct dma_chan *chan) {struct at_dma_chan *atchan =to_at_dma_chan (chan); +struct at_dma_slave *atslave;BUG_ON (atc_chan_is_enabled (atchan));
@@ -1774,8 +1775,12 @@ static void atc_free_chan_resources(stru/* * Free atslave allocated in at_dma_xlate() */ -kfree (chan->private); - chan->private =NULL ; + atslave = chan->private; +if (atslave) { +put_device (atslave->dma_dev); +kfree (atslave); + chan->private =NULL ; + }dev_vdbg (chan2dev (chan),"free_chan_resources: done\n" ); }
Greg Kroah-Hartman
maintainerPATCH 169/198 dmaengine: bcm-sba-raid: fix device leak on probe
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 7c3a46ebf15a9796b763a54272407fdbf945bed8 upstream.
Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.
--- drivers/dma/bcm-sba-raid.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/dma/bcm-sba-raid.c +5 -1
@@ -1699,7 +1699,7 @@ static int sba_probe(struct platform_dev/* Prealloc channel resource */ ret =sba_prealloc_channel_resources (sba);if (ret) - goto fail_free_mchan; + goto fail_put_mbox;/* Check availability of debugfs */ if (!debugfs_initialized ())
@@ -1729,6 +1729,8 @@ skip_debugfs: fail_free_resources:debugfs_remove_recursive (sba->root);sba_freeup_channel_resources (sba); +fail_put_mbox: +put_device (sba->mbox_dev); fail_free_mchan:mbox_free_channel (sba->mchan);return ret;
@@ -1744,6 +1746,8 @@ static void sba_remove(struct platform_dsba_freeup_channel_resources (sba); +put_device (sba->mbox_dev); +mbox_free_channel (sba->mchan); }
Greg Kroah-Hartman
maintainerPATCH 170/198 dmaengine: cv1800b-dmamux: fix device leak on route allocation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 7bb7d696e0361bbfc1411462c784998cca0afcbb upstream.
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
--- drivers/dma/cv1800b-dmamux.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
drivers/dma/cv1800b-dmamux.c +10 -7
@@ -102,11 +102,11 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,struct llist_node *node;unsigned long flags;unsigned int chid, devid, cpuid; -int ret; +int ret = -EINVAL ;if (dma_spec->args_count !=DMAMUX_NCELLS ) {dev_err (&pdev->dev,"invalid number of dma mux args\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; } devid = dma_spec->args[0 ];
@@ -115,18 +115,18 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,if (devid >MAX_DMA_MAPPING_ID ) {dev_err (&pdev->dev,"invalid device id: %u\n" , devid); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }if (cpuid >MAX_DMA_CPU_ID ) {dev_err (&pdev->dev,"invalid cpu id: %u\n" , cpuid); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; } dma_spec->np =of_parse_phandle (ofdma->of_node,"dma-masters" ,0 );if (!dma_spec->np) {dev_err (&pdev->dev,"can't get dma master\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }spin_lock_irqsave (&dmamux->lock, flags);
@@ -136,8 +136,6 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,if (map->peripheral == devid && map->cpu == cpuid) goto found; } - - ret = -EINVAL ; goto failed; }else { node =llist_del_first (&dmamux->free_maps);
@@ -171,12 +169,17 @@ static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,dev_dbg (&pdev->dev,"register channel %u for req %u (cpu %u)\n" , chid, devid, cpuid); +put_device (&pdev->dev); +return map; failed:spin_unlock_irqrestore (&dmamux->lock, flags);of_node_put (dma_spec->np);dev_err (&pdev->dev,"errno %d\n" , ret); +err_put_pdev: +put_device (&pdev->dev); +return ERR_PTR (ret); }
Signature · 1 line
2.52.0
Greg Kroah-Hartman
maintainerPATCH 171/198 dmaengine: dw: dmamux: fix OF node leak on route allocation failure
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit ec25e60f9f95464aa11411db31d0906b3fb7b9f2 upstream.
Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.
--- drivers/dma/dw/rzn1-dmamux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/dma/dw/rzn1-dmamux.c +3 -1
@@ -90,7 +90,7 @@ static void *rzn1_dmamux_route_allocate(if (test_and_set_bit (map->req_idx, dmamux->used_chans)) { ret = -EBUSY ; - goto free_map; + goto put_dma_spec_np; } mask =BIT (map->req_idx);
@@ -103,6 +103,8 @@ static void *rzn1_dmamux_route_allocate( clear_bitmap:clear_bit (map->req_idx, dmamux->used_chans); +put_dma_spec_np: +of_node_put (dma_spec->np); free_map:kfree (map); put_device:
Greg Kroah-Hartman
maintainerPATCH 172/198 dmaengine: fsl-edma: Fix clk leak on alloc_chan_resources failure
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhen Ni <[email protected]>
commit b18cd8b210417f90537d914ffb96e390c85a7379 upstream.
When fsl_edma_alloc_chan_resources() fails after clk_prepare_enable(), the error paths only free IRQs and destroy the TCD pool, but forget to call clk_disable_unprepare(). This causes the channel clock to remain enabled, leaking power and resources.
Fix it by disabling the channel clock in the error unwind path.
--- drivers/dma/fsl-edma-common.c | 1 + 1 file changed, 1 insertion(+)
drivers/dma/fsl-edma-common.c +1 -0
@@ -852,6 +852,7 @@ err_errirq:free_irq (fsl_chan->txirq, fsl_chan); err_txirq:dma_pool_destroy (fsl_chan->tcd_pool); +clk_disable_unprepare (fsl_chan->clk);return ret; }
Greg Kroah-Hartman
maintainerPATCH 173/198 dmaengine: idxd: fix device leaks on compat bind and unbind
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 799900f01792cf8b525a44764f065f83fcafd468 upstream.
Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.
--- drivers/dma/idxd/compat.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
drivers/dma/idxd/compat.c +19 -4
@@ -20,11 +20,16 @@ static ssize_t unbind_store(struct devicint rc = -ENODEV ; dev =bus_find_device_by_name (bus,NULL , buf); -if (dev && dev->driver) { +if (!dev) +return -ENODEV ; + +if (dev->driver) {device_driver_detach (dev); rc = count; } +put_device (dev); +return rc; } static DRIVER_ATTR_IGNORE_LOCKDEP(unbind, 0200, NULL, unbind_store);
@@ -38,9 +43,12 @@ static ssize_t bind_store(struct device_struct idxd_dev *idxd_dev; dev =bus_find_device_by_name (bus,NULL , buf); -if (!dev || dev->driver || drv != &dsa_drv.drv) +if (!dev)return -ENODEV ; +if (dev->driver || drv != &dsa_drv.drv) + goto err_put_dev; + idxd_dev =confdev_to_idxd_dev (dev);if (is_idxd_dev (idxd_dev)) { alt_drv =driver_find ("idxd" , bus);
@@ -53,13 +61,20 @@ static ssize_t bind_store(struct device_ alt_drv =driver_find ("user" , bus); }if (!alt_drv) -return -ENODEV ; + goto err_put_dev; rc =device_driver_attach (alt_drv, dev);if (rc <0 ) -return rc; + goto err_put_dev; + +put_device (dev);return count; + +err_put_dev: +put_device (dev); + +return rc; } static DRIVER_ATTR_IGNORE_LOCKDEP(bind, 0200, NULL, bind_store);
Greg Kroah-Hartman
maintainerPATCH 174/198 dmaengine: lpc18xx-dmamux: fix device leak on route allocation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit d4d63059dee7e7cae0c4d9a532ed558bc90efb55 upstream.
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
--- drivers/dma/lpc18xx-dmamux.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/dma/lpc18xx-dmamux.c +14 -5
@@ -57,30 +57,31 @@ static void *lpc18xx_dmamux_reserve(strustruct lpc18xx_dmamux_data *dmamux =platform_get_drvdata (pdev);unsigned long flags;unsigned mux; +int ret = -EINVAL ;if (dma_spec->args_count !=3 ) {dev_err (&pdev->dev,"invalid number of dma mux args\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; } mux = dma_spec->args[0 ];if (mux >= dmamux->dma_master_requests) {dev_err (&pdev->dev,"invalid mux number: %d\n" , dma_spec->args[0 ]); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }if (dma_spec->args[1 ] >LPC18XX_DMAMUX_MAX_VAL ) {dev_err (&pdev->dev,"invalid dma mux value: %d\n" , dma_spec->args[1 ]); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }/* The of_node_put() will be done in the core for the node */ dma_spec->np =of_parse_phandle (ofdma->of_node,"dma-masters" ,0 );if (!dma_spec->np) {dev_err (&pdev->dev,"can't get dma master\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }spin_lock_irqsave (&dmamux->lock, flags);
@@ -89,7 +90,8 @@ static void *lpc18xx_dmamux_reserve(strudev_err (&pdev->dev,"dma request %u busy with %u.%u\n" , mux, mux, dmamux->muxes[mux].value);of_node_put (dma_spec->np); -return ERR_PTR (-EBUSY ); + ret = -EBUSY ; + goto err_put_pdev; } dmamux->muxes[mux].busy = true;
@@ -106,7 +108,14 @@ static void *lpc18xx_dmamux_reserve(strudev_dbg (&pdev->dev,"mapping dmamux %u.%u to dma request %u\n" , mux, dmamux->muxes[mux].value, mux); +put_device (&pdev->dev); +return &dmamux->muxes[mux]; + +err_put_pdev: +put_device (&pdev->dev); + +return ERR_PTR (ret); }static int lpc18xx_dmamux_probe (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 175/198 dmaengine: lpc32xx-dmamux: fix device leak on route allocation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit d9847e6d1d91462890ba297f7888fa598d47e76e upstream.
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
--- drivers/dma/lpc32xx-dmamux.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/dma/lpc32xx-dmamux.c +14 -5
@@ -95,11 +95,12 @@ static void *lpc32xx_dmamux_reserve(strustruct lpc32xx_dmamux_data *dmamux =platform_get_drvdata (pdev);unsigned long flags;struct lpc32xx_dmamux *mux =NULL ; +int ret = -EINVAL ;int i;if (dma_spec->args_count !=3 ) {dev_err (&pdev->dev,"invalid number of dma mux args\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }for (i =0 ; i <ARRAY_SIZE (lpc32xx_muxes); i++) {
@@ -111,20 +112,20 @@ static void *lpc32xx_dmamux_reserve(struif (!mux) {dev_err (&pdev->dev,"invalid mux request number: %d\n" , dma_spec->args[0 ]); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }if (dma_spec->args[2 ] >1 ) {dev_err (&pdev->dev,"invalid dma mux value: %d\n" , dma_spec->args[1 ]); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }/* The of_node_put() will be done in the core for the node */ dma_spec->np =of_parse_phandle (ofdma->of_node,"dma-masters" ,0 );if (!dma_spec->np) {dev_err (&pdev->dev,"can't get dma master\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }spin_lock_irqsave (&dmamux->lock, flags);
@@ -133,7 +134,8 @@ static void *lpc32xx_dmamux_reserve(strudev_err (dev,"dma request signal %d busy, routed to %s\n" , mux->signal, mux->muxval ? mux->name_sel1 : mux->name_sel1);of_node_put (dma_spec->np); -return ERR_PTR (-EBUSY ); + ret = -EBUSY ; + goto err_put_pdev; } mux->busy = true;
@@ -148,7 +150,14 @@ static void *lpc32xx_dmamux_reserve(strudev_dbg (dev,"dma request signal %d routed to %s\n" , mux->signal, mux->muxval ? mux->name_sel1 : mux->name_sel1); +put_device (&pdev->dev); +return mux; + +err_put_pdev: +put_device (&pdev->dev); + +return ERR_PTR (ret); }static int lpc32xx_dmamux_probe (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 176/198 dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
commit 3f747004bbd641131d9396d87b5d2d3d1e182728 upstream.
Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails.
The issue occurs when:
1. gchan->config points to previously allocated memory
2. krealloc() fails and returns NULL
3. The function directly assigns NULL to gchan->config, losing the reference to the original memory
4. The original memory becomes unreachable and cannot be freed
Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds.
Found via static analysis and code review.
--- drivers/dma/qcom/gpi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/dma/qcom/gpi.c +4 -2
@@ -1605,14 +1605,16 @@ static int gpi_peripheral_config(struct dma_chan *chan, struct dma_slave_config *config) { struct gchan *gchan = to_gchan(chan); +void *new_config;if (!config->peripheral_config)return -EINVAL ; - gchan->config =krealloc (gchan->config, config->peripheral_size,GFP_NOWAIT ); -if (!gchan->config) + new_config =krealloc (gchan->config, config->peripheral_size,GFP_NOWAIT ); +if (!new_config)return -ENOMEM ; + gchan->config = new_config;memcpy (gchan->config, config->peripheral_config, config->peripheral_size);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 177/198 dmaengine: sh: rz-dmac: fix device leak on probe failure
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 9fb490323997dcb6f749cd2660a17a39854600cd upstream.
Make sure to drop the reference taken when looking up the ICU device during probe also on probe failures (e.g. probe deferral).
--- drivers/dma/sh/rz-dmac.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/dma/sh/rz-dmac.c +11 -2
@@ -854,6 +854,13 @@ static int rz_dmac_chan_probe(struct rz_return 0 ; } +static void rz_dmac_put_device (void *_dev) +{ +struct device *dev = _dev; + +put_device (dev); +} +static int rz_dmac_parse_of_icu (struct device *dev,struct rz_dmac *dmac) {struct device_node *np = dev->of_node;
@@ -876,6 +883,10 @@ static int rz_dmac_parse_of_icu(struct dreturn -ENODEV ; } + ret =devm_add_action_or_reset (dev, rz_dmac_put_device, &dmac->icu.pdev->dev); +if (ret) +return ret; + dmac_index = args.args[0 ];if (dmac_index >RZV2H_MAX_DMAC_INDEX ) {dev_err (dev,"DMAC index %u invalid.\n" , dmac_index);
@@ -1055,8 +1066,6 @@ static void rz_dmac_remove(struct platforeset_control_assert (dmac->rstc);pm_runtime_put (&pdev->dev);pm_runtime_disable (&pdev->dev); - -platform_device_put (dmac->icu.pdev); }static const struct of_device_id of_rz_dmac_match[] = {
Greg Kroah-Hartman
maintainerPATCH 178/198 dmaengine: sh: rz-dmac: Fix rz_dmac_terminate_all()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Biju Das <[email protected]>
commit 747213b08a1ab6a76e3e3b3e7a209cc1d402b5d0 upstream.
After audio full duplex testing, playing the recorded file contains a few playback frames from the previous time. The rz_dmac_terminate_all() does not reset all the hardware descriptors queued previously, leading to the wrong descriptor being picked up during the next DMA transfer. Fix the above issue by resetting all the descriptor headers for a channel in rz_dmac_terminate_all() as rz_dmac_lmdesc_recycle() points to the proper descriptor header filled by the rz_dmac_prepare_descs_for_slave_sg().
--- drivers/dma/sh/rz-dmac.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/dma/sh/rz-dmac.c +5 -0
@@ -557,11 +557,16 @@ rz_dmac_prep_slave_sg(struct dma_chan *cstatic int rz_dmac_terminate_all (struct dma_chan *chan) {struct rz_dmac_chan *channel =to_rz_dmac_chan (chan); +struct rz_lmdesc *lmdesc = channel->lmdesc.base;unsigned long flags; +unsigned int i;LIST_HEAD (head);rz_dmac_disable_hw (channel);spin_lock_irqsave (&channel->vc.lock, flags); +for (i =0 ; i <DMAC_NR_LMDESC ; i++) + lmdesc[i].header =0 ; +list_splice_tail_init (&channel->ld_active, &channel->ld_free);list_splice_tail_init (&channel->ld_queue, &channel->ld_free);vchan_get_all_descriptors (&channel->vc, &head);
Greg Kroah-Hartman
maintainerPATCH 179/198 dmaengine: stm32: dmamux: fix device leak on route allocation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit dd6e4943889fb354efa3f700e42739da9bddb6ef upstream.
Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.
Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
--- drivers/dma/stm32/stm32-dmamux.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
drivers/dma/stm32/stm32-dmamux.c +12 -6
@@ -90,23 +90,25 @@ static void *stm32_dmamux_route_allocatestruct stm32_dmamux_data *dmamux =platform_get_drvdata (pdev);struct stm32_dmamux *mux;u32 i, min, max; -int ret; +int ret = -EINVAL ;unsigned long flags;if (dma_spec->args_count !=3 ) {dev_err (&pdev->dev,"invalid number of dma mux args\n" ); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; }if (dma_spec->args[0 ] > dmamux->dmamux_requests) {dev_err (&pdev->dev,"invalid mux request number: %d\n" , dma_spec->args[0 ]); -return ERR_PTR (-EINVAL ); + goto err_put_pdev; } mux =kzalloc (sizeof (*mux),GFP_KERNEL ); -if (!mux) -return ERR_PTR (-ENOMEM ); +if (!mux) { + ret = -ENOMEM ; + goto err_put_pdev; + }spin_lock_irqsave (&dmamux->lock, flags); mux->chan_id = find_first_zero_bit(dmamux->dma_inuse,
@@ -133,7 +135,6 @@ static void *stm32_dmamux_route_allocate dma_spec->np =of_parse_phandle (ofdma->of_node,"dma-masters" , i -1 );if (!dma_spec->np) {dev_err (&pdev->dev,"can't get dma master\n" ); - ret = -EINVAL ; goto error; }
@@ -160,6 +161,8 @@ static void *stm32_dmamux_route_allocatedev_dbg (&pdev->dev,"Mapping DMAMUX(%u) to DMA%u(%u)\n" , mux->request, mux->master, mux->chan_id); +put_device (&pdev->dev); +return mux; error:
@@ -167,6 +170,9 @@ error: error_chan_id:kfree (mux); +err_put_pdev: +put_device (&pdev->dev); +return ERR_PTR (ret); }
Greg Kroah-Hartman
maintainerPATCH 180/198 dmaengine: stm32: dmamux: fix OF node leak on route allocation failure
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit b1b590a590af13ded598e70f0b72bc1e515787a1 upstream.
Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.
--- drivers/dma/stm32/stm32-dmamux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/dma/stm32/stm32-dmamux.c +3 -1
@@ -143,7 +143,7 @@ static void *stm32_dmamux_route_allocate ret =pm_runtime_resume_and_get (&pdev->dev);if (ret <0 ) {spin_unlock_irqrestore (&dmamux->lock, flags); - goto error; + goto err_put_dma_spec_np; }spin_unlock_irqrestore (&dmamux->lock, flags);
@@ -165,6 +165,8 @@ static void *stm32_dmamux_route_allocatereturn mux; +err_put_dma_spec_np: +of_node_put (dma_spec->np); error:clear_bit (mux->chan_id, dmamux->dma_inuse);
Greg Kroah-Hartman
maintainerPATCH 181/198 dmaengine: ti: dma-crossbar: fix device leak on dra7x route allocation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit dc7e44db01fc2498644e3106db3e62a9883a93d5 upstream.
Make sure to drop the reference taken when looking up the crossbar platform device during dra7x route allocation.
Note that commit 615a4bfc426e ("dmaengine: ti: Add missing put_device in ti_dra7_xbar_route_allocate") fixed the leak in the error paths but the reference is still leaking on successful allocation.
--- drivers/dma/ti/dma-crossbar.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/dma/ti/dma-crossbar.c +2 -0
@@ -288,6 +288,8 @@ static void *ti_dra7_xbar_route_allocateti_dra7_xbar_write (xbar->iomem, map->xbar_out, map->xbar_in); +put_device (&pdev->dev); +return map; }
Greg Kroah-Hartman
maintainerPATCH 182/198 dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 4fc17b1c6d2e04ad13fd6c21cfbac68043ec03f9 upstream.
Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.
--- drivers/dma/ti/dma-crossbar.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/dma/ti/dma-crossbar.c +10 -6
@@ -79,34 +79,35 @@ static void *ti_am335x_xbar_route_alloca {struct platform_device *pdev =of_find_device_by_node (ofdma->of_node);struct ti_am335x_xbar_data *xbar =platform_get_drvdata (pdev); -struct ti_am335x_xbar_map *map; +struct ti_am335x_xbar_map *map =ERR_PTR (-EINVAL );if (dma_spec->args_count !=3 ) -return ERR_PTR (-EINVAL ); + goto out_put_pdev;if (dma_spec->args[2 ] >= xbar->xbar_events) {dev_err (&pdev->dev,"Invalid XBAR event number: %d\n" , dma_spec->args[2 ]); -return ERR_PTR (-EINVAL ); + goto out_put_pdev; }if (dma_spec->args[0 ] >= xbar->dma_requests) {dev_err (&pdev->dev,"Invalid DMA request line number: %d\n" , dma_spec->args[0 ]); -return ERR_PTR (-EINVAL ); + goto out_put_pdev; }/* The of_node_put() will be done in the core for the node */ dma_spec->np =of_parse_phandle (ofdma->of_node,"dma-masters" ,0 );if (!dma_spec->np) {dev_err (&pdev->dev,"Can't get DMA master\n" ); -return ERR_PTR (-EINVAL ); + goto out_put_pdev; } map =kzalloc (sizeof (*map),GFP_KERNEL );if (!map) {of_node_put (dma_spec->np); -return ERR_PTR (-ENOMEM ); + map =ERR_PTR (-ENOMEM ); + goto out_put_pdev; } map->dma_line = (u16 )dma_spec->args[0 ];
@@ -120,6 +121,9 @@ static void *ti_am335x_xbar_route_allocati_am335x_xbar_write (xbar->iomem, map->dma_line, map->mux_val); +out_put_pdev: +put_device (&pdev->dev); +return map; }
Greg Kroah-Hartman
maintainerPATCH 183/198 dmaengine: ti: k3-udma: fix device leak on udma lookup
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 430f7803b69cd5e5694e5dfc884c6628870af36e upstream.
Make sure to drop the reference taken when looking up the UDMA platform device.
Note that holding a reference to a platform device does not prevent its driver data from going away so there is no point in keeping the reference after the lookup helper returns.
--- drivers/dma/ti/k3-udma-private.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/ti/k3-udma-private.c +1 -1
@@ -42,9 +42,9 @@ struct udma_dev *of_xudma_dev_get(struct } ud =platform_get_drvdata (pdev); +put_device (&pdev->dev);if (!ud) {pr_debug ("UDMA has not been probed\n" ); -put_device (&pdev->dev);return ERR_PTR (-EPROBE_DEFER ); }
Greg Kroah-Hartman
maintainerPATCH 184/198 mm: add a ptdesc flag to mark kernel page tables
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <[email protected]>
commit 27bfafac65d87c58639f5d7af1353ec1e7886963 upstream.
The page tables used to map the kernel and userspace often have very different handling rules. There are frequently *_kernel() variants of functions just for kernel page tables. That's not great and has lead to code duplication.
Instead of having completely separate call paths, allow a 'ptdesc' to be marked as being for kernel mappings. Introduce helpers to set and clear this status.
Note: this uses the PG_referenced bit. Page flags are a great fit for this since it is truly a single bit of information. Use PG_referenced itself because it's a fairly benign flag (as opposed to things like PG_lock). It's also (according to Willy) unlikely to go away any time soon.
PG_referenced is not in PAGE_FLAGS_CHECK_AT_FREE. It does not need to be cleared before freeing the page, and pages coming out of the allocator should have it cleared. Regardless, introduce an API to clear it anyway. Having symmetry in the API makes it easier to change the underlying implementation later, like if there was a need to move to a PAGE_FLAGS_CHECK_AT_FREE bit.
--- include/linux/mm.h | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
include/linux/mm.h +41 -0
@@ -2947,6 +2947,7 @@ static inline pmd_t *pmd_alloc(struct mm#endif /* CONFIG_MMU */ enum pt_flags { + PT_kernel = PG_referenced, PT_reserved = PG_reserved,/* High bits are used for zone/node/section */ };
@@ -2973,6 +2974,46 @@ static inline bool pagetable_is_reserved }/** +* ptdesc_set_kernel - Mark a ptdesc used to map the kernel +* @ptdesc: The ptdesc to be marked +* +* Kernel page tables often need special handling. Set a flag so that +* the handling code knows this ptdesc will not be used for userspace. +*/ +static inline void ptdesc_set_kernel (struct ptdesc *ptdesc) +{ +set_bit (PT_kernel, &ptdesc->pt_flags.f); +} + +/** +* ptdesc_clear_kernel - Mark a ptdesc as no longer used to map the kernel +* @ptdesc: The ptdesc to be unmarked +* +* Use when the ptdesc is no longer used to map the kernel and no longer +* needs special handling. +*/ +static inline void ptdesc_clear_kernel (struct ptdesc *ptdesc) +{ +/* +* Note: the 'PG_referenced' bit does not strictly need to be +* cleared before freeing the page. But this is nice for +* symmetry. +*/ +clear_bit (PT_kernel, &ptdesc->pt_flags.f); +} + +/** +* ptdesc_test_kernel - Check if a ptdesc is used to map the kernel +* @ptdesc: The ptdesc being tested +* +* Call to tell if the ptdesc used to map the kernel. +*/ +static inline bool ptdesc_test_kernel (const struct ptdesc *ptdesc) +{ +return test_bit (PT_kernel, &ptdesc->pt_flags.f); +} + +/** * pagetable_alloc - Allocate pagetables * @gfp: GFP flags * @order: desired pagetable order
Greg Kroah-Hartman
maintainerPATCH 185/198 mm: actually mark kernel page table pages
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <[email protected]>
commit 977870522af34359b461060597ee3a86f27450d6 upstream.
Now that the API is in place, mark kernel page table pages just after they are allocated. Unmark them just before they are freed.
Note: Unconditionally clearing the 'kernel' marking (via ptdesc_clear_kernel()) would be functionally identical to what is here. But having the if() makes it logically clear that this function can be used for kernel and non-kernel page tables.
--- include/asm-generic/pgalloc.h | 18 ++++++++++++++++++ include/linux/mm.h | 3 +++ 2 files changed, 21 insertions(+)
include/asm-generic/pgalloc.h +18 -0
@@ -28,6 +28,8 @@ static inline pte_t *__pte_alloc_one_kerreturn NULL ; } +ptdesc_set_kernel (ptdesc); +return ptdesc_address (ptdesc); }#define __pte_alloc_one_kernel (...) alloc_hooks(__pte_alloc_one_kernel_noprof(__VA_ARGS__))
@@ -146,6 +148,10 @@ static inline pmd_t *pmd_alloc_one_nopropagetable_free (ptdesc);return NULL ; } + +if (mm == &init_mm) +ptdesc_set_kernel (ptdesc); +return ptdesc_address (ptdesc); }#define pmd_alloc_one (...) alloc_hooks(pmd_alloc_one_noprof(__VA_ARGS__))
@@ -179,6 +185,10 @@ static inline pud_t *__pud_alloc_one_nopreturn NULL ;pagetable_pud_ctor (ptdesc); + +if (mm == &init_mm) +ptdesc_set_kernel (ptdesc); +return ptdesc_address (ptdesc); }#define __pud_alloc_one (...) alloc_hooks(__pud_alloc_one_noprof(__VA_ARGS__))
@@ -233,6 +243,10 @@ static inline p4d_t *__p4d_alloc_one_nopreturn NULL ;pagetable_p4d_ctor (ptdesc); + +if (mm == &init_mm) +ptdesc_set_kernel (ptdesc); +return ptdesc_address (ptdesc); }#define __p4d_alloc_one (...) alloc_hooks(__p4d_alloc_one_noprof(__VA_ARGS__))
@@ -277,6 +291,10 @@ static inline pgd_t *__pgd_alloc_noprof(return NULL ;pagetable_pgd_ctor (ptdesc); + +if (mm == &init_mm) +ptdesc_set_kernel (ptdesc); +return ptdesc_address (ptdesc); }#define __pgd_alloc (...) alloc_hooks(__pgd_alloc_noprof(__VA_ARGS__))
include/linux/mm.h +3 -0
@@ -3042,6 +3042,9 @@ static inline void pagetable_free(struct {struct page *page =ptdesc_page (pt); +if (ptdesc_test_kernel (pt)) +ptdesc_clear_kernel (pt); +__free_pages (page,compound_order (page)); }
Greg Kroah-Hartman
maintainerPATCH 186/198 x86/mm: use ptdesc when freeing PMD pages
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <[email protected]>
commit 412d000346ea38ac4b9bb715a86c73ef89d90dea upstream.
There are a billion ways to refer to a physical memory address. One of the x86 PMD freeing code location chooses to use a 'pte_t *' to point to a PMD page and then call a PTE-specific freeing function for it. That's a bit wonky.
Just use a 'struct ptdesc *' instead. Its entire purpose is to refer to page table pages. It also means being able to remove an explicit cast.
Right now, pte_free_kernel() is a one-liner that calls pagetable_dtor_free(). Effectively, all this patch does is remove one superfluous __pa(__va(paddr)) conversion and then call pagetable_dtor_free() directly instead of through a helper.
--- arch/x86/mm/pgtable.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
arch/x86/mm/pgtable.c +6 -6
@@ -729,7 +729,7 @@ int pmd_clear_huge(pmd_t *pmd)int pud_free_pmd_page (pud_t *pud,unsigned long addr) {pmd_t *pmd, *pmd_sv; -pte_t *pte; +struct ptdesc *pt;int i; pmd =pud_pgtable (*pud);
@@ -750,8 +750,8 @@ int pud_free_pmd_page(pud_t *pud, unsignfor (i =0 ; i <PTRS_PER_PMD ; i++) {if (!pmd_none (pmd_sv[i])) { - pte = (pte_t *)pmd_page_vaddr (pmd_sv[i]); -pte_free_kernel (&init_mm, pte); + pt =page_ptdesc (pmd_page (pmd_sv[i])); +pagetable_dtor_free (pt); } }
@@ -772,15 +772,15 @@ int pud_free_pmd_page(pud_t *pud, unsign*/ int pmd_free_pte_page (pmd_t *pmd,unsigned long addr) { -pte_t *pte; +struct ptdesc *pt; - pte = (pte_t *)pmd_page_vaddr (*pmd); + pt =page_ptdesc (pmd_page (*pmd));pmd_clear (pmd);/* INVLPG to clear all paging-structure caches */ flush_tlb_kernel_range (addr, addr +PAGE_SIZE -1 ); -pte_free_kernel (&init_mm, pte); +pagetable_dtor_free (pt);return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 187/198 mm: introduce pure page table freeing function
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <[email protected]>
commit 01894295672335ff304beed4359f30d14d5765f2 upstream.
The pages used for ptdescs are currently freed back to the allocator in a single location. They will shortly be freed from a second location.
Create a simple helper that just frees them back to the allocator.
--- include/linux/mm.h | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
include/linux/mm.h +8 -3
@@ -3031,6 +3031,13 @@ static inline struct ptdesc *pagetable_a }#define pagetable_alloc (...) alloc_hooks(pagetable_alloc_noprof(__VA_ARGS__)) +static inline void __pagetable_free (struct ptdesc *pt) +{ +struct page *page =ptdesc_page (pt); + +__free_pages (page,compound_order (page)); +} +/** * pagetable_free - Free pagetables * @pt: The page table descriptor
@@ -3040,12 +3047,10 @@ static inline struct ptdesc *pagetable_a*/ static inline void pagetable_free (struct ptdesc *pt) { -struct page *page =ptdesc_page (pt); -if (ptdesc_test_kernel (pt))ptdesc_clear_kernel (pt); -__free_pages (page,compound_order (page)); +__pagetable_free (pt); }#if defined(CONFIG_SPLIT_PTE_PTLOCKS )
Greg Kroah-Hartman
maintainerPATCH 188/198 x86/mm: use pagetable_free()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <[email protected]>
commit bf9e4e30f3538391745a99bc2268ec4f5e4a401e upstream.
The kernel's memory management subsystem provides a dedicated interface, pagetable_free(), for freeing page table pages. Updates two call sites to use pagetable_free() instead of the lower-level __free_page() or free_pages(). This improves code consistency and clarity, and ensures the correct freeing mechanism is used.
--- arch/x86/mm/init_64.c | 2 +- arch/x86/mm/pat/set_memory.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/x86/mm/init_64.c +1 -1
@@ -1031,7 +1031,7 @@ static void __meminit free_pagetable(strfree_reserved_pages (page, nr_pages);#endif }else { -__free_pages (page, order); +pagetable_free (page_ptdesc (page)); } }
arch/x86/mm/pat/set_memory.c +1 -1
@@ -429,7 +429,7 @@ static void cpa_collapse_large_pages(strlist_for_each_entry_safe (ptdesc, tmp, &pgtables, pt_list) {list_del (&ptdesc->pt_list); -__free_page (ptdesc_page (ptdesc)); +pagetable_free (ptdesc); } }
Greg Kroah-Hartman
maintainerPATCH 189/198 mm: introduce deferred freeing for kernel page tables
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Hansen <[email protected]>
commit 5ba2f0a1556479638ac11a3c201421f5515e89f5 upstream.
This introduces a conditional asynchronous mechanism, enabled by CONFIG_ASYNC_KERNEL_PGTABLE_FREE. When enabled, this mechanism defers the freeing of pages that are used as page tables for kernel address mappings. These pages are now queued to a work struct instead of being freed immediately.
This deferred freeing allows for batch-freeing of page tables, providing a safe context for performing a single expensive operation (TLB flush) for a batch of kernel page tables instead of performing that expensive operation for each page table.
--- include/linux/mm.h | 16 +++++++++++++--- mm/Kconfig | 3 +++ mm/pgtable-generic.c | 37 +++++++++++++++++++++++++++++++++++++ 3 files changed, 53 insertions(+), 3 deletions(-)
include/linux/mm.h +13 -3
@@ -3038,6 +3038,14 @@ static inline void __pagetable_free(stru__free_pages (page,compound_order (page)); } +#ifdef CONFIG_ASYNC_KERNEL_PGTABLE_FREE +void pagetable_free_kernel (struct ptdesc *pt); +#else +static inline void pagetable_free_kernel (struct ptdesc *pt) +{ +__pagetable_free (pt); +} +#endif /** * pagetable_free - Free pagetables * @pt: The page table descriptor
@@ -3047,10 +3055,12 @@ static inline void __pagetable_free(stru*/ static inline void pagetable_free (struct ptdesc *pt) { -if (ptdesc_test_kernel (pt)) +if (ptdesc_test_kernel (pt)) {ptdesc_clear_kernel (pt); - -__pagetable_free (pt); +pagetable_free_kernel (pt); + }else { +__pagetable_free (pt); + } }#if defined(CONFIG_SPLIT_PTE_PTLOCKS )
mm/Kconfig +3 -0
@@ -915,6 +915,9 @@ config HAVE_GIGANTIC_FOLIOS def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \ (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) +config ASYNC_KERNEL_PGTABLE_FREE + def_bool n + # TODO: Allow to be enabled without THP config ARCH_SUPPORTS_HUGE_PFNMAP def_bool n
mm/pgtable-generic.c +37 -0
@@ -406,3 +406,40 @@ again:pte_unmap_unlock (pte, ptl); goto again; } + +#ifdef CONFIG_ASYNC_KERNEL_PGTABLE_FREE +static void kernel_pgtable_work_func (struct work_struct *work); + +static struct { +struct list_head list; +/* protect above ptdesc lists */ +spinlock_t lock; +struct work_struct work; +} kernel_pgtable_work = { + .list =LIST_HEAD_INIT (kernel_pgtable_work.list), + .lock =__SPIN_LOCK_UNLOCKED (kernel_pgtable_work.lock), + .work =__WORK_INITIALIZER (kernel_pgtable_work.work, kernel_pgtable_work_func), +}; + +static void kernel_pgtable_work_func (struct work_struct *work) +{ +struct ptdesc *pt, *next; +LIST_HEAD (page_list); + +spin_lock (&kernel_pgtable_work.lock); +list_splice_tail_init (&kernel_pgtable_work.list, &page_list); +spin_unlock (&kernel_pgtable_work.lock); + +list_for_each_entry_safe (pt, next, &page_list, pt_list) +__pagetable_free (pt); +} + +void pagetable_free_kernel (struct ptdesc *pt) +{ +spin_lock (&kernel_pgtable_work.lock); +list_add (&pt->pt_list, &kernel_pgtable_work.list); +spin_unlock (&kernel_pgtable_work.lock); + +schedule_work (&kernel_pgtable_work.work); +} +#endif
Greg Kroah-Hartman
maintainerPATCH 190/198 iommu/sva: invalidate stale IOTLB entries for kernel address space
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <[email protected]>
commit e37d5a2d60a338c5917c45296bac65da1382eda5 upstream.
Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space. This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.
This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users. While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users. The discussion can be found at the link below.
Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.
--- arch/x86/Kconfig | 1 + drivers/iommu/iommu-sva.c | 32 ++++++++++++++++++++++++++++---- include/linux/iommu.h | 4 ++++ mm/pgtable-generic.c | 2 ++ 4 files changed, 35 insertions(+), 4 deletions(-)
arch/x86/Kconfig +1 -0
@@ -279,6 +279,7 @@ config X86 select HAVE_PCI select HAVE_PERF_REGS select HAVE_PERF_USER_STACK_DUMP + select ASYNC_KERNEL_PGTABLE_FREE if IOMMU_SVA select MMU_GATHER_RCU_TABLE_FREE select MMU_GATHER_MERGE_VMAS select HAVE_POSIX_CPU_TIMERS_TASK_WORK
drivers/iommu/iommu-sva.c +28 -4
@@ -10,6 +10,8 @@#include "iommu-priv.h" static DEFINE_MUTEX (iommu_sva_lock); +static bool iommu_sva_present; +static LIST_HEAD (iommu_sva_mms);static struct iommu_domain *iommu_sva_domain_alloc (struct device *dev,struct mm_struct *mm);
@@ -42,6 +44,7 @@ static struct iommu_mm_data *iommu_allocreturn ERR_PTR (-ENOSPC ); } iommu_mm->pasid = pasid; + iommu_mm->mm = mm;INIT_LIST_HEAD (&iommu_mm->sva_domains);/* * Make sure the write to mm->iommu_mm is not reordered in front of
@@ -77,9 +80,6 @@ struct iommu_sva *iommu_sva_bind_device(if (!group)return ERR_PTR (-ENODEV ); -if (IS_ENABLED (CONFIG_X86 )) -return ERR_PTR (-EOPNOTSUPP ); -mutex_lock (&iommu_sva_lock);/* Allocate mm->pasid if necessary. */
@@ -135,8 +135,13 @@ struct iommu_sva *iommu_sva_bind_device(if (ret) goto out_free_domain; domain->users =1 ; -list_add (&domain->next, &mm->iommu_mm->sva_domains); +if (list_empty (&iommu_mm->sva_domains)) { +if (list_empty (&iommu_sva_mms)) + iommu_sva_present = true; +list_add (&iommu_mm->mm_list_elm, &iommu_sva_mms); + } +list_add (&domain->next, &iommu_mm->sva_domains); out:refcount_set (&handle->users,1 );mutex_unlock (&iommu_sva_lock);
@@ -178,6 +183,13 @@ void iommu_sva_unbind_device(struct iommlist_del (&domain->next);iommu_domain_free (domain); } + +if (list_empty (&iommu_mm->sva_domains)) { +list_del (&iommu_mm->mm_list_elm); +if (list_empty (&iommu_sva_mms)) + iommu_sva_present = false; + } +mutex_unlock (&iommu_sva_lock);kfree (handle); }
@@ -315,3 +327,15 @@ static struct iommu_domain *iommu_sva_doreturn domain; } + +void iommu_sva_invalidate_kva_range (unsigned long start,unsigned long end) +{ +struct iommu_mm_data *iommu_mm; + +guard (mutex)(&iommu_sva_lock); +if (!iommu_sva_present) +return ; + +list_for_each_entry (iommu_mm, &iommu_sva_mms, mm_list_elm) +mmu_notifier_arch_invalidate_secondary_tlbs (iommu_mm->mm, start, end); +}
include/linux/iommu.h +4 -0
@@ -1134,7 +1134,9 @@ struct iommu_sva {struct iommu_mm_data {u32 pasid; +struct mm_struct *mm;struct list_head sva_domains; +struct list_head mm_list_elm; };int iommu_fwspec_init (struct device *dev,struct fwnode_handle *iommu_fwnode);
@@ -1615,6 +1617,7 @@ struct iommu_sva *iommu_sva_bind_device( struct mm_struct *mm);void iommu_sva_unbind_device (struct iommu_sva *handle);u32 iommu_sva_get_pasid (struct iommu_sva *handle); +void iommu_sva_invalidate_kva_range (unsigned long start,unsigned long end);#else static inline struct iommu_sva *iommu_sva_bind_device (struct device *dev,struct mm_struct *mm)
@@ -1639,6 +1642,7 @@ static inline u32 mm_get_enqcmd_pasid(st }static inline void mm_pasid_drop (struct mm_struct *mm) {} +static inline void iommu_sva_invalidate_kva_range (unsigned long start,unsigned long end) {}#endif /* CONFIG_IOMMU_SVA */ #ifdef CONFIG_IOMMU_IOPF
mm/pgtable-generic.c +2 -0
@@ -13,6 +13,7 @@#include <linux/swap.h> #include <linux/swapops.h> #include <linux/mm_inline.h> +#include <linux/iommu.h> #include <asm/pgalloc.h> #include <asm/tlb.h>
@@ -430,6 +431,7 @@ static void kernel_pgtable_work_func(strlist_splice_tail_init (&kernel_pgtable_work.list, &page_list);spin_unlock (&kernel_pgtable_work.lock); +iommu_sva_invalidate_kva_range (PAGE_OFFSET ,TLB_FLUSH_ALL );list_for_each_entry_safe (pt, next, &page_list, pt_list)__pagetable_free (pt); }
Greg Kroah-Hartman
maintainerPATCH 191/198 HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Lixu <[email protected]>
commit 0d30dae38fe01cd1de358c6039a0b1184689fe51 upstream.
During suspend/resume tests with S2IDLE, some ISH functional failures were observed because of delay in executing ISH resume handler. Here schedule_work() is used from resume handler to do actual work. schedule_work() uses system_wq, which is a per CPU work queue. Although the queuing is not bound to a CPU, but it prefers local CPU of the caller, unless prohibited.
Users of this work queue are not supposed to queue long running work. But in practice, there are scenarios where long running work items are queued on other unbound workqueues, occupying the CPU. As a result, the ISH resume handler may not get a chance to execute in a timely manner.
In one scenario, one of the ish_resume_handler() executions was delayed nearly 1 second because another work item on an unbound workqueue occupied the same CPU. This delay causes ISH functionality failures.
A similar issue was previously observed where the ISH HID driver timed out while getting the HID descriptor during S4 resume in the recovery kernel, likely caused by the same workqueue contention problem.
Create dedicated unbound workqueues for all ISH operations to allow work items to execute on any available CPU, eliminating CPU-specific bottlenecks and improving resume reliability under varying system loads. Also ISH has three different components, a bus driver which implements ISH protocols, a PCI interface layer and HID interface. Use one dedicated work queue for all of them.
--- drivers/hid/intel-ish-hid/ipc/ipc.c | 21 ++++++++++++++++++++- drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +- drivers/hid/intel-ish-hid/ishtp-hid-client.c | 4 ++-- drivers/hid/intel-ish-hid/ishtp/bus.c | 18 +++++++++++++++++- drivers/hid/intel-ish-hid/ishtp/hbm.c | 4 ++-- drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h | 3 +++ include/linux/intel-ish-client-if.h | 2 ++ 7 files changed, 47 insertions(+), 7 deletions(-)
drivers/hid/intel-ish-hid/ipc/ipc.c +20 -1
@@ -628,7 +628,7 @@ static void recv_ipc(struct ishtp_deviceif (!ishtp_dev) { ishtp_dev = dev; } -schedule_work (&fw_reset_work); +queue_work (dev->unbound_wq, &fw_reset_work);break ;case MNG_RESET_NOTIFY_ACK :
@@ -933,6 +933,21 @@ static const struct ishtp_hw_ops ish_hw_ .dma_no_cache_snooping = _dma_no_cache_snooping }; +static struct workqueue_struct *devm_ishtp_alloc_workqueue (struct device *dev) +{ +struct workqueue_struct *wq; + + wq =alloc_workqueue ("ishtp_unbound_%d" ,WQ_UNBOUND ,0 , dev->id); +if (!wq) +return NULL ; + +if (devm_add_action_or_reset (dev, (void (*)(void *))destroy_workqueue, + wq)) +return NULL ; + +return wq; +} +/** * ish_dev_init() -Initialize ISH devoce * @pdev: PCI device
@@ -953,6 +968,10 @@ struct ishtp_device *ish_dev_init(structif (!dev)return NULL ; + dev->unbound_wq =devm_ishtp_alloc_workqueue (&pdev->dev); +if (!dev->unbound_wq) +return NULL ; + dev->devc = &pdev->dev;ishtp_device_init (dev);
drivers/hid/intel-ish-hid/ipc/pci-ish.c +1 -1
@@ -384,7 +384,7 @@ static int __maybe_unused ish_resume(str ish_resume_device = device; dev->resume_flag =1 ; -schedule_work (&resume_work); +queue_work (dev->unbound_wq, &resume_work);return 0 ; }
drivers/hid/intel-ish-hid/ishtp-hid-client.c +2 -2
@@ -860,7 +860,7 @@ static int hid_ishtp_cl_reset(struct ishhid_ishtp_trace (client_data,"%s hid_ishtp_cl %p\n" , __func__, hid_ishtp_cl); -schedule_work (&client_data->work); +queue_work (ishtp_get_workqueue (cl_device), &client_data->work);return 0 ; }
@@ -902,7 +902,7 @@ static int hid_ishtp_cl_resume(struct dehid_ishtp_trace (client_data,"%s hid_ishtp_cl %p\n" , __func__, hid_ishtp_cl); -schedule_work (&client_data->resume_work); +queue_work (ishtp_get_workqueue (cl_device), &client_data->resume_work);return 0 ; }
drivers/hid/intel-ish-hid/ishtp/bus.c +17 -1
@@ -541,7 +541,7 @@ void ishtp_cl_bus_rx_event(struct ishtp_return ;if (device->event_cb) -schedule_work (&device->event_work); +queue_work (device->ishtp_dev->unbound_wq, &device->event_work); }/**
@@ -877,6 +877,22 @@ struct device *ishtp_get_pci_device(struEXPORT_SYMBOL (ishtp_get_pci_device);/** +* ishtp_get_workqueue - Retrieve the workqueue associated with an ISHTP device +* @cl_device: Pointer to the ISHTP client device structure +* +* Returns the workqueue_struct pointer (unbound_wq) associated with the given +* ISHTP client device. This workqueue is typically used for scheduling work +* related to the device. +* +* Return: Pointer to struct workqueue_struct. +*/ +struct workqueue_struct *ishtp_get_workqueue (struct ishtp_cl_device *cl_device) +{ +return cl_device->ishtp_dev->unbound_wq; +} +EXPORT_SYMBOL (ishtp_get_workqueue); + +/** * ishtp_trace_callback() - Return trace callback * @cl_device: ISH-TP client device instance *
drivers/hid/intel-ish-hid/ishtp/hbm.c +2 -2
@@ -573,7 +573,7 @@ void ishtp_hbm_dispatch(struct ishtp_dev/* Start firmware loading process if it has loader capability */ if (version_res->host_version_supported &ISHTP_SUPPORT_CAP_LOADER ) -schedule_work (&dev->work_fw_loader); +queue_work (dev->unbound_wq, &dev->work_fw_loader); dev->version.major_version =HBM_MAJOR_VERSION ; dev->version.minor_version =HBM_MINOR_VERSION ;
@@ -864,7 +864,7 @@ void recv_hbm(struct ishtp_device *dev, dev->rd_msg_fifo_tail = (dev->rd_msg_fifo_tail +IPC_PAYLOAD_SIZE ) % (RD_INT_FIFO_SIZE *IPC_PAYLOAD_SIZE );spin_unlock_irqrestore (&dev->rd_msg_spinlock, flags); -schedule_work (&dev->bh_hbm_work); +queue_work (dev->unbound_wq, &dev->bh_hbm_work); eoi:return ; }
drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h +3 -0
@@ -175,6 +175,9 @@ struct ishtp_device {struct hbm_version version;int transfer_path;/* Choice of transfer path: IPC or DMA */ +/* Alloc a dedicated unbound workqueue for ishtp device */ +struct workqueue_struct *unbound_wq; +/* work structure for scheduling firmware loading tasks */ struct work_struct work_fw_loader;/* waitq for waiting for command response from the firmware loader */
include/linux/intel-ish-client-if.h +2 -0
@@ -87,6 +87,8 @@ bool ishtp_wait_resume(struct ishtp_deviishtp_print_log ishtp_trace_callback (struct ishtp_cl_device *cl_device);/* Get device pointer of PCI device for DMA acces */ struct device *ishtp_get_pci_device (struct ishtp_cl_device *cl_device); +/* Get the ISHTP workqueue */ +struct workqueue_struct *ishtp_get_workqueue (struct ishtp_cl_device *cl_device);struct ishtp_cl *ishtp_cl_allocate (struct ishtp_cl_device *cl_device);void ishtp_cl_free (struct ishtp_cl *cl);
Greg Kroah-Hartman
maintainerPATCH 192/198 HID: intel-ish-hid: Fix -Wcast-function-type-strict in devm_ishtp_alloc_workqueue()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 3644f4411713f52bf231574aa8759e3d8e20b341 upstream.
Clang warns (or errors with CONFIG_WERROR=y / W=e):
drivers/hid/intel-ish-hid/ipc/ipc.c:935:36: error: cast from 'void (*)(struct workqueue_struct *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
935 | if (devm_add_action_or_reset(dev, (void (*)(void *))destroy_workqueue,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/device/devres.h:168:34: note: expanded from macro 'devm_add_action_or_reset'
168 | __devm_add_action_or_ireset(dev, action, data, #action)
| ^~~~~~
This warning is pointing out a kernel control flow integrity (kCFI / CONFIG_CFI=y) violation will occur due to this function cast when the destroy_workqueue() is indirectly called via devm_action_release() because the prototype of destroy_workqueue() does not match the prototype of (*action)().
Use a local function with the correct prototype to wrap destroy_workqueue() to resolve the warning and CFI violation.
--- drivers/hid/intel-ish-hid/ipc/ipc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/hid/intel-ish-hid/ipc/ipc.c +6 -2
@@ -933,6 +933,11 @@ static const struct ishtp_hw_ops ish_hw_ .dma_no_cache_snooping = _dma_no_cache_snooping }; +static void ishtp_free_workqueue (void *wq) +{ +destroy_workqueue (wq); +} +static struct workqueue_struct *devm_ishtp_alloc_workqueue (struct device *dev) {struct workqueue_struct *wq;
@@ -941,8 +946,7 @@ static struct workqueue_struct *devm_ishif (!wq)return NULL ; -if (devm_add_action_or_reset (dev, (void (*)(void *))destroy_workqueue, - wq)) +if (devm_add_action_or_reset (dev, ishtp_free_workqueue, wq))return NULL ;return wq;
Greg Kroah-Hartman
maintainerPATCH 193/198 btrfs: fix deadlock in wait_current_trans() due to ignored transaction type
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robbie Ko <[email protected]>
commit 5037b342825df7094a4906d1e2a9674baab50cb2 upstream.
When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans().
This can lead to a deadlock scenario involving two transactions and pending ordered extents:
1. Transaction A is in TRANS_STATE_COMMIT_DOING state
2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN
3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING
4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes
5. A new Transaction B is created (TRANS_STATE_RUNNING)
6. The ordered extent from step 2 is added to Transaction B's pending ordered extents
7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START
8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally
9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START
according to btrfs_blocked_trans_types[]
10. Transaction B is waiting for pending ordered extents to complete
11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B
This can be illustrated by the following call stacks:
CPU0 CPU1
btrfs_finish_ordered_io()
start_transaction(TRANS_JOIN)
join_transaction()
# -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING)
# Transaction A completes
# Transaction B created
# ordered extent added to
# Transaction B's pending list
btrfs_commit_transaction()
# Transaction B enters
# TRANS_STATE_COMMIT_START
# waiting for pending ordered
# extents
wait_current_trans()
# waits for Transaction B
# (should not wait!)Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents:
__schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Task kworker in wait_current_trans waiting for transaction commit:
Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30
Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.
--- fs/btrfs/transaction.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
fs/btrfs/transaction.c +6 -5
@@ -518,13 +518,14 @@ static inline int is_transaction_blocked* when this is done, it is safe to start a new transaction, but the current * transaction might not be fully on disk. */ -static void wait_current_trans (struct btrfs_fs_info *fs_info) +static void wait_current_trans (struct btrfs_fs_info *fs_info,unsigned int type) {struct btrfs_transaction *cur_trans;spin_lock (&fs_info->trans_lock); cur_trans = fs_info->running_transaction; -if (cur_trans &&is_transaction_blocked (cur_trans)) { +if (cur_trans &&is_transaction_blocked (cur_trans) && + (btrfs_blocked_trans_types[cur_trans->state] & type)) {refcount_inc (&cur_trans->use_count);spin_unlock (&fs_info->trans_lock);
@@ -699,12 +700,12 @@ again:sb_start_intwrite (fs_info->sb);if (may_wait_transaction (fs_info, type)) -wait_current_trans (fs_info); +wait_current_trans (fs_info, type); do { ret = join_transaction(fs_info, type); if (ret == -EBUSY) { - wait_current_trans(fs_info); + wait_current_trans(fs_info, type); if (unlikely(type == TRANS_ATTACH || type == TRANS_JOIN_NOSTART)) ret = -ENOENT;
@@ -1001,7 +1002,7 @@ out:void btrfs_throttle (struct btrfs_fs_info *fs_info) { -wait_current_trans (fs_info); +wait_current_trans (fs_info,TRANS_START ); }bool btrfs_should_end_transaction (struct btrfs_trans_handle *trans)
Greg Kroah-Hartman
maintainerPATCH 194/198 mm/page_alloc/vmstat: simplify refresh_cpu_vm_stats change detection
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joshua Hahn <[email protected]>
commit 0acc67c4030c39f39ac90413cc5d0abddd3a9527 upstream.
Patch series "mm/page_alloc: Batch callers of free_pcppages_bulk", v5.
Motivation & Approach
=====================
While testing workloads with high sustained memory pressure on large machines in the Meta fleet (1Tb memory, 316 CPUs), we saw an unexpectedly high number of softlockups. Further investigation showed that the zone lock in free_pcppages_bulk was being held for a long time, and was called to free 2k+ pages over 100 times just during boot.
This causes starvation in other processes for the zone lock, which can lead to the system stalling as multiple threads cannot make progress without the locks. We can see these issues manifesting as warnings:
[ 4512.591979] rcu: INFO: rcu_sched self-detected stall on CPU [ 4512.604370] rcu: 20-....: (9312 ticks this GP) idle=a654/1/0x4000000000000000 softirq=309340/309344 fqs=5426 [ 4512.626401] rcu: hardirqs softirqs csw/system [ 4512.638793] rcu: number: 0 145 0 [ 4512.651177] rcu: cputime: 30 10410 174 ==> 10558(ms) [ 4512.666657] rcu: (t=21077 jiffies g=783665 q=1242213 ncpus=316)
While these warnings don't indicate a crash or a kernel panic, they do point to the underlying issue of lock contention. To prevent starvation in both locks, batch the freeing of pages using pcp->batch.
Because free_pcppages_bulk is called with the pcp lock and acquires the zone lock, relinquishing and reacquiring the locks are only effective when both of them are broken together (unless the system was built with queued spinlocks). Thus, instead of modifying free_pcppages_bulk to break both locks, batch the freeing from its callers instead.
A similar fix has been implemented in the Meta fleet, and we have seen significantly less softlockups.
Testing
=======
The following are a few synthetic benchmarks, made on three machines. The first is a large machine with 754GiB memory and 316 processors. The second is a relatively smaller machine with 251GiB memory and 176 processors. The third and final is the smallest of the three, which has 62GiB memory and 36 processors.
On all machines, I kick off a kernel build with -j$(nproc). Negative delta is better (faster compilation).
Large machine (754GiB memory, 316 processors)
make -j$(nproc)
+------------+---------------+-----------+ | Metric (s) | Variation (%) | Delta(%) | +------------+---------------+-----------+ | real | 0.8070 | - 1.4865 | | user | 0.2823 | + 0.4081 | | sys | 5.0267 | -11.8737 | +------------+---------------+-----------+
Medium machine (251GiB memory, 176 processors)
make -j$(nproc)
+------------+---------------+----------+ | Metric (s) | Variation (%) | Delta(%) | +------------+---------------+----------+ | real | 0.2806 | +0.0351 | | user | 0.0994 | +0.3170 | | sys | 0.6229 | -0.6277 | +------------+---------------+----------+
Small machine (62GiB memory, 36 processors)
make -j$(nproc)
+------------+---------------+----------+ | Metric (s) | Variation (%) | Delta(%) | +------------+---------------+----------+ | real | 0.1503 | -2.6585 | | user | 0.0431 | -2.2984 | | sys | 0.1870 | -3.2013 | +------------+---------------+----------+
Here, variation is the coefficient of variation, i.e. standard deviation / mean.
Based on these results, it seems like there are varying degrees to how much lock contention this reduces. For the largest and smallest machines that I ran the tests on, it seems like there is quite some significant reduction. There is also some performance increases visible from userspace.
Interestingly, the performance gains don't scale with the size of the machine, but rather there seems to be a dip in the gain there is for the medium-sized machine. One possible theory is that because the high watermark depends on both memory and the number of local CPUs, what impacts zone contention the most is not these individual values, but rather the ratio of mem:processors.
This patch (of 5):
Currently, refresh_cpu_vm_stats returns an int, indicating how many changes were made during its updates. Using this information, callers like vmstat_update can heuristically determine if more work will be done in the future.
However, all of refresh_cpu_vm_stats's callers either (a) ignore the result, only caring about performing the updates, or (b) only care about whether changes were made, but not *how many* changes were made.
Simplify the code by returning a bool instead to indicate if updates were made.
In addition, simplify fold_diff and decay_pcp_high to return a bool for the same reason.
Stable-dep-of: 038a102535eb ("mm/page_alloc: prevent pcp corruption with SMP=n")
--- include/linux/gfp.h | 2 +- mm/page_alloc.c | 8 ++++---- mm/vmstat.c | 28 +++++++++++++++------------- 3 files changed, 20 insertions(+), 18 deletions(-)
include/linux/gfp.h +1 -1
@@ -387,7 +387,7 @@ extern void free_pages(unsigned long add#define free_page (addr) free_pages((addr), 0)void page_alloc_init_cpuhp (void ); -int decay_pcp_high (struct zone *zone,struct per_cpu_pages *pcp); +bool decay_pcp_high (struct zone *zone,struct per_cpu_pages *pcp);void drain_zone_pages (struct zone *zone,struct per_cpu_pages *pcp);void drain_all_pages (struct zone *zone);void drain_local_pages (struct zone *zone);
mm/page_alloc.c +4 -4
@@ -2552,10 +2552,10 @@ static int rmqueue_bulk(struct zone *zon* Called from the vmstat counter updater to decay the PCP high. * Return whether there are addition works to do. */ -int decay_pcp_high (struct zone *zone,struct per_cpu_pages *pcp) +bool decay_pcp_high (struct zone *zone,struct per_cpu_pages *pcp) {int high_min, to_drain, batch; -int todo =0 ; +bool todo = false; high_min =READ_ONCE (pcp->high_min); batch =READ_ONCE (pcp->batch);
@@ -2568,7 +2568,7 @@ int decay_pcp_high(struct zone *zone, st pcp->high =max3 (pcp->count - (batch <<CONFIG_PCP_BATCH_SCALE_MAX ), pcp->high - (pcp->high >>3 ), high_min);if (pcp->high > high_min) - todo++; + todo = true; } to_drain = pcp->count - pcp->high;
@@ -2576,7 +2576,7 @@ int decay_pcp_high(struct zone *zone, stspin_lock (&pcp->lock);free_pcppages_bulk (zone, to_drain, pcp,0 );spin_unlock (&pcp->lock); - todo++; + todo = true; }return todo;
mm/vmstat.c +15 -13
@@ -771,25 +771,25 @@ EXPORT_SYMBOL(dec_node_page_state);/* * Fold a differential into the global counters. -* Returns the number of counters updated. +* Returns whether counters were updated. */ static int fold_diff (int *zone_diff,int *node_diff) {int i; -int changes =0 ; +bool changed = false;for (i =0 ; i <NR_VM_ZONE_STAT_ITEMS ; i++)if (zone_diff[i]) {atomic_long_add (zone_diff[i], &vm_zone_stat[i]); - changes++; + changed = true; }for (i =0 ; i <NR_VM_NODE_STAT_ITEMS ; i++)if (node_diff[i]) {atomic_long_add (node_diff[i], &vm_node_stat[i]); - changes++; + changed = true; } -return changes; +return changed; }/*
@@ -806,16 +806,16 @@ static int fold_diff(int *zone_diff, int* with the global counters. These could cause remote node cache line * bouncing and will have to be only done when necessary. * -* The function returns the number of global counters updated. +* The function returns whether global counters were updated. */ -static int refresh_cpu_vm_stats (bool do_pagesets) +static bool refresh_cpu_vm_stats (bool do_pagesets) {struct pglist_data *pgdat;struct zone *zone;int i;int global_zone_diff[NR_VM_ZONE_STAT_ITEMS ] = {0 , };int global_node_diff[NR_VM_NODE_STAT_ITEMS ] = {0 , }; -int changes =0 ; +bool changed = false;for_each_populated_zone (zone) {struct per_cpu_zonestat __percpu *pzstats = zone->per_cpu_zonestats;
@@ -839,7 +839,8 @@ static int refresh_cpu_vm_stats(bool do_if (do_pagesets) {cond_resched (); - changes +=decay_pcp_high (zone,this_cpu_ptr (pcp)); +if (decay_pcp_high (zone,this_cpu_ptr (pcp))) + changed = true;#ifdef CONFIG_NUMA /* * Deal with draining the remote pageset of this
@@ -861,13 +862,13 @@ static int refresh_cpu_vm_stats(bool do_ }if (__this_cpu_dec_return (pcp->expire)) { - changes++; + changed = true;continue ; }if (__this_cpu_read (pcp->count)) {drain_zone_pages (zone,this_cpu_ptr (pcp)); - changes++; + changed = true; }#endif }
@@ -887,8 +888,9 @@ static int refresh_cpu_vm_stats(bool do_ } } - changes +=fold_diff (global_zone_diff, global_node_diff); -return changes; +if (fold_diff (global_zone_diff, global_node_diff)) + changed = true; +return changed; }/*
Greg Kroah-Hartman
maintainerPATCH 195/198 mm/page_alloc: batch page freeing in decay_pcp_high
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joshua Hahn <[email protected]>
commit fc4b909c368f3a7b08c895dd5926476b58e85312 upstream.
It is possible for pcp->count - pcp->high to exceed pcp->batch by a lot. When this happens, we should perform batching to ensure that free_pcppages_bulk isn't called with too many pages to free at once and starve out other threads that need the pcp or zone lock.
Since we are still only freeing the difference between the initial pcp->count and pcp->high values, there should be no change to how many pages are freed.
Stable-dep-of: 038a102535eb ("mm/page_alloc: prevent pcp corruption with SMP=n")
--- mm/page_alloc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
mm/page_alloc.c +6 -3
@@ -2554,7 +2554,7 @@ static int rmqueue_bulk(struct zone *zon*/ bool decay_pcp_high (struct zone *zone,struct per_cpu_pages *pcp) { -int high_min, to_drain, batch; +int high_min, to_drain, to_drain_batched, batch;bool todo = false; high_min =READ_ONCE (pcp->high_min);
@@ -2572,11 +2572,14 @@ bool decay_pcp_high(struct zone *zone, s } to_drain = pcp->count - pcp->high; -if (to_drain >0 ) { +while (to_drain >0 ) { + to_drain_batched =min (to_drain, batch);spin_lock (&pcp->lock); -free_pcppages_bulk (zone, to_drain, pcp,0 ); +free_pcppages_bulk (zone, to_drain_batched, pcp,0 );spin_unlock (&pcp->lock); todo = true; + + to_drain -= to_drain_batched; }return todo;
Greg Kroah-Hartman
maintainerPATCH 196/198 mm/page_alloc: prevent pcp corruption with SMP=n
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlastimil Babka <[email protected]>
commit 038a102535eb49e10e93eafac54352fcc5d78847 upstream.
The kernel test robot has reported:
BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) ___free_pages (mm/page_alloc.c:5295) __free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) </TASK>
Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure.
The problem has been introduced by commit 574907741599 ("mm/page_alloc:
leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock).
--- mm/page_alloc.c | 47 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 8 deletions(-)
mm/page_alloc.c +39 -8
@@ -166,6 +166,33 @@ static DEFINE_MUTEX(pcp_batch_high_lock)#define pcp_spin_unlock (ptr) \ pcpu_spin_unlock(lock, ptr) +/* +* With the UP spinlock implementation, when we spin_lock(&pcp->lock) (for i.e. +* a potentially remote cpu drain) and get interrupted by an operation that +* attempts pcp_spin_trylock(), we can't rely on the trylock failure due to UP +* spinlock assumptions making the trylock a no-op. So we have to turn that +* spin_lock() to a spin_lock_irqsave(). This works because on UP there are no +* remote cpu's so we can only be locking the only existing local one. +*/ +#if defined(CONFIG_SMP ) || defined(CONFIG_PREEMPT_RT ) +static inline void __flags_noop (unsigned long *flags) { } +#define pcp_spin_lock_maybe_irqsave (ptr, flags) \ +({ \ + __flags_noop(&(flags)); \ + spin_lock(&(ptr)->lock); \ +}) +#define pcp_spin_unlock_maybe_irqrestore (ptr, flags) \ +({ \ + spin_unlock(&(ptr)->lock); \ + __flags_noop(&(flags)); \ +}) +#else +#define pcp_spin_lock_maybe_irqsave (ptr, flags) \ + spin_lock_irqsave(&(ptr)->lock, flags) +#define pcp_spin_unlock_maybe_irqrestore (ptr, flags) \ + spin_unlock_irqrestore(&(ptr)->lock, flags) +#endif +#ifdef CONFIG_USE_PERCPU_NUMA_NODE_ID DEFINE_PER_CPU (int, numa_node);EXPORT_PER_CPU_SYMBOL (numa_node);
@@ -2555,6 +2582,7 @@ static int rmqueue_bulk(struct zone *zonbool decay_pcp_high (struct zone *zone,struct per_cpu_pages *pcp) {int high_min, to_drain, to_drain_batched, batch; +unsigned long UP_flags;bool todo = false; high_min =READ_ONCE (pcp->high_min);
@@ -2574,9 +2602,9 @@ bool decay_pcp_high(struct zone *zone, s to_drain = pcp->count - pcp->high;while (to_drain >0 ) { to_drain_batched =min (to_drain, batch); -spin_lock (&pcp->lock); +pcp_spin_lock_maybe_irqsave (pcp, UP_flags);free_pcppages_bulk (zone, to_drain_batched, pcp,0 ); -spin_unlock (&pcp->lock); +pcp_spin_unlock_maybe_irqrestore (pcp, UP_flags); todo = true; to_drain -= to_drain_batched;
@@ -2593,14 +2621,15 @@ bool decay_pcp_high(struct zone *zone, s*/ void drain_zone_pages (struct zone *zone,struct per_cpu_pages *pcp) { +unsigned long UP_flags;int to_drain, batch; batch =READ_ONCE (pcp->batch); to_drain =min (pcp->count, batch);if (to_drain >0 ) { -spin_lock (&pcp->lock); +pcp_spin_lock_maybe_irqsave (pcp, UP_flags);free_pcppages_bulk (zone, to_drain, pcp,0 ); -spin_unlock (&pcp->lock); +pcp_spin_unlock_maybe_irqrestore (pcp, UP_flags); } }#endif
@@ -2611,10 +2640,11 @@ void drain_zone_pages(struct zone *zone,static void drain_pages_zone (unsigned int cpu,struct zone *zone) {struct per_cpu_pages *pcp =per_cpu_ptr (zone->per_cpu_pageset, cpu); +unsigned long UP_flags;int count; do { - spin_lock(&pcp->lock); + pcp_spin_lock_maybe_irqsave(pcp, UP_flags); count = pcp->count; if (count) { int to_drain = min(count,
@@ -2623,7 +2653,7 @@ static void drain_pages_zone(unsigned infree_pcppages_bulk (zone, to_drain, pcp,0 ); count -= to_drain; } -spin_unlock (&pcp->lock); +pcp_spin_unlock_maybe_irqrestore (pcp, UP_flags); }while (count); }
@@ -6081,6 +6111,7 @@ static void zone_pcp_update_cacheinfo(st {struct per_cpu_pages *pcp;struct cpu_cacheinfo *cci; +unsigned long UP_flags; pcp =per_cpu_ptr (zone->per_cpu_pageset, cpu); cci =get_cpu_cacheinfo (cpu);
@@ -6091,12 +6122,12 @@ static void zone_pcp_update_cacheinfo(st* This can reduce zone lock contention without hurting * cache-hot pages sharing. */ -spin_lock (&pcp->lock); +pcp_spin_lock_maybe_irqsave (pcp, UP_flags);if ((cci->per_cpu_data_slice_size >>PAGE_SHIFT ) >3 * pcp->batch) pcp->flags |=PCPF_FREE_HIGH_BATCH ;else pcp->flags &= ~PCPF_FREE_HIGH_BATCH ; -spin_unlock (&pcp->lock); +pcp_spin_unlock_maybe_irqrestore (pcp, UP_flags); }void setup_pcp_cacheinfo (unsigned int cpu)
Greg Kroah-Hartman
maintainerPATCH 197/198 Revert "functionfs: fix the open/removal races"
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
This reverts commit b49c766856fb5901490de577e046149ebf15e39d which is commit e5bf5ee266633cb18fff6f98f0b7d59a62819eee upstream.
It has been reported to cause test problems in Android devices. As the other functionfs changes were not also backported at the same time, something is out of sync. So just revert this one for now and it can come back in the future as a patch series if it is tested.
--- drivers/usb/gadget/function/f_fs.c | 53 ++++++------------------------------- 1 file changed, 10 insertions(+), 43 deletions(-)
drivers/usb/gadget/function/f_fs.c +10 -43
@@ -640,22 +640,13 @@ done_mutex:static int ffs_ep0_open (struct inode *inode,struct file *file) { -struct ffs_data *ffs = inode->i_sb->s_fs_info; -int ret; - -/* Acquire mutex */ - ret =ffs_mutex_lock (&ffs->mutex, file->f_flags &O_NONBLOCK ); -if (ret <0 ) -return ret; +struct ffs_data *ffs = inode->i_private; -ffs_data_opened (ffs); -if (ffs->state ==FFS_CLOSING ) { -ffs_data_closed (ffs); -mutex_unlock (&ffs->mutex); +if (ffs->state ==FFS_CLOSING )return -EBUSY ; - } -mutex_unlock (&ffs->mutex); + file->private_data = ffs; +ffs_data_opened (ffs);return stream_open (inode, file); }
@@ -1202,33 +1193,14 @@ error:static int ffs_epfile_open (struct inode *inode,struct file *file) { -struct ffs_data *ffs = inode->i_sb->s_fs_info; -struct ffs_epfile *epfile; -int ret; - -/* Acquire mutex */ - ret =ffs_mutex_lock (&ffs->mutex, file->f_flags &O_NONBLOCK ); -if (ret <0 ) -return ret; +struct ffs_epfile *epfile = inode->i_private; -if (!atomic_inc_not_zero (&ffs->opened)) { -mutex_unlock (&ffs->mutex); -return -ENODEV ; - } -/* -* we want the state to be FFS_ACTIVE; FFS_ACTIVE alone is -* not enough, though - we might have been through FFS_CLOSING -* and back to FFS_ACTIVE, with our file already removed. -*/ - epfile =smp_load_acquire (&inode->i_private); -if (unlikely (ffs->state !=FFS_ACTIVE || !epfile)) { -mutex_unlock (&ffs->mutex); -ffs_data_closed (ffs); +if (WARN_ON (epfile->ffs->state !=FFS_ACTIVE ))return -ENODEV ; - } -mutex_unlock (&ffs->mutex); file->private_data = epfile; +ffs_data_opened (epfile->ffs); +return stream_open (inode, file); }
@@ -1360,7 +1332,7 @@ static void ffs_dmabuf_put(struct dma_bustatic int ffs_epfile_release (struct inode *inode,struct file *file) { -struct ffs_epfile *epfile = file->private_data; +struct ffs_epfile *epfile = inode->i_private;struct ffs_dmabuf_priv *priv, *tmp;struct ffs_data *ffs = epfile->ffs;
@@ -2380,11 +2352,6 @@ static int ffs_epfiles_create(struct ffsreturn 0 ; } -static void clear_one (struct dentry *dentry) -{ -smp_store_release (&dentry->d_inode->i_private,NULL ); -} -static void ffs_epfiles_destroy (struct ffs_epfile *epfiles,unsigned count) {struct ffs_epfile *epfile = epfiles;
@@ -2392,7 +2359,7 @@ static void ffs_epfiles_destroy(struct ffor (; count; --count, ++epfile) {BUG_ON (mutex_is_locked (&epfile->mutex));if (epfile->dentry) { -simple_recursive_removal (epfile->dentry, clear_one); +simple_recursive_removal (epfile->dentry,NULL ); epfile->dentry =NULL ; } }
Greg Kroah-Hartman
maintainerPATCH 198/198 iommu/sva: include mmu_notifier.h header
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Carlos Llamas <[email protected]>
commit 4b5c493ff762bb0433529ca6870b284f0a2a5ca8 upstream.
A call to mmu_notifier_arch_invalidate_secondary_tlbs() was introduced in commit e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") but without explicitly adding its corresponding header file <linux/mmu_notifier.h>. This was evidenced while trying to enable compile testing support for IOMMU_SVA:
config IOMMU_SVA
select IOMMU_MM_DATA
- bool
+ bool "Shared Virtual Addressing" if COMPILE_TEST
The thing is for certain architectures this header file is indirectly included via <asm/tlbflush.h>. However, for others such as 32-bit arm the header is missing and it results in a build failure:
$ make ARCH=arm allmodconfig
[...]
drivers/iommu/iommu-sva.c:340:3: error: call to undeclared function 'mmu_notifier_arch_invalidate_secondary_tlbs' [...]
340 | mmu_notifier_arch_invalidate_secondary_tlbs(iommu_mm->mm, start, end);
| ^Fix this by including the appropriate header file.
--- drivers/iommu/iommu-sva.c | 1 + 1 file changed, 1 insertion(+)
drivers/iommu/iommu-sva.c +1 -0
@@ -3,6 +3,7 @@* Helpers for IOMMU drivers implementing SVA */ #include <linux/mmu_context.h> +#include <linux/mmu_notifier.h> #include <linux/mutex.h> #include <linux/sched/mm.h> #include <linux/iommu.h>
Hi
no regressions here on x86_64 (Intel 11th Gen. CPU)
Thanks
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
6.18.7-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.18.7-rc1rv-g28a73c31d7f5
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.2.1 20260103, GNU ld (GNU Binutils) 2.45.1) #1 SMP PREEMPT_DYNAMIC Thu Jan 22 11:47:11 JST 2026
Thanks
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.18.7-rc1-g28a73c31d7f5 #1 SMP PREEMPT_DYNAMIC Thu Jan 22 05:27:29 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
test_progs, test_progs-no_alu32, test_progs-cpuv4, test_maps, test_verifier in BPF selftests all passes on x86_64.
...
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.18:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 failLinux version: 6.18.7-rc1-g28a73c31d7f5
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Builds successfully. Boots and works on qemu and Intel Core i7-10810U
Thanks,
Brett
Am 21.01.2026 um 19:13 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
However:
Quoted 2 lines
Lorenzo Stoakes <[email protected]>
tools/testing/selftests: add forked (un)/faulted VMA merge tests
These are failing for me on arm64 and I think arm (something literally exploded in my lab so the arm bisect didn't complete yet due to the half of the lab with that board being powered off until I get that fixed), that in turn causes a new top level failure of the merge selftest program but the actual failure is purely newly added tests not working so I don't think the kernel itself is any worse than it was before. The tests are OK in Linus' tree so we are I guess missing a backport?
Log:
https://lava.sirena.org.uk/scheduler/job/2395273#L4133
# # # RUN merge_with_fork.forked.mremap_faulted_to_unfaulted_prev ...
# # # merge.c:1283:mremap_faulted_to_unfaulted_prev:Expected procmap->query.vma_end (281473166635008) == (unsigned long)ptr_b + offset (281473166622720) # # # mremap_faulted_to_unfaulted_prev: Test terminated by assertion
# # # FAIL merge_with_fork.forked.mremap_faulted_to_unfaulted_prev
# # not ok 16 merge_with_fork.forked.mremap_faulted_to_unfaulted_prev
# # # RUN merge_with_fork.forked.mremap_faulted_to_unfaulted_next ...
# # # merge.c:1349:mremap_faulted_to_unfaulted_next:Expected procmap->query.vma_end (281473166635008) == (unsigned long)ptr_a + offset (281473166622720) # # # mremap_faulted_to_unfaulted_next: Test terminated by assertion
# # # FAIL merge_with_fork.forked.mremap_faulted_to_unfaulted_next
# # not ok 17 merge_with_fork.forked.mremap_faulted_to_unfaulted_next
# # # RUN merge_with_fork.forked.mremap_faulted_to_unfaulted_prev_unfaulted_next ...
# # # merge.c:1420:mremap_faulted_to_unfaulted_prev_unfaulted_next:Expected procmap->query.vma_end (281473166647296) == (unsigned long)ptr_a + offset (281473166622720) # # # mremap_faulted_to_unfaulted_prev_unfaulted_next: Test terminated by assertion
# # # FAIL merge_with_fork.forked.mremap_faulted_to_unfaulted_prev_unfaulted_next
# # not ok 18 merge_with_fork.forked.mremap_faulted_to_unfaulted_prev_unfaulted_next
# # # RUN merge_with_fork.forked.mremap_faulted_to_unfaulted_prev_faulted_next ...
# # # merge.c:1495:mremap_faulted_to_unfaulted_prev_faulted_next:Expected procmap->query.vma_start (281473166610432) == (unsigned long)ptr_b (281473166622720) # # # mremap_faulted_to_unfaulted_prev_faulted_next: Test terminated by assertion
# # # FAIL merge_with_fork.forked.mremap_faulted_to_unfaulted_prev_faulted_next
# # not ok 19 merge_with_fork.forked.mremap_faulted_to_unfaulted_prev_faulted_next
Quoted 14 lines · Mark Brown
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Tested-by Mark Brown <[email protected]>However:
Quoted 2 lines
Lorenzo Stoakes <[email protected]>
tools/testing/selftests: add forked (un)/faulted VMA merge tests
Quoted 8 lines
These are failing for me on arm64 and I think arm (something literally exploded in my lab so the arm bisect didn't complete yet due to the half of the lab with that board being powered off until I get that fixed), that in turn causes a new top level failure of the merge selftest program but the actual failure is purely newly added tests not working so I don't think the kernel itself is any worse than it was before. The tests are OK in Linus' tree so we are I guess missing a backport?
Yeah, I wouldn't recommend running these tests as they repro the the bug that the backport fixes :)
You may experience instability as a result of that.
I'm fixing the failed backport to 6.18.y literally right now, should have it out soon.
I guess maybe I should have put a 'please do not take this until previous patch was taken' note in there, but ther we go.
Cheers, Lorenzo
Quoted 29 lines · Lorenzo Stoakes
Quoted 14 lines · Mark Brown
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Tested-by Mark Brown <[email protected]>However:
Quoted 2 lines
Lorenzo Stoakes <[email protected]>
tools/testing/selftests: add forked (un)/faulted VMA merge testsQuoted 8 lines
These are failing for me on arm64 and I think arm (something literally exploded in my lab so the arm bisect didn't complete yet due to the half of the lab with that board being powered off until I get that fixed), that in turn causes a new top level failure of the merge selftest program but the actual failure is purely newly added tests not working so I don't think the kernel itself is any worse than it was before. The tests are OK in Linus' tree so we are I guess missing a backport?
Yeah, I wouldn't recommend running these tests as they repro the the bug that the backport fixes :)
You may experience instability as a result of that.
Quoted 7 lines
I'm fixing the failed backport to 6.18.y literally right now, should have it out soon.
I guess maybe I should have put a 'please do not take this until previous patch was taken' note in there, but ther we go.
Cheers, Lorenzo
FYI the fixes are now sent to stable at
https://lore.kernel.org/stable/f1e305c89aaf15fc62c6160505eb6d19adf5d49b.1769108022.git.lorenzo.stoakes@oracle.com/
Cheers, Lorenzo
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.7-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.
Quoted 5 lines
thanks,
greg k-h
-------------
build and boot report for Linux 6.18.7-rc1.
The kernel was built and booted successfull on both arm64 and x86_64 architectures using the defconfig. Testing was performed in virtual environments,
and the system ran as expected.
No dmesg regressions were found during testing.
Build details:
Architectures: arm64, x86_64
Kernel version: 6.18.7
Configuration: defconfig
Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: 28a73c31d7f5d9d2276c92e1d4891c18a5631e6e
Quoted 8 lines · On Wed, 21 Jan 2026 19:13:48 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.18.7 release. There are 198 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 23 Jan 2026 18:13:40 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
Thanks!
Cheers,
Miguel