[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <xjwdgvoc6fw65yvtuyz7ku6dtjqzpf2ipty7ei5qcrfo7brxee@slit46ljmaoz>
Date: Thu, 15 Jan 2026 10:39:09 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Zheng Qixing <zhengqixing@...weicloud.com>
Cc: Yu Kuai <yukuai@...as.com>, tj@...nel.org, josef@...icpanda.com,
axboe@...nel.dk, hch@...radead.org, cgroups@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, yi.zhang@...wei.com,
yangerkun@...wei.com, houtao1@...wei.com, zhengqixing@...wei.com
Subject: Re: [PATCH v2 1/3] blk-cgroup: fix race between policy activation
and blkg destruction
On Thu, Jan 15, 2026 at 11:27:47AM +0800, Zheng Qixing <zhengqixing@...weicloud.com> wrote:
> Yes, this issue was discovered by injecting memory allocation failure at
> ->pd_alloc_fn(..., GFP_KERNEL) in blkcg_activate_policy().
Fair enough.
> Commit f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from
> blkg_free_workfn() and blkcg_deactivate_policy()") delays
> list_del_init(&blkg->q_node) until after pd_free_fn() in blkg_free_workfn().
IIUC, the point was to delay it from blkg_destroy until blkg_free_workfn
but then inside blkg_free_workfn it may have gone too far where it calls
pd_free_fn's before actual list removal.
(I'm Cc'ing the correct Kuai's address now.)
IOW, I'm wondering whether mere swap of these two actions (pd_free_fn
and list removal) wouldn't be a sufficient fix for the discovered issue
(instead of expanding lock coverage).
Thanks,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)
Powered by blists - more mailing lists