- Linux-stable-mirror - lists.linaro.org

[Patch v2 3/4] uio_hv_generic: Adjust ring size according to system page alignment

by longli＠linuxonhyperv.com

From: Long Li <longli(a)microsoft.com> Following the ring header, the ring data should align to system page boundary. Adjust the size if necessary. Cc: stable(a)vger.kernel.org Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Signed-off-by: Long Li <longli(a)microsoft.com> --- drivers/uio/uio_hv_generic.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 08385b04c4ab..dfc5f0e1a254 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -256,6 +256,12 @@ hv_uio_probe(struct hv_device *dev, if (!ring_size) ring_size = SZ_2M; + /* + * Adjust ring size if necessary to have the ring data region page + * aligned + */ + ring_size = VMBUS_RING_SIZE(ring_size); + pdata = devm_kzalloc(&dev->device, sizeof(*pdata), GFP_KERNEL); if (!pdata) return -ENOMEM; -- 2.34.1

2 months

2
1
0 0

[Patch v2 2/4] uio_hv_generic: Use correct size for interrupt and monitor pages

by longli＠linuxonhyperv.com

From: Long Li <longli(a)microsoft.com> Interrupt and monitor pages should be in Hyper-V page size (4k bytes). This can be different to the system page size. This size is read and used by the user-mode program to determine the mapped data region. An example of such user-mode program is the VMBUS driver in DPDK. Cc: stable(a)vger.kernel.org Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus") Signed-off-by: Long Li <longli(a)microsoft.com> --- drivers/uio/uio_hv_generic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 1b19b5647495..08385b04c4ab 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -287,13 +287,13 @@ hv_uio_probe(struct hv_device *dev, pdata->info.mem[INT_PAGE_MAP].name = "int_page"; pdata->info.mem[INT_PAGE_MAP].addr = (uintptr_t)vmbus_connection.int_page; - pdata->info.mem[INT_PAGE_MAP].size = PAGE_SIZE; + pdata->info.mem[INT_PAGE_MAP].size = HV_HYP_PAGE_SIZE; pdata->info.mem[INT_PAGE_MAP].memtype = UIO_MEM_LOGICAL; pdata->info.mem[MON_PAGE_MAP].name = "monitor_page"; pdata->info.mem[MON_PAGE_MAP].addr = (uintptr_t)vmbus_connection.monitor_pages[1]; - pdata->info.mem[MON_PAGE_MAP].size = PAGE_SIZE; + pdata->info.mem[MON_PAGE_MAP].size = HV_HYP_PAGE_SIZE; pdata->info.mem[MON_PAGE_MAP].memtype = UIO_MEM_LOGICAL; if (channel->device_id == HV_NIC) { -- 2.34.1

2 months

2
1
0 0

[PATCH 3/3] HID: wacom: fix kobject reference count leak

by Qasim Ijaz

When sysfs_create_files() fails in wacom_initialize_remotes() the error is returned and the cleanup action will not have been registered yet. As a result the kobject’s refcount is never dropped, so the kobject can never be freed leading to a reference leak. Fix this by calling kobject_put() before returning. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- drivers/hid/wacom_sys.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index 58cbd43a37e9..1257131b1e34 100644 --- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -2059,6 +2059,7 @@ static int wacom_initialize_remotes(struct wacom *wacom) hid_err(wacom->hdev, "cannot create sysfs group err: %d\n", error); kfifo_free(&remote->remote_fifo); + kobject_put(remote->remote_dir); return error; } -- 2.39.5

2 months

1
0
0 0

[PATCH 2/3] HID: wacom: fix memory leak on sysfs attribute creation failure

by Qasim Ijaz

When sysfs_create_files() fails during wacom_initialize_remotes() the fifo buffer is not freed leading to a memory leak. Fix this by calling kfifo_free() before returning. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- drivers/hid/wacom_sys.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index ec5282bc69d6..58cbd43a37e9 100644 --- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -2058,6 +2058,7 @@ static int wacom_initialize_remotes(struct wacom *wacom) if (error) { hid_err(wacom->hdev, "cannot create sysfs group err: %d\n", error); + kfifo_free(&remote->remote_fifo); return error; } -- 2.39.5

