Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Per-CPU object pools (`lpool`) grow unboundedly because objects are never returned to the global pool, leading to endless `vmalloc()` allocations and potential OOM. - [High] Un-ratelimited printk in the pool exhaustion path causes console flooding and soft lockups. --
(Note: The format of this report is altered to use a free-form summary rather than inline diff quotes due to recitation restrictions.) commit 0f35ff40c325e46d2d4adab446907928b805d0e5 Author: Byungchul Park <[email protected]> dept: add a mechanism to refill the internal memory pools on running out This commit introduces a mechanism to dynamically refill internal memory pools for the DEPT engine using an IRQ work and workqueue. It adds per-CPU local pools and a vmalloc-based refill path when the static pools are exhausted. [Severity: High] Could the per-CPU local pools (lpool) grow without bounds under certain workloads? Looking at to_pool() and from_pool() in kernel/dependency/dept.c, objects are unconditionally added to the per-CPU lpool without any upper bound check or reclaim logic. If a task allocates an object (like ecxt or wait) on CPU A, migrates to CPU B, and frees it, the object goes into CPU B's lpool. Because objects are never returned to the global spool when the lpool grows large, the global pool will eventually drain. When from_pool() sees an empty global pool, it triggers request_rpool_refill(), which allocates new memory via vmalloc() in dept_wq_work_fn(). Will continuous cross-CPU allocation and freeing indefinitely leak memory into local pools and repeatedly trigger vmalloc allocations, potentially leading to an out-of-memory condition? [Severity: High] Is it safe to use an un-ratelimited printk in the pool exhaustion path? In kernel/dependency/dept.c:from_pool(), when a pool is exhausted, the code calls DEPT_INFO() (which maps to pr_warn()) to notify the user. This happens with hardware interrupts disabled via dept_enter(). Because the pool refill in dept_wq_work_fn() happens asynchronously in a workqueue, the pool will remain empty until the workqueue runs. Every subsequent lock acquisition during this window will synchronously print a multi-line message to the console. Could this flood the console and cause soft lockups or RCU stalls since thousands of locks might be acquired by a single thread while waiting for the async workqueue to execute? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8
