Received: by 2002:a05:6358:f14:b0:e5:3b68:ec04 with SMTP id b20csp1525340rwj; Sun, 18 Dec 2022 09:52:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf5E4gROG7j/QDQwy4HfVwybyo8x/2hzFZaDk78jTVRC0834zZEeQ8RemNeTQxgob5KexbvC X-Received: by 2002:a17:90a:b281:b0:219:e761:97e0 with SMTP id c1-20020a17090ab28100b00219e76197e0mr40143457pjr.33.1671385957467; Sun, 18 Dec 2022 09:52:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671385957; cv=none; d=google.com; s=arc-20160816; b=XM9dY/rHq4mKIQZR5g2Zv1K9P1HXj0swCAjHdrskOhVaDvGMxw78ApHRlvI2xOLW8q zC0UCUzWmJBHWMPOY9ZcmjKYf+rThGF6Ugm+nvR77LcoRs7jiDIlnwx6xwy5R9B+D5/t pIUYJ6C/DPjtzyOAyLSbiNNH6bZsRb4PZ4hKixorXPpVznOe4npMuB85UEf2bwQly53U AsfYmzfGtYSBsWZ6bW2K5hf1QpGRBqGMs65wamGaF0p+g7gwmW1mZcpljMNMG+HrNpuT xW7MEvD6RdawzDjPLB4w7RFDiVG+Ptq8FEv92n60+NfmAlp/CafvNLGrUJeCz1YbgUKH DjGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=nQu5TD56OKRSizqq+gTmO92SbHi6DwUUMYhMw9MtZIg=; b=rO9yjANpDATCenTua8gG2nv08orui+gJrnP1wwBFxBbNr9wwR/70ayc5/uiy85IJy6 2YCTOtQLobGsXZZoPNxVpFP5VgQDvSFPyZsSP+ARF3nQQQyDmshJFmss0baVG1z+YmKO Jz8zVDI1e/yMJQWSq5yfZxGGO5WIhQEOJN9q9H+IWcC13XP4MwOd1pFV27sPIrxzA+Pb EOh+j4ay0s2c//9qckuclVWmQfe2E+R13EhRRWmUnTxzpClk2Ol/wDnRhOtFOuIe+l4O l90JNo/JX00t7Tz3na/4Xr2LqgJfDbUGvffpM9p5ViJEdzzRHgff2SaBNk6qjBA589gp HgOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WBjM66jD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b129-20020a636787000000b00478d2acc977si8253797pgc.662.2022.12.18.09.52.28; Sun, 18 Dec 2022 09:52:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WBjM66jD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232573AbiLRQo0 (ORCPT + 70 others); Sun, 18 Dec 2022 11:44:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232453AbiLRQmg (ORCPT ); Sun, 18 Dec 2022 11:42:36 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5168ABC1E; Sun, 18 Dec 2022 08:15:30 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0538CB80BD1; Sun, 18 Dec 2022 16:15:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1331C433F2; Sun, 18 Dec 2022 16:15:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671380127; bh=2h+M05ApNHE6xRq8bd6r6AZBEC+OQeir99791RdYMCE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WBjM66jDTtFXjgOI49e03V8iDV4kN52DAtU/Dn8VzXRI42c0nCF7srTocZvGP9okK AVkb3guviHBth3uP0f8cAHAh4zV40Mmr341IHJVS1ywcpZbsXI2BRC6/fGmvTr3Frc GbXWH9vNPiVTpBKI5I1rITMCRzDe87RBQ7zG4FP5h+uVjL+eQQpUIZRXRNQT3IZIBV ycny1ZXh/NALxnLHEu52X3FZjYdIWIFnOKh29QXqRyjeP2xXu5hcZxJ6nVpGqU+Rrx kndbUk/0O88uAYhoU/VM9it+V0qIoCEV+Mv63aHT8rcEQWTvM827lLkvYABSzC8iFE n/Z8O/UWCMRjQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ye Bin , Ming Lei , Jens Axboe , Sasha Levin , linux-block@vger.kernel.org Subject: [PATCH AUTOSEL 5.15 37/46] blk-mq: fix possible memleak when register 'hctx' failed Date: Sun, 18 Dec 2022 11:12:35 -0500 Message-Id: <20221218161244.930785-37-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221218161244.930785-1-sashal@kernel.org> References: <20221218161244.930785-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ye Bin [ Upstream commit 4b7a21c57b14fbcd0e1729150189e5933f5088e9 ] There's issue as follows when do fault injection test: unreferenced object 0xffff888132a9f400 (size 512): comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2.... 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0 [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230 [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910 [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0 [<00000000a2a34657>] 0xffffffffa2ad310f [<00000000b173f718>] 0xffffffffa2af824a [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0 [<00000000f32fdf93>] do_init_module+0xdf/0x320 [<00000000cbe8541e>] load_module+0x3006/0x3390 [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fault injection context as follows: kobject_add blk_mq_register_hctx blk_mq_sysfs_register blk_register_queue device_add_disk null_add_dev.part.0 [null_blk] As 'blk_mq_register_hctx' may already add some objects when failed halfway, but there isn't do fallback, caller don't know which objects add failed. To solve above issue just do fallback when add objects failed halfway in 'blk_mq_register_hctx'. Signed-off-by: Ye Bin Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20221117022940.873959-1-yebin@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- block/blk-mq-sysfs.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c index 253c857cba47..7074ce8d2d03 100644 --- a/block/blk-mq-sysfs.c +++ b/block/blk-mq-sysfs.c @@ -187,7 +187,7 @@ static int blk_mq_register_hctx(struct blk_mq_hw_ctx *hctx) { struct request_queue *q = hctx->queue; struct blk_mq_ctx *ctx; - int i, ret; + int i, j, ret; if (!hctx->nr_ctx) return 0; @@ -199,9 +199,16 @@ static int blk_mq_register_hctx(struct blk_mq_hw_ctx *hctx) hctx_for_each_ctx(hctx, ctx, i) { ret = kobject_add(&ctx->kobj, &hctx->kobj, "cpu%u", ctx->cpu); if (ret) - break; + goto out; } + return 0; +out: + hctx_for_each_ctx(hctx, ctx, j) { + if (j < i) + kobject_del(&ctx->kobj); + } + kobject_del(&hctx->kobj); return ret; } -- 2.35.1