March 2024 - Linux-stable-mirror

[PATCH v5 0/4] Disable automatic load CCS load balancing

by Andi Shyti

Hi, this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Assigns all the CCS slices to one single user engine. The user will then be able to query only one CCS engine In this v5 I have created a new file, gt/intel_gt_ccs_mode.c where I added the intel_gt_apply_ccs_mode(). In the upcoming patches, this file will contain the implementation for dynamic CCS mode setting. I saw also necessary the creation of a new mechanism fro looping through engines in order to exclude the CCS's that are merged into one single stream. It's called for_each_available_engine() and I started using it in the hangcheck sefltest. I might still need to iterate a few CI runs in order to cover more cases when this call is needed. I'm using here the "Requires: " tag, but I'm not sure the commit id will be valid, on the other hand, I don't know what commit id I should use. Thanks Tvrtko, Matt, John and Joonas for your reviews! Andi Changelog ========= v4 -> v5 - Use the workaround framework to do all the CCS balancing settings in order to always apply the modes also when the engine resets. Put everything in its own specific function to be executed for the first CCS engine encountered. (Thanks Matt) - Calculate the CCS ID for the CCS mode as the first available CCS among all the engines (Thanks Matt) - create the intel_gt_ccs_mode.c function to host the CCS configuration. We will have it ready for the next series. - Fix a selftest that was failing because could not set CCS2. - Add the for_each_available_engine() macro to exclude CCS1+ and start using it in the hangcheck selftest. v3 -> v4 - Reword correctly the comment in the workaround - Fix a buffer overflow (Thanks Joonas) - Handle properly the fused engines when setting the CCS mode. v2 -> v3 - Simplified the algorithm for creating the list of the exported uabi engines. (Patch 1) (Thanks, Tvrtko) - Consider the fused engines when creating the uabi engine list (Patch 2) (Thanks, Matt) - Patch 4 now uses a the refactoring from patch 1, in a cleaner outcome. v1 -> v2 - In Patch 1 use the correct workaround number (thanks Matt). - In Patch 2 do not add the extra CCS engines to the exposed UABI engine list and adapt the engine counting accordingly (thanks Tvrtko). - Reword the commit of Patch 2 (thanks John). Andi Shyti (4): drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Refactor uabi engine class/instance list creation drm/i915/gt: Disable tests for CCS engines beyond the first drm/i915/gt: Enable only one CCS for compute workload drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_engine_user.c | 40 ++++++++++++++------ drivers/gpu/drm/i915/gt/intel_gt.h | 13 +++++++ drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 39 +++++++++++++++++++ drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 13 +++++++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 30 ++++++++++++++- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 22 +++++------ 8 files changed, 139 insertions(+), 25 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h -- 2.43.0

12 months

3
9
0 0

[PATCH 1/2] dlm: fix user space lkb refcounting

by Alexander Aring

This patch fixes to check on the right return value if it was the last callback. The rv variable got overwritten by the return of copy_result_to_user(). Fixing it by introducing a second variable for the return value and don't let rv being overwritten. Cc: stable(a)vger.kernel.org Fixes: 61bed0baa4db ("fs: dlm: use a non-static queue for callbacks") Reported-by: Valentin Vidić <vvidic(a)valentin-vidic.from.hr> Closes: https://lore.kernel.org/gfs2/Ze4qSvzGJDt5yxC3@valentin-vidic.from.hr Signed-off-by: Alexander Aring <aahringo(a)redhat.com> --- fs/dlm/user.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/dlm/user.c b/fs/dlm/user.c index 695e691b38b3..9f9b68448830 100644 --- a/fs/dlm/user.c +++ b/fs/dlm/user.c @@ -806,7 +806,7 @@ static ssize_t device_read(struct file *file, char __user *buf, size_t count, struct dlm_lkb *lkb; DECLARE_WAITQUEUE(wait, current); struct dlm_callback *cb; - int rv, copy_lvb = 0; + int rv, ret, copy_lvb = 0; int old_mode, new_mode; if (count == sizeof(struct dlm_device_version)) { @@ -906,9 +906,9 @@ static ssize_t device_read(struct file *file, char __user *buf, size_t count, trace_dlm_ast(lkb->lkb_resource->res_ls, lkb); } - rv = copy_result_to_user(lkb->lkb_ua, - test_bit(DLM_PROC_FLAGS_COMPAT, &proc->flags), - cb->flags, cb->mode, copy_lvb, buf, count); + ret = copy_result_to_user(lkb->lkb_ua, + test_bit(DLM_PROC_FLAGS_COMPAT, &proc->flags), + cb->flags, cb->mode, copy_lvb, buf, count); kref_put(&cb->ref, dlm_release_callback); @@ -916,7 +916,7 @@ static ssize_t device_read(struct file *file, char __user *buf, size_t count, if (rv == DLM_DEQUEUE_CALLBACK_LAST) dlm_put_lkb(lkb); - return rv; + return ret; } static __poll_t device_poll(struct file *file, poll_table *wait) -- 2.43.0

12 months

2
2
0 0

[PATCH 0/4] RFDS backport 6.8.y

by Pawan Gupta

This is a backport of recently upstreamed mitigation of a CPU vulnerability Register File Data Sampling (RFDS) (CVE-2023-28746). It has a dependency on "Delay VERW" series which is already present in v6.8. v6.8 just got released so the backport was very smooth. Cc: Sasha Levin <sashal(a)kernel.org> To: stable(a)vger.kernel.org Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> --- Pawan Gupta (4): x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set Documentation/hw-vuln: Add documentation for RFDS x86/rfds: Mitigate Register File Data Sampling (RFDS) KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../admin-guide/hw-vuln/reg-file-data-sampling.rst | 104 +++++++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 21 +++++ arch/x86/Kconfig | 11 +++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 8 ++ arch/x86/kernel/cpu/bugs.c | 92 +++++++++++++++++- arch/x86/kernel/cpu/common.c | 38 +++++++- arch/x86/kvm/x86.c | 5 +- drivers/base/cpu.c | 3 + include/linux/cpu.h | 2 + 12 files changed, 278 insertions(+), 9 deletions(-) --- base-commit: e8f897f4afef0031fe618a8e94127a0934896aba change-id: 20240312-rfds-backport-6-8-y-d67dcdfe4e51 Best regards, -- Thanks, Pawan

12 months

2
5
0 0

[PATCH 0/4] RFDS backport 6.1.y

by Pawan Gupta

This is a backport of recently upstreamed mitigation of a CPU vulnerability Register File Data Sampling (RFDS) (CVE-2023-28746). It has a dependency on "Delay VERW" series which is already backported and merged in linux-6.1.y. - There was a minor conflict for patch 2/4 in Documentation index. - There were many easy to resolve conflicts in patch 3/4 related to sysfs reporting. - s/ATOM_GRACEMONT/ALDERLAKE_N/ - ATOM_GRACEMONT is called ALDERLAKE_N in 6.6. Cc: Sasha Levin <sashal(a)kernel.org> To: stable(a)vger.kernel.org Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> --- Pawan Gupta (4): x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set Documentation/hw-vuln: Add documentation for RFDS x86/rfds: Mitigate Register File Data Sampling (RFDS) KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../admin-guide/hw-vuln/reg-file-data-sampling.rst | 104 +++++++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 21 +++++ arch/x86/Kconfig | 11 +++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 8 ++ arch/x86/kernel/cpu/bugs.c | 92 +++++++++++++++++- arch/x86/kernel/cpu/common.c | 38 +++++++- arch/x86/kvm/x86.c | 5 +- drivers/base/cpu.c | 8 ++ include/linux/cpu.h | 2 + 12 files changed, 283 insertions(+), 9 deletions(-) --- base-commit: 61adba85cc40287232a539e607164f273260e0fe change-id: 20240312-rfds-backport-6-1-y-d17ecf8c1ec5 Best regards, -- Thanks, Pawan

12 months

1
4
0 0

[PATCH 0/4] RFDS backport 6.6.y

by Pawan Gupta

This is a backport of recently upstreamed mitigation of a CPU vulnerability Register File Data Sampling (RFDS) (CVE-2023-28746). It has a dependency on "Delay VERW" series which is already backported and merged in linux-6.6.y. There were no hiccups in backporting this. Cc: Sasha Levin <sashal(a)kernel.org> To: stable(a)vger.kernel.org Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> --- Pawan Gupta (4): x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set Documentation/hw-vuln: Add documentation for RFDS x86/rfds: Mitigate Register File Data Sampling (RFDS) KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../admin-guide/hw-vuln/reg-file-data-sampling.rst | 104 +++++++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 21 +++++ arch/x86/Kconfig | 11 +++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 8 ++ arch/x86/kernel/cpu/bugs.c | 92 +++++++++++++++++- arch/x86/kernel/cpu/common.c | 38 +++++++- arch/x86/kvm/x86.c | 5 +- drivers/base/cpu.c | 3 + include/linux/cpu.h | 2 + 12 files changed, 278 insertions(+), 9 deletions(-) --- base-commit: 62e5ae5007ef14cf9b12da6520d50fe90079d8d4 change-id: 20240312-rfds-backport-6-6-y-e1425616b52a Best regards, -- Thanks, Pawan

12 months

1
4
0 0

[PATCH 0/4] RFDS backport 6.7.y

by Pawan Gupta

This is a backport of recently upstreamed mitigation of a CPU vulnerability Register File Data Sampling (RFDS) (CVE-2023-28746). It has a dependency on "Delay VERW" series which is already backported and merged in linux-6.7.y. There were no hiccups in backporting this. Cc: Sasha Levin <sashal(a)kernel.org> To: stable(a)vger.kernel.org Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> --- Pawan Gupta (4): x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set Documentation/hw-vuln: Add documentation for RFDS x86/rfds: Mitigate Register File Data Sampling (RFDS) KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../admin-guide/hw-vuln/reg-file-data-sampling.rst | 104 +++++++++++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 21 +++++ arch/x86/Kconfig | 11 +++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 8 ++ arch/x86/kernel/cpu/bugs.c | 92 +++++++++++++++++- arch/x86/kernel/cpu/common.c | 38 +++++++- arch/x86/kvm/x86.c | 5 +- drivers/base/cpu.c | 3 + include/linux/cpu.h | 2 + 12 files changed, 278 insertions(+), 9 deletions(-) --- base-commit: 2e7cdd29fc42c410eab52fffe5710bf656619222 change-id: 20240312-rfds-backport-6-7-y-4fbe3fc5366a Best regards, -- Thanks, Pawan

12 months

1
4
0 0

Re: [PATCH v4 0/9] x86/sev: KEXEC/KDUMP support for SEV-ES guests

by Tom Lendacky

On 3/11/24 15:32, Vasant k wrote: > Hi Tom, > > Right, it just escaped my mind that the SNP uses the secrets page > to hand over APs to the next stage. I will correct that in the next Not quite... The MADT table lists the APs and the GHCB AP Create NAE event is used to start the APs. Thanks, Tom > version. Please let me know if you have any corrections or improvement > suggestions on the rest of the patchset. > > Thanks, > Vasant >

12 months

2
2
0 0

INVESTMENT PROPOSAL

by Howard＠web.codeaurora.org

Good day, Our investors are exploring all possibilities to initiate change on a massive scale of investment opportunities, We offer personal, business, loans at a fixed interest rate of 2% per annum. Regards Howard Ethan Financial Advisor

12 months

1
0
0 0

+ memtest-use-readwrite_once-in-memory-scanning.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: memtest: use {READ,WRITE}_ONCE in memory scanning has been added to the -mm mm-unstable branch. Its filename is memtest-use-readwrite_once-in-memory-scanning.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Qiang Zhang <qiang4.zhang(a)intel.com> Subject: memtest: use {READ,WRITE}_ONCE in memory scanning Date: Tue, 12 Mar 2024 16:04:23 +0800 memtest failed to find bad memory when compiled with clang. So use {WRITE,READ}_ONCE to access memory to avoid compiler over optimization. Link: https://lkml.kernel.org/r/20240312080422.691222-1-qiang4.zhang@intel.com Signed-off-by: Qiang Zhang <qiang4.zhang(a)intel.com> Cc: Bill Wendling <morbo(a)google.com> Cc: Justin Stitt <justinstitt(a)google.com> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: Nick Desaulniers <ndesaulniers(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memtest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/memtest.c~memtest-use-readwrite_once-in-memory-scanning +++ a/mm/memtest.c @@ -51,10 +51,10 @@ static void __init memtest(u64 pattern, last_bad = 0; for (p = start; p < end; p++) - *p = pattern; + WRITE_ONCE(*p, pattern); for (p = start; p < end; p++, start_phys_aligned += incr) { - if (*p == pattern) + if (READ_ONCE(*p) == pattern) continue; if (start_phys_aligned == last_bad + incr) { last_bad += incr; _ Patches currently in -mm which might be from qiang4.zhang(a)intel.com are memtest-use-readwrite_once-in-memory-scanning.patch

12 months

1
0
0 0

[PATCH v2 1/2] ring-buffer: Fix full_waiters_pending in poll

by Steven Rostedt

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> If a reader of the ring buffer is doing a poll, and waiting for the ring buffer to hit a specific watermark, there could be a case where it gets into an infinite ping-pong loop. The poll code has: rbwork->full_waiters_pending = true; if (!cpu_buffer->shortest_full || cpu_buffer->shortest_full > full) cpu_buffer->shortest_full = full; The writer will see full_waiters_pending and check if the ring buffer is filled over the percentage of the shortest_full value. If it is, it calls an irq_work to wake up all the waiters. But the code could get into a circular loop: CPU 0 CPU 1 ----- ----- [ Poll ] [ shortest_full = 0 ] rbwork->full_waiters_pending = true; if (rbwork->full_waiters_pending && [ buffer percent ] > shortest_full) { rbwork->wakeup_full = true; [ queue_irqwork ] cpu_buffer->shortest_full = full; [ IRQ work ] if (rbwork->wakeup_full) { cpu_buffer->shortest_full = 0; wakeup poll waiters; [woken] if ([ buffer percent ] > full) break; rbwork->full_waiters_pending = true; if (rbwork->full_waiters_pending && [ buffer percent ] > shortest_full) { rbwork->wakeup_full = true; [ queue_irqwork ] cpu_buffer->shortest_full = full; [ IRQ work ] if (rbwork->wakeup_full) { cpu_buffer->shortest_full = 0; wakeup poll waiters; [woken] [ Wash, rinse, repeat! ] In the poll, the shortest_full needs to be set before the full_pending_waiters, as once that is set, the writer will compare the current shortest_full (which is incorrect) to decide to call the irq_work, which will reset the shortest_full (expecting the readers to update it). Also move the setting of full_waiters_pending after the check if the ring buffer has the required percentage filled. There's no reason to tell the writer to wake up waiters if there are no waiters. Cc: stable(a)vger.kernel.org Fixes: 42fb0a1e84ff5 ("tracing/ring-buffer: Have polling block on watermark") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index aa332ace108b..adfe603a769b 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -964,16 +964,32 @@ __poll_t ring_buffer_poll_wait(struct trace_buffer *buffer, int cpu, poll_wait(filp, &rbwork->full_waiters, poll_table); raw_spin_lock_irqsave(&cpu_buffer->reader_lock, flags); - rbwork->full_waiters_pending = true; if (!cpu_buffer->shortest_full || cpu_buffer->shortest_full > full) cpu_buffer->shortest_full = full; raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags); - } else { - poll_wait(filp, &rbwork->waiters, poll_table); - rbwork->waiters_pending = true; + if (full_hit(buffer, cpu, full)) + return EPOLLIN | EPOLLRDNORM; + /* + * Only allow full_waiters_pending update to be seen after + * the shortest_full is set. If the writer sees the + * full_waiters_pending flag set, it will compare the + * amount in the ring buffer to shortest_full. If the amount + * in the ring buffer is greater than the shortest_full + * percent, it will call the irq_work handler to wake up + * this list. The irq_handler will reset shortest_full + * back to zero. That's done under the reader_lock, but + * the below smp_mb() makes sure that the update to + * full_waiters_pending doesn't leak up into the above. + */ + smp_mb(); + rbwork->full_waiters_pending = true; + return 0; } + poll_wait(filp, &rbwork->waiters, poll_table); + rbwork->waiters_pending = true; + /* * There's a tight race between setting the waiters_pending and * checking if the ring buffer is empty. Once the waiters_pending bit @@ -989,9 +1005,6 @@ __poll_t ring_buffer_poll_wait(struct trace_buffer *buffer, int cpu, */ smp_mb(); - if (full) - return full_hit(buffer, cpu, full) ? EPOLLIN | EPOLLRDNORM : 0; - if ((cpu == RING_BUFFER_ALL_CPUS && !ring_buffer_empty(buffer)) || (cpu != RING_BUFFER_ALL_CPUS && !ring_buffer_empty_cpu(buffer, cpu))) return EPOLLIN | EPOLLRDNORM; -- 2.43.0

12 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024