Message ID | 20221117022940.873959-1-yebin@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp170920wrr; Wed, 16 Nov 2022 18:14:14 -0800 (PST) X-Google-Smtp-Source: AA0mqf7+xuQLiLYqDg2lEdIXtUXIY9vhlRG0G4nhFJcKbbmdqAMTq5ho1rnhPgUI+ITs8MI9nE/y X-Received: by 2002:a63:1601:0:b0:46f:9193:467d with SMTP id w1-20020a631601000000b0046f9193467dmr114242pgl.479.1668651254051; Wed, 16 Nov 2022 18:14:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668651254; cv=none; d=google.com; s=arc-20160816; b=KQCMJfN2uithh/nqs1CAqMi80zBMgptYH1C+ZRDF+lU6tAbQQlkbUIFBaCRMTcbXsa zhN4+MMWY9blk37SL7yD5/7o5h3J8XAwQgn+585rV0rMboSOEhO5FENb8xq1F2CH3oBW mDjJwvMcT+ztG11n7W3eym6+Z8b/DW9qESUvicp0jJyQY5jFpUC6ia8cGozpAzuv+11T X0sH7ANFrLhzzLRArO4ftEUVthf4f/+Tr2n8kkGvAUNWblJ9f+pzxtDVbW9hKpvoBK07 CVA6YBY7vWu9muIo2EIA83SLNM3P28YICt/An7G57LxhvO4f9xVBb3PJk9UzucKHoGkZ B0yQ== 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 :message-id:date:subject:cc:to:from; bh=lnmL6JayKfUvHaVf/EcBx/pvT77//5DG5XZf2kXS5sY=; b=zNCXFygKO9OoH0SVGhBnozuMpbA4J9ElHTeF9uLFZRgNjrzwOzyqiqoJn9nqt4HNDC UXN1G+4DuU7VnMC0ZL35fJXqmZ5BcujFmJ1K350LG4ijlcMBPko/TBgxZj2KSe2Woynw /KfQbd+nu1cxkBvfDirMoVyw/6F5wvSRrzB9KtS3P+OJlnfByWGMvY+RQg64Y/Tl/r4B L9U0IMgQ7I738IShS5GN1bFt24I8xRUh/e9tG7f79l1bUAudQMfMJVLq+ZAYs53aJQ0x 0RVtpiU2MwgZZl/w4tKqc2ISjpwsqqMv9wHGANwlHBwtQ132VfTfZjfEqxEXs2HwX/ju D3wQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pc1-20020a17090b3b8100b001fd8713170csi3968869pjb.179.2022.11.16.18.13.59; Wed, 16 Nov 2022 18:14:14 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234175AbiKQCIX (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 21:08:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232097AbiKQCIW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 21:08:22 -0500 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CEC860685; Wed, 16 Nov 2022 18:08:20 -0800 (PST) Received: from mail02.huawei.com (unknown [172.30.67.153]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4NCNcG5yjLz4f3mSF; Thu, 17 Nov 2022 10:08:14 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.127.227]) by APP4 (Coremail) with SMTP id gCh0CgAnmdaQl3Vjz+6gAg--.29770S4; Thu, 17 Nov 2022 10:08:17 +0800 (CST) From: Ye Bin <yebin@huaweicloud.com> To: axboe@kernel.dk, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Cc: ming.lei@redhat.com, Ye Bin <yebin10@huawei.com> Subject: [PATCH] blk-mq: fix possible memleak when register 'hctx' failed Date: Thu, 17 Nov 2022 10:29:40 +0800 Message-Id: <20221117022940.873959-1-yebin@huaweicloud.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgAnmdaQl3Vjz+6gAg--.29770S4 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr1xGryxGF1rGw4fXw4kXrb_yoW5JrWrpF W3Ww45GrW0qr4DZF4UtanxJry5Gw4vkFWUJFWfXr13tr1DGr90gF48JryjqFW8ArZ3AF4f uFyDtrZYkryUuaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyjb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6r1S6rWUM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1x MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6r W3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUv cSsGvfC2KfnxnUUI43ZEXa7IU1zuWJUUUUU== X-CM-SenderInfo: p1hex046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749707657127381631?= X-GMAIL-MSGID: =?utf-8?q?1749707657127381631?= |
Series |
blk-mq: fix possible memleak when register 'hctx' failed
|
|
Commit Message
Ye Bin
Nov. 17, 2022, 2:29 a.m. UTC
From: Ye Bin <yebin10@huawei.com> 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 <yebin10@huawei.com> --- block/blk-mq-sysfs.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
Comments
On Thu, Nov 17, 2022 at 10:29:40AM +0800, Ye Bin wrote: > From: Ye Bin <yebin10@huawei.com> > > 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 <yebin10@huawei.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Thanks, Ming
ping... On 2022/11/17 10:29, Ye Bin wrote: > From: Ye Bin <yebin10@huawei.com> > > 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 <yebin10@huawei.com> > --- > 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 93997d297d42..4515288fbe35 100644 > --- a/block/blk-mq-sysfs.c > +++ b/block/blk-mq-sysfs.c > @@ -185,7 +185,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; > @@ -197,9 +197,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; > } >
On Thu, 17 Nov 2022 10:29:40 +0800, Ye Bin wrote: > From: Ye Bin <yebin10@huawei.com> > > 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 > > [...] Applied, thanks! [1/1] blk-mq: fix possible memleak when register 'hctx' failed commit: 4b7a21c57b14fbcd0e1729150189e5933f5088e9 Best regards,
diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c index 93997d297d42..4515288fbe35 100644 --- a/block/blk-mq-sysfs.c +++ b/block/blk-mq-sysfs.c @@ -185,7 +185,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; @@ -197,9 +197,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; }