November 2024 - Linux-stable-mirror

[PATCH v6 2/8] KVM: SVM: Fix snp_context_create error reporting

by Dionna Glaze

Failure to allocate should not return -ENOTTY. Command failure has multiple possible error modes. Fixes: 136d8bc931c8 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_START command") CC: Sean Christopherson <seanjc(a)google.com> CC: Paolo Bonzini <pbonzini(a)redhat.com> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Ingo Molnar <mingo(a)redhat.com> CC: Borislav Petkov <bp(a)alien8.de> CC: Dave Hansen <dave.hansen(a)linux.intel.com> CC: Ashish Kalra <ashish.kalra(a)amd.com> CC: Tom Lendacky <thomas.lendacky(a)amd.com> CC: John Allen <john.allen(a)amd.com> CC: Herbert Xu <herbert(a)gondor.apana.org.au> CC: "David S. Miller" <davem(a)davemloft.net> CC: Michael Roth <michael.roth(a)amd.com> CC: Luis Chamberlain <mcgrof(a)kernel.org> CC: Russ Weight <russ.weight(a)linux.dev> CC: Danilo Krummrich <dakr(a)redhat.com> CC: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CC: "Rafael J. Wysocki" <rafael(a)kernel.org> CC: Tianfei zhang <tianfei.zhang(a)intel.com> CC: Alexey Kardashevskiy <aik(a)amd.com> CC: stable(a)vger.kernel.org Signed-off-by: Dionna Glaze <dionnaglaze(a)google.com> --- arch/x86/kvm/svm/sev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index 357906375ec59..d0e0152aefb32 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -2171,7 +2171,7 @@ static void *snp_context_create(struct kvm *kvm, struct kvm_sev_cmd *argp) /* Allocate memory for context page */ context = snp_alloc_firmware_page(GFP_KERNEL_ACCOUNT); if (!context) - return NULL; + return ERR_PTR(-ENOMEM); data.address = __psp_pa(context); rc = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_GCTX_CREATE, &data, &argp->error); @@ -2179,7 +2179,7 @@ static void *snp_context_create(struct kvm *kvm, struct kvm_sev_cmd *argp) pr_warn("Failed to create SEV-SNP context, rc %d fw_error %d", rc, argp->error); snp_free_firmware_page(context); - return NULL; + return ERR_PTR(rc); } return context; @@ -2227,8 +2227,8 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) return -EINVAL; sev->snp_context = snp_context_create(kvm, argp); - if (!sev->snp_context) - return -ENOTTY; + if (IS_ERR(sev->snp_context)) + return PTR_ERR(sev->snp_context); start.gctx_paddr = __psp_pa(sev->snp_context); start.policy = params.policy; -- 2.47.0.277.g8800431eea-goog

10 months, 1 week

2
1
0 0

[PATCH 5.4] ftrace: Fix possible use-after-free issue in ftrace_location()

by Hagar Hemdan