2 months

1
0
0 0

[PATCH 1/3] HID: wacom: fix memory leak on kobject creation failure

by Qasim Ijaz

During wacom_initialize_remotes() a fifo buffer is allocated with kfifo_alloc() and later a cleanup action is registered during devm_add_action_or_reset() to clean it up. However if the code fails to create a kobject and register it with sysfs the code simply returns -ENOMEM before the cleanup action is registered leading to a memory leak. Fix this by ensuring the fifo is freed when the kobject creation and registration process fails. Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated") Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> --- drivers/hid/wacom_sys.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index eaf099b2efdb..ec5282bc69d6 100644 --- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -2048,8 +2048,10 @@ static int wacom_initialize_remotes(struct wacom *wacom) remote->remote_dir = kobject_create_and_add("wacom_remote", &wacom->hdev->dev.kobj); - if (!remote->remote_dir) + if (!remote->remote_dir) { + kfifo_free(&remote->remote_fifo); return -ENOMEM; + } error = sysfs_create_files(remote->remote_dir, remote_unpair_attrs); -- 2.39.5

2 months

1
0
0 0

[PATCH v2] iio: Fix scan mask subset check logic

by Fabio Estevam

From: Fabio Estevam <festevam(a)denx.de> Since commit 2718f15403fb ("iio: sanity check available_scan_masks array"), verbose and misleading warnings are printed for devices like the MAX11601: max1363 1-0064: available_scan_mask 8 subset of 0. Never used max1363 1-0064: available_scan_mask 9 subset of 0. Never used max1363 1-0064: available_scan_mask 10 subset of 0. Never used max1363 1-0064: available_scan_mask 11 subset of 0. Never used max1363 1-0064: available_scan_mask 12 subset of 0. Never used max1363 1-0064: available_scan_mask 13 subset of 0. Never used ... [warnings continue] Adding some debug prints show that the mask1 and mask2 indexes are incorrectly computed, leading to wrong array access. These incorrect accesses causes the wrong subset output: iio-core: ******** mask1[0] is 0x1 iio-core: ******** mask2[1] is 0x4 iio-core: ******** mask2[2] is 0x3 iio-core: ******** mask2[3] is 0xf iio-core: ******** mask2[4] is 0x1000 iio-core: ******** mask2[5] is 0x40000 iio-core: ******** mask2[6] is 0x3000 iio-core: ******** mask2[7] is 0x0 iio-core: ******** mask2[8] is 0xffff0000000e2720 max1363 1-0064: available_scan_mask 8 subset of 0. Never used iio-core: ******** mask2[9] is 0xffff0000000e2660 max1363 1-0064: available_scan_mask 9 subset of 0. Never used iio-core: ******** mask2[10] is 0xffff0000000e25a0 max1363 1-0064: available_scan_mask 10 subset of 0. Never used iio-core: ******** mask2[11] is 0xffff0000000e24e0 max1363 1-0064: available_scan_mask 11 subset of 0. Never used iio-core: ******** mask2[12] is 0xffff0000000e2420 max1363 1-0064: available_scan_mask 12 subset of 0. Never used iio-core: ******** mask2[13] is 0xffff0000000e2360 max1363 1-0064: available_scan_mask 13 subset of 0. Never used Fix the available_scan_masks sanity check logic so that it only prints the warning when an element of available_scan_mask is in fact a subset of a previous one. With this fix, the warning output becomes both correct and more informative: max1363 1-0064: Mask 7 (0xc) is a subset of mask 6 (0xf) and will be ignored. Cc: stable(a)vger.kernel.org Fixes: 2718f15403fb ("iio: sanity check available_scan_masks array") Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v1: - Make it a standalone patch. max1363 fix will be sent later. - Keep using bitmap_subset(). - Add more information about the error in the commit log. drivers/iio/industrialio-core.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c index 6a6568d4a2cb..dabfcb50e5fe 100644 --- a/drivers/iio/industrialio-core.c +++ b/drivers/iio/industrialio-core.c @@ -1947,21 +1947,13 @@ static void iio_sanity_check_avail_scan_masks(struct iio_dev *indio_dev) * available masks in the order of preference (presumably the least * costy to access masks first). */ - for (i = 0; i < num_masks - 1; i++) { - const unsigned long *mask1; - int j; - mask1 = av_masks + i * longs_per_mask; - for (j = i + 1; j < num_masks; j++) { - const unsigned long *mask2; - - mask2 = av_masks + j * longs_per_mask; - if (bitmap_subset(mask2, mask1, masklength)) + for (i = 1; i < num_masks; i++) + for (int j = 0; j < i; j++) + if (bitmap_subset(&av_masks[i], &av_masks[j], BITS_PER_LONG)) dev_warn(indio_dev->dev.parent, - "available_scan_mask %d subset of %d. Never used\n", - j, i); - } - } + "Mask %d (0x%lx) is a subset of mask %d (0x%lx) and will be ignored.\n", + i, av_masks[i], j, av_masks[j]); } /** -- 2.34.1

2 months

2
1
0 0

[PATCH] cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode

by Srinivas Pandruvada

When turbo mode is unavailable on a Skylake-X system, executing the command: "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo" results in an unchecked MSR access error: WRMSR to 0x199 (attempted to write 0x0000000100001300). This issue was reproduced on an OEM (Original Equipment Manufacturer) system and is not a common problem across all Skylake-X systems. This error occurs because the MSR 0x199 Turbo Engage Bit (bit 32) is set when turbo mode is disabled. The issue arises when intel_pstate fails to detect that turbo mode is disabled. Here intel_pstate relies on MSR_IA32_MISC_ENABLE bit 38 to determine the status of turbo mode. However, on this system, bit 38 is not set even when turbo mode is disabled. According to the Intel Software Developer's Manual (SDM), the BIOS sets this bit during platform initialization to enable or disable opportunistic processor performance operations. Logically, this bit should be set in such cases. However, the SDM also specifies that "OS and applications must use CPUID leaf 06H to detect processors with opportunistic processor performance operations enabled." Therefore, in addition to checking MSR_IA32_MISC_ENABLE bit 38, verify that CPUID.06H:EAX[1] is 0 to accurately determine if turbo mode is disabled. Fixes: 4521e1a0ce17 ("cpufreq: intel_pstate: Reflect current no_turbo state correctly") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/cpufreq/intel_pstate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index f41ed0b9e610..ba9bf06f1c77 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -598,6 +598,9 @@ static bool turbo_is_disabled(void) { u64 misc_en; + if (!cpu_feature_enabled(X86_FEATURE_IDA)) + return true; + rdmsrl(MSR_IA32_MISC_ENABLE, misc_en); return !!(misc_en & MSR_IA32_MISC_ENABLE_TURBO_DISABLE); -- 2.48.1

2 months

2
1
0 0

[PATCH v1] usb: typec: tcpm: delay SNK_TRY_WAIT_DEBOUNCE to SRC_TRYWAIT transition

by RD Babiera

This patch fixes Type-C Compliance Test TD 4.7.6 - Try.SNK DRP Connect SNKAS. The compliance tester moves into SNK_UNATTACHED during toggling and expects the PUT to apply Rp after tPDDebounce of detection. If the port is in SNK_TRY_WAIT_DEBOUNCE, it will move into SRC_TRYWAIT immediately and apply Rp. This violates TD 4.7.5.V.3, where the tester confirms that the PUT attaches Rp after the transitions to Unattached.SNK for tPDDebounce. Change the tcpm_set_state delay between SNK_TRY_WAIT_DEBOUNCE and SRC_TRYWAIT to tPDDebounce. Fixes: a0a3e04e6b2c ("staging: typec: tcpm: Check for Rp for tPDDebounce") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> Reviewed-by: Badhri Jagan Sridharan <badhri(a)google.com> --- drivers/usb/typec/tcpm/tcpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 784fa23102f9..87d56ac4565d 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -6003,7 +6003,7 @@ static void _tcpm_cc_change(struct tcpm_port *port, enum typec_cc_status cc1, case SNK_TRY_WAIT_DEBOUNCE: if (!tcpm_port_is_sink(port)) { port->max_wait = 0; - tcpm_set_state(port, SRC_TRYWAIT, 0); + tcpm_set_state(port, SRC_TRYWAIT, PD_T_PD_DEBOUNCE); } break; case SRC_TRY_WAIT: base-commit: 615dca38c2eae55aff80050275931c87a812b48c -- 2.49.0.967.g6a0df3ecc3-goog

2 months

2
1
0 0

[PATCH v2] x86/sev: Fix making shared pages private during kdump

by Ashish Kalra

From: Ashish Kalra <ashish.kalra(a)amd.com> When the shared pages are being made private during kdump preparation there are additional checks to handle shared GHCB pages. These additional checks include handling the case of GHCB page being contained within a huge page. There is a bug in this additional check for GHCB page contained within a huge page which causes any shared page just below the per-cpu GHCB getting skipped from being transitioned back to private before kdump preparation which subsequently causes a 0x404 #VC exception when this shared page is accessed later while dumping guest memory during vmcore generation via kdump. Correct the detection and handling of GHCB pages contained within a huge page. Cc: stable(a)vger.kernel.org Fixes: 3074152e56c9 ("x86/sev: Convert shared memory back to private on kexec") Signed-off-by: Ashish Kalra <ashish.kalra(a)amd.com> --- arch/x86/coco/sev/core.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c index 870f4994a13d..ba601ef5242d 100644 --- a/arch/x86/coco/sev/core.c +++ b/arch/x86/coco/sev/core.c @@ -961,7 +961,13 @@ static void unshare_all_memory(void) data = per_cpu(runtime_data, cpu); ghcb = (unsigned long)&data->ghcb_page; - if (addr <= ghcb && ghcb <= addr + size) { + /* Handle the case of a huge page containing the GHCB page */ + if (level == PG_LEVEL_4K && addr == ghcb) { + skipped_addr = true; + break; + } + if (level > PG_LEVEL_4K && addr <= ghcb && + ghcb < addr + size) { skipped_addr = true; break; } @@ -1074,8 +1080,8 @@ static void snp_shutdown_all_aps(void) void snp_kexec_finish(void) { struct sev_es_runtime_data *data; + unsigned long size, mask; unsigned int level, cpu; - unsigned long size; struct ghcb *ghcb; pte_t *pte; @@ -1103,6 +1109,10 @@ void snp_kexec_finish(void) ghcb = &data->ghcb_page; pte = lookup_address((unsigned long)ghcb, &level); size = page_level_size(level); + mask = page_level_mask(level); + /* Handle the case of a huge page containing the GHCB page */ + if (level > PG_LEVEL_4K) + ghcb = (struct ghcb *)((unsigned long)ghcb & mask); set_pte_enc(pte, level, (void *)ghcb); snp_set_memory_private((unsigned long)ghcb, (size / PAGE_SIZE)); } -- 2.34.1

