Re: [PATCH v5 3/3] writeback: switch a replaced cgwb's inodes to its successor

[Tejun Heo]

Hello, Liz.

On Thu, Oct 01, 2026 at 11:50:21PM +0000, Liz Fong-Jones wrote:
> it only queues the work, after dropping cgwb_lock. Inodes already being
> switched when the work runs are left to the existing per-inode
> switching, so this is best effort. If the successor is already gone,

That covers inodes being switched away from the old wb but not the ones
being switched to it. inode_switch_wbs() pins its target while the wb is
still live and the context lands later through the wb's switch_work, with
nothing ordering that against replaced_work. Those inodes end up on the
replaced wb after its scan, and for a removed memcg css_is_dying() keeps
them there until clean.

Every context lands through inode_switch_wbs_work_fn(), so can you kick
replaced_work from there when new_wb is dying and no longer owns its slot?
A dying wb that still owns its slot must not be kicked, or the work would
look up itself.

> +	/*
> +	 * The replaced wb is out of foreign flushes' reach but may still have
> +	 * inodes attached, dirty or not.  Switch them over to @wb.  We may be
> +	 * running with interrupts disabled, so use a work item.  A replaced wb
> +	 * never returns to the tree, so its work can't already be pending.
> +	 */
> +	if (replaced_wb &&
> +	    !queue_work(system_dfl_wq, &replaced_wb->replaced_work))
> +		wb_put(replaced_wb);

With the re-kick, already pending becomes a normal case. Maybe make this a
helper which trygets, queues and puts on failure, shared by both call
sites, and drop the last sentence.

Thanks.

--
tejun