From: Tejun Heo <tj@kernel.org>
To: Liz Fong-Jones <lizf@honeycomb.io>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jens Axboe <axboe@kernel.dk>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Xin Yin <yinxin.x@bytedance.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
ian@honeycomb.io
Subject: Re: [PATCH v6 3/3] writeback: switch a replaced cgwb's inodes to its successor
Date: Wed, 14 Oct 2026 09:05:38 -1000 [thread overview]
Message-ID: <0bc5d58533f10b4841807be3025daa11@kernel.org> (raw)
In-Reply-To: <20261002-wb-dying-cgwb-flush-v6-3-1991b4e2dcff@honeycomb.io>
Hello, Liz.
The following is a Claude-generated review.
On Fri, Oct 02, 2026 at 09:40:48PM +0000, Liz Fong-Jones wrote:
> + * Switch all inodes attached to @wb, dirty or not, to the wb that foreign
> + * flushes now find for @wb's memcg. If that one is already gone, fall back
The scan only reaches inodes on @wb's lists, so any inode attached to @wb
but on none of them stays behind, not just one from the
__inode_attach_wb() race. A clean inode switched over from the root wb,
which keeps clean inodes off its lists, is one example. Maybe say "all
inodes on @wb's lists" here and broaden that sentence in the description?
> + spin_lock(&wb->list_lock);
> + restart = isw_prepare_wbs_switch(new_wb, isw, &wb->b_attached, &nr) ||
> + isw_prepare_wbs_switch(new_wb, isw, &wb->b_dirty, &nr) ||
> + isw_prepare_wbs_switch(new_wb, isw, &wb->b_io, &nr) ||
> + isw_prepare_wbs_switch(new_wb, isw, &wb->b_more_io, &nr) ||
> + isw_prepare_wbs_switch(new_wb, isw, &wb->b_dirty_time, &nr);
> + spin_unlock(&wb->list_lock);
With f6988c90671e ("writeback: bound cleanup_offline_cgwb() rescans by
rotating scanned inodes") on mainline, isw_prepare_wbs_switch() moves
every scanned inode to the newest end of the list, and wb_switch_rwsem
keeps switches from landing during a sync but doesn't cover this scan.
On b_dirty, that can make a sync miss data:
1. A background work on the replaced wb yields to a sync_inodes_sb()
work and leaves inodes on b_io.
2. The sync work fixes dirtied_before at entry but doesn't queue_io()
until b_io drains.
3. Meanwhile, the memcg dirties a clean inode, which goes to the head of
b_dirty.
4. This scan fills an isw from the tail of b_dirty and moves those older
inodes in front of the new one.
5. Their switches block on wb_switch_rwsem, which the sync holds for
write.
6. queue_io() stops at the new inode, so the older ones, dirtied before
the sync started, are still dirty when it returns.
Maybe hold wb_switch_rwsem for read across the scan?
> +/* called with cgwb_lock held, possibly with interrupts disabled */
cgwb_lock is always taken with irqs disabled and lockdep_assert_held()
already says the rest. Maybe drop the comment?
> + * cgwb_kick_replaced - switch inodes away from @wb again if it was replaced
This queues replaced_work rather than switching anything. Maybe "queue
@wb's replaced_work if @wb has been replaced"?
Thanks.
--
tejun
next prev parent reply other threads:[~2026-10-14 19:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 21:40 [PATCH v6 0/3] writeback: let foreign flushes reach dying cgwbs Liz Fong-Jones
2026-10-02 21:40 ` Liz Fong-Jones
2026-10-02 21:40 ` [PATCH v6 1/3] writeback: clear the old wb's dirty IO state after switching inodes Liz Fong-Jones
2026-10-14 7:35 ` Jan Kara
2026-10-02 21:40 ` [PATCH v6 2/3] writeback: let foreign flushes reach dying cgwbs Liz Fong-Jones
2026-10-14 7:50 ` Jan Kara
2026-10-02 21:40 ` [PATCH v6 3/3] writeback: switch a replaced cgwb's inodes to its successor Liz Fong-Jones
2026-10-14 11:21 ` Jan Kara
2026-10-14 19:05 ` Tejun Heo [this message]
2026-10-13 13:34 ` [PATCH v6 0/3] writeback: let foreign flushes reach dying cgwbs Liz Fong-Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bc5d58533f10b4841807be3025daa11@kernel.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=ian@honeycomb.io \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@honeycomb.io \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=yinxin.x@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.