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

Backport rcu-tasks fix to stable kernel version 6.6.y

by Tahera Fahimi

Dear Stable Kernel Maintainers, I am writing to request the backport of the following patches to stable kernel versions 6.6.y, addressing a deadlock issue in RCU Tasks related to do_exit() on preemptible systems. Issue Description: The kernel may experience deadlocks due to shared locking between exit_tasks_rcu_start() and rcu_tasks_postscan() via synchronize_srcu(), when multiple processes exit concurrently. The problem manifests as stalls in the RCU tasks grace period. This issue manifest as a deadlock in WSL kernel which uses the stable kernel 6.6.87 (Please see the issue on https://github.com/microsoft/WSL/issues/13480) Patches to Apply: Patch 1: Subject: rcu-tasks: Maintain lists to eliminate RCU-tasks/do_exit() deadlocks Commit ID: 6b70399f9ef3809f6e308fd99dd78b072c1bd05c Justification: Introduces per-CPU lists for exiting tasks, replacing SRCU-based waits and eliminating deadlocks during concurrent exits. Patch 2: Subject: rcu-tasks: Eliminate deadlocks involving do_exit() and RCU tasks Commit ID: 1612160b91272f5b1596f499584d6064bf5be794 Justification: Ensures all exiting tasks are properly gathered and synchronized, preventing missed synchronizations and further deadlocks. Patch 3: Subject: rcu-tasks: Maintain real-time response in rcu_tasks_postscan() Commit ID: 0bb11a372fc8d7006b4d0f42a2882939747bdbff Justification: Periodically enables interrupts during per-CPU list traversal to maintain system responsiveness, especially when many tasks are present. Kernel version: latest kernel version in 6.6.y branch Thank you for your consideration. Best regards, Tahera Fahimi

1 month, 1 week

2
1
0 0

[PATCH v3 0/4 5.10.y] overflow: Allow mixed type arguments in overflow macros

by Eliav Farber

This series backports four commits to bring include/linux/overflow.h in line with v5.15.193: - 4578be130a64 ("overflow: Correct check_shl_overflow() comment") - 4eb6bd55cfb2 ("compiler.h: drop fallback overflow checkers") - 53f2cd86a81c ("overflow: Allow mixed type arguments") - ed6e37e30826 ("tracing: Define the is_signed_type() macro once") The motivation is to fix build failures such as: drivers/net/ethernet/intel/e1000e/ethtool.c: In function ‘e1000_set_eeprom’: ./include/linux/overflow.h:71:15: error: comparison of distinct pointer types lacks a cast [-Werror] 71 | (void) (&__a == __d); \ | ^~ drivers/net/ethernet/intel/e1000e/ethtool.c:582:6: note: in expansion of macro ‘check_add_overflow’ 582 | if (check_add_overflow(eeprom->offset, eeprom->len, &total_len) || | ^~~~~~~~~~~~~~~~~~ This regression was triggered by commit ce8829d3d44b ("e1000e: fix heap overflow in e1000_set_eeprom"). check_add_overflow() requires the first two operands and the result pointer to be of identical type. On 64-bit builds, using size_t for the result conflicted with the u32 fields eeprom->offset and eeprom->len, resulting in type check failures. Bart Van Assche (1): tracing: Define the is_signed_type() macro once Kees Cook (1): overflow: Allow mixed type arguments Keith Busch (1): overflow: Correct check_shl_overflow() comment Nick Desaulniers (1): compiler.h: drop fallback overflow checkers include/linux/compiler-clang.h | 13 -- include/linux/compiler-gcc.h | 4 - include/linux/compiler.h | 6 + include/linux/overflow.h | 209 ++++++----------------------- include/linux/trace_events.h | 2 - tools/include/linux/compiler-gcc.h | 4 - tools/include/linux/overflow.h | 140 +------------------ 7 files changed, 52 insertions(+), 326 deletions(-) --- Changes in v3: - Fixed SHA1 of commits mentioned in cover letter Changes in v2: - Added missing sign-off in all patches -- 2.47.3

1 month, 1 week

2
5
0 0

[PATCH] comedi: fix divide-by-zero in comedi_buf_munge()

by Deepanshu Kartikey

The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands. Reported-by: syzbot+f6c3c066162d2c43a66c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f6c3c066162d2c43a66c Cc: stable(a)vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- drivers/comedi/comedi_buf.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/comedi/comedi_buf.c b/drivers/comedi/comedi_buf.c index 002c0e76baff..786f888299ce 100644 --- a/drivers/comedi/comedi_buf.c +++ b/drivers/comedi/comedi_buf.c @@ -321,6 +321,11 @@ static unsigned int comedi_buf_munge(struct comedi_subdevice *s, async->munge_count += num_bytes; return num_bytes; } + + if (async->cmd.chanlist_len == 0) { + async->munge_count += num_bytes; + return num_bytes; + } /* don't munge partial samples */ num_bytes -= num_bytes % num_sample_bytes; -- 2.43.0

1 month, 1 week

1
0
0 0

[PATCH] crypto: atmel - Fix dma_unmap_sg() direction

by Thomas Fourier

It seems like everywhere in this file, dd->in_sg is mapped with DMA_TO_DEVICE and dd->out_sg is mapped with DMA_FROM_DEVICE. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas(a)gmail.com> --- drivers/crypto/atmel-tdes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c index 098f5532f389..3b2a92029b16 100644 --- a/drivers/crypto/atmel-tdes.c +++ b/drivers/crypto/atmel-tdes.c @@ -512,7 +512,7 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd) if (err && (dd->flags & TDES_FLAGS_FAST)) { dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE); - dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_TO_DEVICE); + dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_FROM_DEVICE); } return err; -- 2.43.0

1 month, 1 week

2
1
0 0

[PATCH] crypto: rockchip - Fix dma_unmap_sg() nents value

by Thomas Fourier

The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 57d67c6e8219 ("crypto: rockchip - rework by using crypto_engine") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas(a)gmail.com> --- drivers/crypto/rockchip/rk3288_crypto_ahash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/rockchip/rk3288_crypto_ahash.c b/drivers/crypto/rockchip/rk3288_crypto_ahash.c index d6928ebe9526..b9f5a8b42e66 100644 --- a/drivers/crypto/rockchip/rk3288_crypto_ahash.c +++ b/drivers/crypto/rockchip/rk3288_crypto_ahash.c @@ -254,7 +254,7 @@ static void rk_hash_unprepare(struct crypto_engine *engine, void *breq) struct rk_ahash_rctx *rctx = ahash_request_ctx(areq); struct rk_crypto_info *rkc = rctx->dev; - dma_unmap_sg(rkc->dev, areq->src, rctx->nrsg, DMA_TO_DEVICE); + dma_unmap_sg(rkc->dev, areq->src, sg_nents(areq->src), DMA_TO_DEVICE); } static int rk_hash_run(struct crypto_engine *engine, void *breq) -- 2.43.0

1 month, 1 week

2
1
0 0

+ mm-hugetlb-fix-folio-is-still-mapped-when-deleted.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/hugetlb: fix folio is still mapped when deleted has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-hugetlb-fix-folio-is-still-mapped-when-deleted.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-hotfixes-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: Jinjiang Tu <tujinjiang(a)huawei.com> Subject: mm/hugetlb: fix folio is still mapped when deleted Date: Fri, 12 Sep 2025 15:41:39 +0800 Migration may be raced with fallocating hole. remove_inode_single_folio will unmap the folio if the folio is still mapped. However, it's called without folio lock. If the folio is migrated and the mapped pte has been converted to migration entry, folio_mapped() returns false, and won't unmap it. Due to extra refcount held by remove_inode_single_folio, migration fails, restores migration entry to normal pte, and the folio is mapped again. As a result, we triggered BUG in filemap_unaccount_folio. The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380 Hold folio lock before checking if the folio is mapped to avold race with migration. Link: https://lkml.kernel.org/r/20250912074139.3575005-1-tujinjiang@huawei.com Fixes: 4aae8d1c051e ("mm/hugetlbfs: unmap pages if page fault raced with hole punch") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/hugetlbfs/inode.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/fs/hugetlbfs/inode.c~mm-hugetlb-fix-folio-is-still-mapped-when-deleted +++ a/fs/hugetlbfs/inode.c @@ -517,14 +517,16 @@ static bool remove_inode_single_folio(st /* * If folio is mapped, it was faulted in after being - * unmapped in caller. Unmap (again) while holding - * the fault mutex. The mutex will prevent faults - * until we finish removing the folio. + * unmapped in caller or hugetlb_vmdelete_list() skips + * unmapping it due to fail to grab lock. Unmap (again) + * while holding the fault mutex. The mutex will prevent + * faults until we finish removing the folio. Hold folio + * lock to guarantee no concurrent migration. */ + folio_lock(folio); if (unlikely(folio_mapped(folio))) hugetlb_unmap_file_folio(h, mapping, folio, index); - folio_lock(folio); /* * We must remove the folio from page cache before removing * the region/ reserve map (hugetlb_unreserve_pages). In _ Patches currently in -mm which might be from tujinjiang(a)huawei.com are mm-hugetlb-fix-folio-is-still-mapped-when-deleted.patch filemap-optimize-folio-refount-update-in-filemap_map_pages.patch

1 month, 1 week

1
0
0 0

[PATH 6.6.y] KVM: SVM: Set synthesized TSA CPUID flags

by Boris Ostrovsky

From: "Borislav Petkov (AMD)" <bp(a)alien8.de> Commit f3f9deccfc68a6b7c8c1cc51e902edba23d309d4 LTS VERW_CLEAR is supposed to be set only by the hypervisor to denote TSA mitigation support to a guest. SQ_NO and L1_NO are both synthesizable, and are going to be set by hw CPUID on future machines. So keep the kvm_cpu_cap_init_kvm_defined() invocation *and* set them when synthesized. This fix is stable-only. Co-developed-by: Jinpu Wang <jinpu.wang(a)ionos.com> Signed-off-by: Jinpu Wang <jinpu.wang(a)ionos.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> # 6.6.y Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> --- arch/x86/kvm/cpuid.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 288db3516772..2c0bc6a93ec3 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -791,10 +791,15 @@ void kvm_set_cpu_caps(void) F(PERFMON_V2) ); + kvm_cpu_cap_check_and_set(X86_FEATURE_VERW_CLEAR); + kvm_cpu_cap_init_kvm_defined(CPUID_8000_0021_ECX, F(TSA_SQ_NO) | F(TSA_L1_NO) ); + kvm_cpu_cap_check_and_set(X86_FEATURE_TSA_SQ_NO); + kvm_cpu_cap_check_and_set(X86_FEATURE_TSA_L1_NO); + /* * Synthesize "LFENCE is serializing" into the AMD-defined entry in * KVM's supported CPUID if the feature is reported as supported by the -- 2.43.5

1 month, 1 week

1
0
0 0

[PATCH 6.1.y 0/3] Fix TSA CPUID management in KVM

by Boris Ostrovsky

Backport of AMD's TSA mitigation to 6.1.y did not set CPUID bits that are passed to a guest correctly (commit c334ae4a545a "KVM: SVM: Advertise TSA CPUID bits to guests") Boris Ostrovsky (1): KVM: SVM: Return TSA_SQ_NO and TSA_L1_NO bits in __do_cpuid_func() Borislav Petkov (AMD) (1): KVM: SVM: Set synthesized TSA CPUID flags Kim Phillips (1): KVM: x86: Move open-coded CPUID leaf 0x80000021 EAX bit propagation code arch/x86/kvm/cpuid.c | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) -- 2.43.5

1 month, 1 week

1
3
0 0

[to-be-updated] memcg-dont-wait-writeback-completion-when-release-memcg.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: memcg: don't wait writeback completion when release memcg has been removed from the -mm tree. Its filename was memcg-dont-wait-writeback-completion-when-release-memcg.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Julian Sun <sunjunchao(a)bytedance.com> Subject: memcg: don't wait writeback completion when release memcg Date: Thu, 28 Aug 2025 04:45:57 +0800 Recently, we encountered the following hung task: INFO: task kworker/4:1:1334558 blocked for more than 1720 seconds. [Wed Jul 30 17:47:45 2025] Workqueue: cgroup_destroy css_free_rwork_fn [Wed Jul 30 17:47:45 2025] Call Trace: [Wed Jul 30 17:47:45 2025] __schedule+0x934/0xe10 [Wed Jul 30 17:47:45 2025] ? complete+0x3b/0x50 [Wed Jul 30 17:47:45 2025] ? _cond_resched+0x15/0x30 [Wed Jul 30 17:47:45 2025] schedule+0x40/0xb0 [Wed Jul 30 17:47:45 2025] wb_wait_for_completion+0x52/0x80 [Wed Jul 30 17:47:45 2025] ? finish_wait+0x80/0x80 [Wed Jul 30 17:47:45 2025] mem_cgroup_css_free+0x22/0x1b0 [Wed Jul 30 17:47:45 2025] css_free_rwork_fn+0x42/0x380 [Wed Jul 30 17:47:45 2025] process_one_work+0x1a2/0x360 [Wed Jul 30 17:47:45 2025] worker_thread+0x30/0x390 [Wed Jul 30 17:47:45 2025] ? create_worker+0x1a0/0x1a0 [Wed Jul 30 17:47:45 2025] kthread+0x110/0x130 [Wed Jul 30 17:47:45 2025] ? __kthread_cancel_work+0x40/0x40 [Wed Jul 30 17:47:45 2025] ret_from_fork+0x1f/0x30 The direct cause is that memcg spends a long time waiting for dirty page writeback of foreign memcgs during release. The root causes are: a. The wb may have multiple writeback tasks, containing millions of dirty pages, as shown below: >>> for work in list_for_each_entry("struct wb_writeback_work", \ wb.work_list.address_of_(), "list"): ... print(work.nr_pages, work.reason, hex(work)) ... 900628 WB_REASON_FOREIGN_FLUSH 0xffff969e8d956b40 1116521 WB_REASON_FOREIGN_FLUSH 0xffff9698332a9540 1275228 WB_REASON_FOREIGN_FLUSH 0xffff969d9b444bc0 1099673 WB_REASON_FOREIGN_FLUSH 0xffff969f0954d6c0 1351522 WB_REASON_FOREIGN_FLUSH 0xffff969e76713340 2567437 WB_REASON_FOREIGN_FLUSH 0xffff9694ae208400 2954033 WB_REASON_FOREIGN_FLUSH 0xffff96a22d62cbc0 3008860 WB_REASON_FOREIGN_FLUSH 0xffff969eee8ce3c0 3337932 WB_REASON_FOREIGN_FLUSH 0xffff9695b45156c0 3348916 WB_REASON_FOREIGN_FLUSH 0xffff96a22c7a4f40 3345363 WB_REASON_FOREIGN_FLUSH 0xffff969e5d872800 3333581 WB_REASON_FOREIGN_FLUSH 0xffff969efd0f4600 3382225 WB_REASON_FOREIGN_FLUSH 0xffff969e770edcc0 3418770 WB_REASON_FOREIGN_FLUSH 0xffff96a252ceea40 3387648 WB_REASON_FOREIGN_FLUSH 0xffff96a3bda86340 3385420 WB_REASON_FOREIGN_FLUSH 0xffff969efc6eb280 3418730 WB_REASON_FOREIGN_FLUSH 0xffff96a348ab1040 3426155 WB_REASON_FOREIGN_FLUSH 0xffff969d90beac00 3397995 WB_REASON_FOREIGN_FLUSH 0xffff96a2d7288800 3293095 WB_REASON_FOREIGN_FLUSH 0xffff969dab423240 3293595 WB_REASON_FOREIGN_FLUSH 0xffff969c765ff400 3199511 WB_REASON_FOREIGN_FLUSH 0xffff969a72d5e680 3085016 WB_REASON_FOREIGN_FLUSH 0xffff969f0455e000 3035712 WB_REASON_FOREIGN_FLUSH 0xffff969d9bbf4b00 b. The writeback might severely throttled by wbt, with a speed possibly less than 100kb/s, leading to a very long writeback time. >>> wb.write_bandwidth (unsigned long)24 >>> wb.write_bandwidth (unsigned long)13 The wb_wait_for_completion() here is probably only used to prevent use-after-free. Therefore, we manage 'done' separately and automatically free it. This allows us to remove wb_wait_for_completion() while preventing the use-after-free issue. Link: https://lkml.kernel.org/r/20250827204557.90112-1-sunjunchao@bytedance.com Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing") Signed-off-by: Julian Sun <sunjunchao(a)bytedance.com> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Venkat <venkat88(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memcontrol.h | 7 +++- mm/memcontrol.c | 53 +++++++++++++++++++++++++++++------ 2 files changed, 51 insertions(+), 9 deletions(-) --- a/include/linux/memcontrol.h~memcg-dont-wait-writeback-completion-when-release-memcg +++ a/include/linux/memcontrol.h @@ -157,11 +157,16 @@ struct mem_cgroup_thresholds { */ #define MEMCG_CGWB_FRN_CNT 4 +struct cgwb_frn_wait { + struct wb_completion done; + struct wait_queue_entry wq_entry; +}; + struct memcg_cgwb_frn { u64 bdi_id; /* bdi->id of the foreign inode */ int memcg_id; /* memcg->css.id of foreign inode */ u64 at; /* jiffies_64 at the time of dirtying */ - struct wb_completion done; /* tracks in-flight foreign writebacks */ + struct cgwb_frn_wait *wait; /* tracks in-flight foreign writebacks */ }; /* --- a/mm/memcontrol.c~memcg-dont-wait-writeback-completion-when-release-memcg +++ a/mm/memcontrol.c @@ -3457,7 +3457,7 @@ void mem_cgroup_track_foreign_dirty_slow frn->memcg_id == wb->memcg_css->id) break; if (time_before64(frn->at, oldest_at) && - atomic_read(&frn->done.cnt) == 1) { + atomic_read(&frn->wait->done.cnt) == 1) { oldest = i; oldest_at = frn->at; } @@ -3504,12 +3504,12 @@ void mem_cgroup_flush_foreign(struct bdi * already one in flight. */ if (time_after64(frn->at, now - intv) && - atomic_read(&frn->done.cnt) == 1) { + atomic_read(&frn->wait->done.cnt) == 1) { frn->at = 0; trace_flush_foreign(wb, frn->bdi_id, frn->memcg_id); cgroup_writeback_by_id(frn->bdi_id, frn->memcg_id, WB_REASON_FOREIGN_FLUSH, - &frn->done); + &frn->wait->done); } } } @@ -3700,13 +3700,29 @@ static void mem_cgroup_free(struct mem_c __mem_cgroup_free(memcg); } +#ifdef CONFIG_CGROUP_WRITEBACK +static int memcg_cgwb_waitq_callback_fn(struct wait_queue_entry *wq_entry, unsigned int mode, + int flags, void *key) +{ + struct cgwb_frn_wait *frn_wait = container_of(wq_entry, + struct cgwb_frn_wait, wq_entry); + + if (!atomic_read(&frn_wait->done.cnt)) { + list_del(&wq_entry->entry); + kfree(frn_wait); + } + + return 0; +} +#endif + static struct mem_cgroup *mem_cgroup_alloc(struct mem_cgroup *parent) { struct memcg_vmstats_percpu *statc; struct memcg_vmstats_percpu __percpu *pstatc_pcpu; struct mem_cgroup *memcg; int node, cpu; - int __maybe_unused i; + int __maybe_unused i = 0; long error; memcg = kmem_cache_zalloc(memcg_cachep, GFP_KERNEL); @@ -3761,9 +3777,17 @@ static struct mem_cgroup *mem_cgroup_all INIT_LIST_HEAD(&memcg->objcg_list); #ifdef CONFIG_CGROUP_WRITEBACK INIT_LIST_HEAD(&memcg->cgwb_list); - for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) - memcg->cgwb_frn[i].done = + for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) { + struct memcg_cgwb_frn *frn = &memcg->cgwb_frn[i]; + + frn->wait = kmalloc(sizeof(struct cgwb_frn_wait), GFP_KERNEL); + if (!frn->wait) + goto fail; + + frn->wait->done = __WB_COMPLETION_INIT(&memcg_cgwb_frn_waitq); + init_wait_func(&frn->wait->wq_entry, memcg_cgwb_waitq_callback_fn); + } #endif #ifdef CONFIG_TRANSPARENT_HUGEPAGE spin_lock_init(&memcg->deferred_split_queue.split_queue_lock); @@ -3773,6 +3797,10 @@ static struct mem_cgroup *mem_cgroup_all lru_gen_init_memcg(memcg); return memcg; fail: +#ifdef CONFIG_CGROUP_WRITEBACK + while (i--) + kfree(memcg->cgwb_frn[i].wait); +#endif mem_cgroup_id_remove(memcg); __mem_cgroup_free(memcg); return ERR_PTR(error); @@ -3910,8 +3938,17 @@ static void mem_cgroup_css_free(struct c int __maybe_unused i; #ifdef CONFIG_CGROUP_WRITEBACK - for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) - wb_wait_for_completion(&memcg->cgwb_frn[i].done); + for (i = 0; i < MEMCG_CGWB_FRN_CNT; i++) { + struct cgwb_frn_wait *wait = memcg->cgwb_frn[i].wait; + + /* + * Not necessary to wait for wb completion which might cause task hung, + * only used to free resources. See memcg_cgwb_waitq_callback_fn(). + */ + __add_wait_queue_entry_tail(wait->done.waitq, &wait->wq_entry); + if (atomic_dec_and_test(&wait->done.cnt)) + wake_up_all(wait->done.waitq); + } #endif if (cgroup_subsys_on_dfl(memory_cgrp_subsys) && !cgroup_memory_nosocket) static_branch_dec(&memcg_sockets_enabled_key); _ Patches currently in -mm which might be from sunjunchao(a)bytedance.com are

1 month, 1 week

1
0
0 0

[PATCH v3 5.15.y 0/3] Fix TSA CPUID management in KVM

by Boris Ostrovsky

v3: * Make commit message in patch 2 more verbose v2: * Move kvm_cpu_cap_mask(CPUID_8000_0021_EAX, F(VERW_CLEAR)) to the first patch * Split second patch into two: fix TSA_SQ/L1_NO reporting (new patch) backport of LTS' f3f9deccfc68a6b7c8c1cc51e902edba23d309d4 Backport of AMD's TSA mitigation to 5.15 did not set CPUID bits that are passed to a guest correctly (commit c334ae4a545a "KVM: SVM: Advertise TSA CPUID bits to guests"). Boris Ostrovsky (1): KVM: SVM: Return TSA_SQ_NO and TSA_L1_NO bits in __do_cpuid_func() Borislav Petkov (AMD) (1): KVM: SVM: Set synthesized TSA CPUID flags Kim Phillips (1): KVM: x86: Move open-coded CPUID leaf 0x80000021 EAX bit propagation code arch/x86/kvm/cpuid.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) -- 2.43.5

1 month, 1 week

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror