Re: [PATCH] writeback: let foreign flushes reach dying cgwbs
From: Liz Fong-Jones
Date: Mon Sep 28 2026 - 18:14:06 EST
Hi Tejun,
On Mon, Sep 28, 2026 at 09:19:37AM -1000, Tejun Heo wrote:
> Instead of walking bdi->wb_list, can't we update the lifetime rule so that
> a wb stays on bdi->cgwb_tree until it's actually released? That is, remove
> it from the tree in cgwb_release_workfn() instead of cgwb_kill() and have
> the creation paths skip dying wbs. cgroup_writeback_by_id() would then
> find the dying wb through the regular lookup.
Yes, that's cleaner, thanks for the suggestion. Implemented in v2:
https://lore.kernel.org/all/20260928-wb-dying-cgwb-flush-v2-1-56b54cda74f2@xxxxxxxxxxxx/
One edge case: a live memcg whose blkcg association changes needs a new
wb in the same slot while the killed one is still there, so
cgwb_create() takes over a dying wb's slot and cgwb_release_workfn()
uses radix_tree_delete_item() to only remove a wb that still owns it.
cgwb_bdi_unregister() skips dying wbs so they aren't killed twice.
> Note that the blkcg association check in wb_get_lookup() would have to
> move to the creation side.
Done, along with a wb_tryget_live() for the creation paths, including
wb_get_create_current().
> I don't think this qualifies as a fix. Can you drop the Fixes: and stable
> tags?
Dropped in v2. I'd tagged it because foreign flushes can't reach the
owning wb in exactly the case where its memcg has gone away, which
looked like a bug in the original implementation. But we avoided it in
userspace by syncing after the old container's last write, so agreed, it
doesn't need to go to stable.
Thanks,
Liz