On Mon, Jul 7, 2025 at 10:49 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > Yes, but where does that ceph_evict_inode() come from? What's in its call chain? > Is it several shrink_dcache_parent() fighting each other on the same tree, or...? I described that already in my first email, but here you have a full kernel call stack (in this example, the shrinker is invoked from a user process due to memcg pressure): [<0>] ceph_evict_inode+0x232/0x2d0 [<0>] evict+0x104/0x2a0 [<0>] __dentry_kill+0x74/0x190 [<0>] shrink_dentry_list+0x107/0x3a0 [<0>] prune_dcache_sb+0x51/0x80 [<0>] super_cache_scan+0x130/0x1e0 [<0>] do_shrink_slab+0x156/0x670 [<0>] shrink_slab+0x48e/0x8a0 [<0>] shrink_node+0x32d/0x870 [<0>] do_try_to_free_pages+0xaf/0x500 [<0>] try_to_free_mem_cgroup_pages+0x10f/0x290 [<0>] try_charge_memcg+0x182/0x880 [<0>] __mem_cgroup_charge+0x3e/0x2c0 [<0>] filemap_add_folio+0x41/0xd0 [<0>] __filemap_get_folio+0x194/0x310 [<0>] netfs_write_begin+0x98/0x540 [<0>] ceph_write_begin+0x27/0x50 [<0>] generic_perform_write+0x97/0x2b0 [<0>] ceph_write_iter+0x4f1/0x650 [<0>] vfs_write+0x269/0x510 [<0>] ksys_write+0x65/0xe0 [<0>] do_syscall_64+0x82/0x130 [<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