From: Zheng Yejian <zhengyejian1(a)huawei.com> commit e60b613df8b6253def41215402f72986fee3fc8d upstream. KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in ftrace_location_range(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). Link: https://lore.kernel.org/linux-trace-kernel/20240509192859.1273558-1-zhengye… Cc: stable(a)vger.kernel.org Cc: <mhiramat(a)kernel.org> Cc: <mark.rutland(a)arm.com> Cc: <mathieu.desnoyers(a)efficios.com> Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization") Suggested-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> [Hagar: Modified to apply on v5.4.y] Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> --- only compile tested. --- kernel/trace/ftrace.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 412505d94865..60bf8a6d55ce 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -1552,7 +1552,9 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) struct ftrace_page *pg; struct dyn_ftrace *rec; struct dyn_ftrace key; + unsigned long ip = 0; + rcu_read_lock(); key.ip = start; key.flags = end; /* overload flags, as it is unsigned long */ @@ -1565,10 +1567,13 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end) sizeof(struct dyn_ftrace), ftrace_cmp_recs); if (rec) - return rec->ip; + { + ip = rec->ip; + break; + } } - - return 0; + rcu_read_unlock(); + return ip; } /** @@ -5736,6 +5741,8 @@ static int ftrace_process_locs(struct module *mod, /* We should have used all pages unless we skipped some */ if (pg_unuse) { WARN_ON(!skipped); + /* Need to synchronize with ftrace_location_range() */ + synchronize_rcu(); ftrace_free_pages(pg_unuse); } return ret; @@ -5889,6 +5896,9 @@ void ftrace_release_mod(struct module *mod) out_unlock: mutex_unlock(&ftrace_lock); + /* Need to synchronize with ftrace_location_range() */ + if (tmp_page) + synchronize_rcu(); for (pg = tmp_page; pg; pg = tmp_page) { /* Needs to be called outside of ftrace_lock */ @@ -6196,6 +6206,7 @@ void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) unsigned long start = (unsigned long)(start_ptr); unsigned long end = (unsigned long)(end_ptr); struct ftrace_page **last_pg = &ftrace_pages_start; + struct ftrace_page *tmp_page = NULL; struct ftrace_page *pg; struct dyn_ftrace *rec; struct dyn_ftrace key; @@ -6239,12 +6250,8 @@ void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) ftrace_update_tot_cnt--; if (!pg->index) { *last_pg = pg->next; - if (pg->records) { - free_pages((unsigned long)pg->records, pg->order); - ftrace_number_of_pages -= 1 << pg->order; - } - ftrace_number_of_groups--; - kfree(pg); + pg->next = tmp_page; + tmp_page = pg; pg = container_of(last_pg, struct ftrace_page, next); if (!(*last_pg)) ftrace_pages = pg; @@ -6261,6 +6268,11 @@ void ftrace_free_mem(struct module *mod, void *start_ptr, void *end_ptr) clear_func_from_hashes(func); kfree(func); } + /* Need to synchronize with ftrace_location_range() */ + if (tmp_page) { + synchronize_rcu(); + ftrace_free_pages(tmp_page); + } } void __init ftrace_free_init_mem(void) -- 2.40.1

10 months, 1 week

3
4
0 0

[PATCH v2 00/12] mwifiex: two fixes and cleanup

by Sascha Hauer

These are a few patches broken out from [1]. Kalle requested to limit the number of patches per series to approximately 12 and Francesco to move the fixes to the front of the series, so here we go. First two patches are fixes. First one is for host mlme support which currently is in wireless-next, so no stable tag needed, second one has a stable tag. The remaining patches except the last one I have chosen to upstream first. I'll continue with the other patches after having this series in shape and merged. The last one is a new patch not included in [1]. Sascha [1] https://lore.kernel.org/all/20240820-mwifiex-cleanup-v1-0-320d8de4a4b7@peng… Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- Changes in v2: - Add refence to 7bff9c974e1a in commit message of "wifi: mwifiex: drop asynchronous init waiting code" - Add extra sentence about bss_started in "wifi: mwifiex: move common settings out of switch/case" - Kill now unused MWIFIEX_BSS_TYPE_ANY - Collect reviewed-by tags from Francesco Dolcini - Link to v1: https://lore.kernel.org/r/20240826-mwifiex-cleanup-1-v1-0-56e6f8e056ec@peng… --- Sascha Hauer (12): wifi: mwifiex: add missing locking wifi: mwifiex: fix MAC address handling wifi: mwifiex: deduplicate code in mwifiex_cmd_tx_rate_cfg() wifi: mwifiex: use adapter as context pointer for mwifiex_hs_activated_event() wifi: mwifiex: drop unnecessary initialization wifi: mwifiex: make region_code_mapping_t const wifi: mwifiex: pass adapter to mwifiex_dnld_cmd_to_fw() wifi: mwifiex: simplify mwifiex_setup_ht_caps() wifi: mwifiex: fix indention wifi: mwifiex: make locally used function static wifi: mwifiex: move common settings out of switch/case wifi: mwifiex: drop asynchronous init waiting code drivers/net/wireless/marvell/mwifiex/cfg80211.c | 38 ++++------ drivers/net/wireless/marvell/mwifiex/cfp.c | 4 +- drivers/net/wireless/marvell/mwifiex/cmdevt.c | 76 +++++++------------- drivers/net/wireless/marvell/mwifiex/decl.h | 1 - drivers/net/wireless/marvell/mwifiex/init.c | 19 ++--- drivers/net/wireless/marvell/mwifiex/main.c | 94 +++++++++---------------- drivers/net/wireless/marvell/mwifiex/main.h | 16 ++--- drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 49 ++++--------- drivers/net/wireless/marvell/mwifiex/txrx.c | 3 +- drivers/net/wireless/marvell/mwifiex/util.c | 22 +----- drivers/net/wireless/marvell/mwifiex/wmm.c | 12 ++-- 11 files changed, 105 insertions(+), 229 deletions(-) --- base-commit: 67a72043aa2e6f60f7bbe7bfa598ba168f16d04f change-id: 20240826-mwifiex-cleanup-1-b5035c7faff6 Best regards, -- Sascha Hauer <s.hauer(a)pengutronix.de>

10 months, 1 week

3
4
0 0

[PATCH v6.1 0/2] uprobe: avoid out-of-bounds memory access of fetching args

by Vamsi Krishna Brahmajosyula

Include additional patch (Andrii Nakryiko) since its a dependency Andrii Nakryiko (1): uprobes: encapsulate preparation of uprobe args buffer Qiao Ma (1): uprobe: avoid out-of-bounds memory access of fetching args kernel/trace/trace_uprobe.c | 86 ++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 40 deletions(-) -- 2.39.4

10 months, 1 week

1
2
0 0

[PATCH RESEND] PM: domains: Fix return value of API dev_pm_get_subsys_data()

by Zijun Hu

From: Zijun Hu <quic_zijuhu(a)quicinc.com> dev_pm_get_subsys_data() has below 2 issues under condition (@dev->power.subsys_data != NULL): - it will do unnecessary kzalloc() and kfree(). - it will return -ENOMEM if the kzalloc() fails, that is wrong since the kzalloc() is not needed. Fixed by not doing kzalloc() and returning 0 for the condition. Fixes: ef27bed1870d ("PM: Reference counting of power.subsys_data") Cc: stable(a)vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- drivers/base/power/common.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c index 8c34ae1cd8d5..13cb1f2a06e7 100644 --- a/drivers/base/power/common.c +++ b/drivers/base/power/common.c @@ -26,6 +26,14 @@ int dev_pm_get_subsys_data(struct device *dev) { struct pm_subsys_data *psd; + spin_lock_irq(&dev->power.lock); + if (dev->power.subsys_data) { + dev->power.subsys_data->refcount++; + spin_unlock_irq(&dev->power.lock); + return 0; + } + spin_unlock_irq(&dev->power.lock); + psd = kzalloc(sizeof(*psd), GFP_KERNEL); if (!psd) return -ENOMEM; --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20241010-fix_dev_pm_get_subsys_data-2478bb200fde Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

10 months, 1 week

2
3
0 0

[PATCH 0/3] driver core: class: Fix bug and code improvements for class APIs

by Zijun Hu

This patch series is to - Fix an potential wild pointer dereference bug for API: class_dev_iter_next() - Improve the following APIs: class_for_each_device() class_find_device() Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Zijun Hu (3): driver core: class: Fix wild pointer dereference in API class_dev_iter_next() driver core: class: Correct WARN() message in APIs class_(for_each|find)_device() driver core: class: Delete a redundant check in APIs class_(for_each|find)_device() drivers/base/class.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- base-commit: 9bd133f05b1dca5ca4399a76d04d0f6f4d454e44 change-id: 20241104-class_fix-f176bd9eba22 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

10 months, 1 week

2
6
0 0

New GaN Wall charger 45W-Sample!

by Vicky

10 months, 1 week

1
0
0 0

[PATCH v2] mm/readahead: Fix large folio support in async readahead

by Yafang Shao

When testing large folio support with XFS on our servers, we observed that only a few large folios are mapped when reading large files via mmap. After a thorough analysis, I identified it was caused by the `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this parameter is set to 128KB. After I tune it to 2MB, the large folio can work as expected. However, I believe the large folio behavior should not be dependent on the value of read_ahead_kb. It would be more robust if the kernel can automatically adopt to it. With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a sequential read on a 1GB file using MADV_HUGEPAGE, the differences in /proc/meminfo are as follows: - before this patch FileHugePages: 18432 kB FilePmdMapped: 4096 kB - after this patch FileHugePages: 1067008 kB FilePmdMapped: 1048576 kB This shows that after applying the patch, the entire 1GB file is mapped to huge pages. The stable list is CCed, as without this patch, large folios don’t function optimally in the readahead path. It's worth noting that if read_ahead_kb is set to a larger value that isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail to map to hugepages. Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Suggested-by: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: stable(a)vger.kernel.org --- mm/readahead.c | 2 ++ 1 file changed, 2 insertions(+) Changes: v1->v2: - Drop the align (Matthew) - Improve commit log (Andrew) RFC->v1: https://lore.kernel.org/linux-mm/20241106092114.8408-1-laoar.shao@gmail.com/ - Simplify the code as suggested by Matthew RFC: https://lore.kernel.org/linux-mm/20241104143015.34684-1-laoar.shao@gmail.co… diff --git a/mm/readahead.c b/mm/readahead.c index 3dc6c7a128dd..9b8a48e736c6 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -385,6 +385,8 @@ static unsigned long get_next_ra_size(struct file_ra_state *ra, return 4 * cur; if (cur <= max / 2) return 2 * cur; + if (cur > max) + return cur; return max; } -- 2.43.5

10 months, 1 week

3
16
0 0

[PATCH] accel/ivpu: Fix Qemu crash when running in passthrough

by Jacek Lawrynowicz

Restore PCI state after putting the NPU in D0. Restoring state before powering up the device caused a Qemu crash if NPU was running in passthrough mode and recovery was performed. Fixes: 3534eacbf101 ("accel/ivpu: Fix PCI D0 state entry in resume") Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz(a)linux.intel.com> Reviewed-by: Karol Wachowski <karol.wachowski(a)linux.intel.com> --- drivers/accel/ivpu/ivpu_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c index 59d3170f5e354..5aac3d64045d3 100644 --- a/drivers/accel/ivpu/ivpu_pm.c +++ b/drivers/accel/ivpu/ivpu_pm.c @@ -73,8 +73,8 @@ static int ivpu_resume(struct ivpu_device *vdev) int ret; retry: - pci_restore_state(to_pci_dev(vdev->drm.dev)); pci_set_power_state(to_pci_dev(vdev->drm.dev), PCI_D0); + pci_restore_state(to_pci_dev(vdev->drm.dev)); ret = ivpu_hw_power_up(vdev); if (ret) { -- 2.45.1

10 months, 1 week

1
1
0 0

[PATCH] iov_iter: fix copy_page_from_iter_atomic() for highmem

by Christian Brauner

When fixing copy_page_from_iter_atomic() in c749d9b7ebbc ("iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP") the check for PageHighMem() got moved out of the loop. If copy_page_from_iter_atomic() crosses page boundaries it will use a stale PageHighMem() check for an earlier page. Fixes: 908a1ad89466 ("iov_iter: Handle compound highmem pages in copy_page_from_iter_atomic()") Fixes: c749d9b7ebbc ("iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP") Cc: stable(a)vger.kernel.org Reviewed-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Christian Brauner <brauner(a)kernel.org> --- Hey Linus, I think the original fix was buggy but then again my knowledge of highmem isn't particularly detailed. Compile tested only. If correct, I would ask you to please apply it directly. Thanks! Christian --- lib/iov_iter.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 908e75a28d90..e90a5ababb11 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -457,12 +457,16 @@ size_t iov_iter_zero(size_t bytes, struct iov_iter *i) } EXPORT_SYMBOL(iov_iter_zero); +static __always_inline bool iter_atomic_uses_kmap(struct page *page) +{ + return IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP) || + PageHighMem(page); +} + size_t copy_page_from_iter_atomic(struct page *page, size_t offset, size_t bytes, struct iov_iter *i) { size_t n, copied = 0; - bool uses_kmap = IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP) || - PageHighMem(page); if (!page_copy_sane(page, offset, bytes)) return 0; @@ -473,7 +477,7 @@ size_t copy_page_from_iter_atomic(struct page *page, size_t offset, char *p; n = bytes - copied; - if (uses_kmap) { + if (iter_atomic_uses_kmap(page)) { page += offset / PAGE_SIZE; offset %= PAGE_SIZE; n = min_t(size_t, n, PAGE_SIZE - offset); @@ -484,7 +488,7 @@ size_t copy_page_from_iter_atomic(struct page *page, size_t offset, kunmap_atomic(p); copied += n; offset += n; - } while (uses_kmap && copied != bytes && n > 0); + } while (iter_atomic_uses_kmap(page) && copied != bytes && n > 0); return copied; } -- 2.45.2

10 months, 1 week

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024