2 months

3
2
0 0

[PATCH AUTOSEL 6.14 01/39] cpufreq: Add SM8650 to cpufreq-dt-platdev blocklist

by Sasha Levin

From: Pengyu Luo <mitltlatltl(a)gmail.com> [ Upstream commit fc5414a4774e14e51a93499a6adfdc45f2de82e0 ] SM8650 have already been supported by qcom-cpufreq-hw driver, but never been added to cpufreq-dt-platdev. This makes noise [ 0.388525] cpufreq-dt cpufreq-dt: failed register driver: -17 [ 0.388537] cpufreq-dt cpufreq-dt: probe with driver cpufreq-dt failed with error -17 So adding it to the cpufreq-dt-platdev driver's blocklist to fix it. Signed-off-by: Pengyu Luo <mitltlatltl(a)gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c index 2aa00769cf09d..a010da0f6337f 100644 --- a/drivers/cpufreq/cpufreq-dt-platdev.c +++ b/drivers/cpufreq/cpufreq-dt-platdev.c @@ -175,6 +175,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "qcom,sm8350", }, { .compatible = "qcom,sm8450", }, { .compatible = "qcom,sm8550", }, + { .compatible = "qcom,sm8650", }, { .compatible = "st,stih407", }, { .compatible = "st,stih410", }, -- 2.39.5

2 months

3
40
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror