Skip to content

Navigation Menu

Sign in
Sign up

btrfs: reclaim compression cache in shrinker-sized batches - #10

Draft
eeea2222 wants to merge 1 commit into
CachyOS:7.0/cachy from
eeea2222:codex/btrfs-compression-shrinker-batch
Draft

btrfs: reclaim compression cache in shrinker-sized batches #10
eeea2222 wants to merge 1 commit into
CachyOS:7.0/cachy from
eeea2222:codex/btrfs-compression-shrinker-batch

Conversation

@eeea2222

@eeea2222 eeea2222 commented Jun 22, 2026

Copy link
Copy Markdown

Summary

Make the Btrfs compression page-pool shrinker reclaim only the requested shrinker batch under memory pressure instead of draining the whole cached page list.

Teardown behavior is preserved: calls without a shrink control still drain the full cache.

Why

The previous scan path drained the entire compression page cache once reclaim asked for objects. That can discard more cached pages than requested and cause avoidable reallocation churn in compressed Btrfs workloads.

Compatibility

No userspace ABI, module contract, exported symbol, Kconfig, or dependency changes. This is an internal shrinker behavior refinement.

Validation

  • Passed targeted ARCH=um object build for fs/btrfs/compression.o.
  • x86 object validation was attempted locally but blocked before compiling this object because the host environment lacked gelf.h, required by objtool.

CherrieTheShifter reacted with thumbs up emoji
adithyagenie pushed a commit to adithyagenie/linux that referenced this pull request Jul 25, 2026
commit 6d827ad upstream.
When meson_allocate_chanlist() fails after a partial allocation, it already
unwinds the allocated chanlist state through its local error path.
meson_crypto_probe() then jump to error_flow and calls
meson_free_chanlist() again, causing the same per-flow resources to be torn
down twice. In the reproduced failure path, the second teardown
re-entered crypto_engine_exit() on an already destroyed worker and KASAN
reported a slab-use-after-free in kthread_destroy_worker().
Prevent double-free by handling partial allocation failures locally within
meson_allocate_chanlist() and skipping the outer cleanup path.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available.
The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1,
using the reproducer under tools/testing/meson_crypto_probe. The reproducer
forces the second dma_alloc_attrs() call in the gxl-crypto probe path to
return NULL, making meson_allocate_chanlist() fail after partial
initialization. On the unpatched kernel this reliably triggered a
slab-use-after-free. With this fix applied, the same reproducer no longer
emits any KASAN report and the probe fails cleanly with -ENOMEM.
 ==================================================================
 BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0
 Read of size 8 at addr ff1100010c057a68 by task insmod/265
 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty CachyOS#10 PREEMPT(lazy)
 Tainted: [O]=OOT_MODULE
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
 Call Trace:
 <TASK>
 dump_stack_lvl+0x68/0xa0
 print_report+0xcb/0x5e0
 ? __virt_addr_valid+0x21d/0x3f0
 ? kthread_destroy_worker+0xb2/0xd0
 ? kthread_destroy_worker+0xb2/0xd0
 kasan_report+0xca/0x100
 ? kthread_destroy_worker+0xb2/0xd0
 kthread_destroy_worker+0xb2/0xd0
 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto]
 platform_probe+0x99/0x140
 really_probe+0x1c6/0x6a0
 ? __pfx___device_attach_driver+0x10/0x10
 __driver_probe_device+0x248/0x310
 ? acpi_driver_match_device+0xb0/0x100
 driver_probe_device+0x48/0x210
 ? __pfx___device_attach_driver+0x10/0x10
 __device_attach_driver+0x160/0x320
 bus_for_each_drv+0x104/0x190
 ? __pfx_bus_for_each_drv+0x10/0x10
 ? _raw_spin_unlock_irqrestore+0x2c/0x50
 __device_attach+0x19d/0x3b0
 ? __pfx___device_attach+0x10/0x10
 ? do_raw_spin_unlock+0x53/0x220
 device_initial_probe+0x78/0xa0
 bus_probe_device+0x5b/0x130
 device_add+0xcfd/0x1430
 ? __pfx_device_add+0x10/0x10
 ? insert_resource+0x34/0x50
 ? lock_release+0xc9/0x290
 platform_device_add+0x24e/0x590
 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro]
 meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro]
 do_one_initcall+0xc0/0x450
 ? __pfx_do_one_initcall+0x10/0x10
 ? _raw_spin_unlock_irqrestore+0x2c/0x50
 ? __create_object+0x59/0x80
 ? kasan_unpoison+0x27/0x60
 do_init_module+0x27b/0x7d0
 ? __pfx_do_init_module+0x10/0x10
 ? kasan_quarantine_put+0x84/0x1d0
 ? kfree+0x32c/0x510
 ? load_module+0x561e/0x5ff0
 load_module+0x54fe/0x5ff0
 ? __pfx_load_module+0x10/0x10
 ? security_file_permission+0x20/0x40
 ? kernel_read_file+0x23d/0x6e0
 ? mmap_region+0x235/0x4a0
 ? __pfx_kernel_read_file+0x10/0x10
 ? __file_has_perm+0x2c0/0x3e0
 init_module_from_file+0x158/0x180
 ? __pfx_init_module_from_file+0x10/0x10
 ? __lock_acquire+0x45a/0x1ba0
 ? idempotent_init_module+0x315/0x610
 ? lock_release+0xc9/0x290
 ? lockdep_init_map_type+0x4b/0x220
 ? do_raw_spin_unlock+0x53/0x220
 idempotent_init_module+0x330/0x610
 ? __pfx_idempotent_init_module+0x10/0x10
 ? __pfx_cred_has_capability.isra.0+0x10/0x10
 ? ksys_mmap_pgoff+0x385/0x520
 __x64_sys_finit_module+0xbe/0x120
 do_syscall_64+0x115/0x690
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 RIP: 0033:0x7f7d6d31690d
 Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 b4 0f 00 f7 d8 >
 RSP: 002b:00007fffc027ac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
 RAX: ffffffffffffffda RBX: 000055f7b81967c0 RCX: 00007f7d6d31690d
 RDX: 0000000000000000 RSI: 000055f79a0d6cd2 RDI: 0000000000000003
 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000003 R11: 0000000000000246 R12: 000055f79a0d6cd2
 R13: 000055f7b8196790 R14: 000055f79a0d5888 R15: 000055f7b81968e0
 </TASK>
Fixes: 48fe583 ("crypto: amlogic - Add crypto accelerator for amlogic GXL")
Cc: stable@vger.kernel.org
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Copy link
Copy Markdown

Yes This

CherrieTheShifter reacted with thumbs up emoji

kernelOfTruth commented Aug 25, 2026
edited
Loading

Copy link
Copy Markdown

@CherrieTheShifter since it's filesystem changes - it requires more than just compile-testing, no ?

e.g. xfstests runs and if there are any regressions ...

don't get me wrong - those pull-requests appear kinda awesome - it's just that when it comes to filesystems I'm extra-cautious and since btrfs is a checksumming fs and also used for backups, home, system - it makes even more sense to be extra picky

@eeea2222 thanks for those !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot will automatically review once the pull request is marked ready for review

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /