From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 833AE3451D9 for ; Tue, 23 Jun 2026 01:16:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782177384; cv=none; b=WmKnDVupzygc6BA4vbqaHjHV75V/hmoc1ecNqdal/r4ef6A8dp8HFbcOOSA9YL9Zc+QsVK0+LAE/rDGWV8yGugGno2UvnKdUtbHj1JVjrh1aL20+/lVv6h2QBgyg9VGilyZmWr5gR7WQlJ3zcVTKvWGLQzivEW1OD5LpbveGcNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782177384; c=relaxed/simple; bh=vg3wPC7jO9qTviKshM1mltF4IV5lb3FhxmhRHoFsvVI=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=GTjJPf5d39Q/L7C2liFk4rWaA3eGMlATZTB3lIeCbc3yLHcjHZz9093Mcx4xWvQClPv/4N/znhIIsyt3obL9uw6TQ2OCmlXVAGS9OacVo0zZGU/o4j9EIBF9W2VT9+bOeLR+SdGwL/0eT9CZVvE4julLYjz9xnRVn91rN4nu7W8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=NX7BAWz3; arc=none smtp.client-ip=95.215.58.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="NX7BAWz3" Message-ID: <38704548-786f-4ec7-afd4-228aa8d68ad7@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782177381; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jazVFyYoX6ftfj3SrA57nJBQLa/oXcNsFtjUmrhgLSk=; b=NX7BAWz309zA4pLIM0U0aZPFiH+SwFh59Czpu0M5/MYWP90j8ARH0PCXdVSrpP7vcAPAbD mCH6d3oTYJmQothNsmM8raLHjX7fcnlheqEqljTzW4O0UgFmLyIMO4onc5dQwy4hdOt29y GhNIXjd7BH6/aL0G6LUanDOfnfu01Q0= Date: Tue, 23 Jun 2026 09:16:01 +0800 Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Cc: cui.tao@linux.dev, cgroups@vger.kernel.org, yangerkun@huawei.com, chengzhihao1@huawei.com, houtao1@huawei.com, yukuai@fygo.io Subject: Re: [PATCH 1/2] blk-cgroup: fix blkg leak in blkg_create() error path To: Zizhi Wo , axboe@kernel.dk, tj@kernel.org, josef@toxicpanda.com, linux-block@vger.kernel.org References: <20260622070714.1158886-1-wozizhi@huaweicloud.com> <20260622070714.1158886-2-wozizhi@huaweicloud.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Tao Cui In-Reply-To: <20260622070714.1158886-2-wozizhi@huaweicloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Hi Zizhi, Thanks for the patch. I ran into the same issue and posted a fix for it earlier: https://lore.kernel.org/all/20260507061229.57466-1-cuitao@kylinos.cn/ The leak fix is identical to yours (blkg_put() -> percpu_ref_kill()), plus one extra change: moving blkg->online = true into the success block: if (likely(!ret)) { ... + blkg->online = true; } - blkg->online = true; On the failure path the blkg was never inserted into any list, and its blkg->pd[i]->online flags were not set either (those are in the same block). Leaving blkg->online = true marks a blkg as online that was never created -- inconsistent with pd[]->online and with blkg_destroy(), which clears blkg->online = false. Not observable today, since the failed blkg is on no list and unreachable by the online readers, but the flag should track the actual insertion. (This was sent to the cgroups list rather than linux-block, hence the overlap.) Thanks, Tao 在 2026/6/22 15:07, Zizhi Wo 写道: > When radix_tree_insert() fails in blkg_create(), the error path calls > blkg_put() to release the blkg. This was correct when blkg->refcnt was an > atomic_t: blkg_put() dropped it to 0 and triggered the release path. > > But commit 7fcf2b033b84 ("blkcg: change blkg reference counting to use > percpu_ref") switched refcnt to a percpu_ref. In percpu mode > percpu_ref_put() never checks for zero, so the release callback is never > invoked. This blkg is on neither blkcg->blkg_list nor queue->blkg_list, so > blkg_destroy_all() / blkcg_destroy_blkgs() can never reach it to call > blkg_destroy()->percpu_ref_kill() either, cause the leak. > > Fix it by killing the percpu_ref instead, which switches it to atomic mode > and drops the initial ref. > > Fixes: 7fcf2b033b84 ("blkcg: change blkg reference counting to use percpu_ref") > Signed-off-by: Zizhi Wo > Signed-off-by: Zizhi Wo > --- > block/blk-cgroup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index bc63bd220865..6386fe413994 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -437,11 +437,11 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, struct gendisk *disk, > > if (!ret) > return blkg; > > /* @blkg failed fully initialized, use the usual release path */ > - blkg_put(blkg); > + percpu_ref_kill(&blkg->refcnt); > return ERR_PTR(ret); > > err_put_css: > css_put(&blkcg->css); > err_free_blkg: