Message ID | 20230817085937.55590-1-hejunhao3@huawei.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b82d:0:b0:3f2:4152:657d with SMTP id z13csp630234vqi; Thu, 17 Aug 2023 04:33:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFIULHGoEsBo/5O7zhHl1RzoMybBE4RZlsrh58d00Q+sH9R/unZnzc/YTemKN9xaIqjTofi X-Received: by 2002:a17:90a:b794:b0:263:f4cc:a988 with SMTP id m20-20020a17090ab79400b00263f4cca988mr3650772pjr.5.1692271995253; Thu, 17 Aug 2023 04:33:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692271995; cv=none; d=google.com; s=arc-20160816; b=lpCXwCID7nomcwbNHqi4dJgpy/NDrSftn3No5NcvRXRWVYtviF2khT/e3wgWoxkgNW OP6UMHeegJ/dCFlj9OcbzkoxrqMvZPsxxFR9C+Kj6IWjnykJFXneZKK3oSrUrlhch2qm VthCurWoyqvLTSBlY3B0FZUrW9ZxLdMjOVhpqozA5eRbkiqKz4ek5JtM8+7BGoX7DKaW shJ4fp9xNbEd+dwi/4eeZFIDhC0ucBQ44h0NT9CshaF0QOlo9wUCQO59R0a84HTBYekw onJ/Ex9w2w90uEfBNPB0Nzr/FTFWWcVbwHsyolS71g1BKhtwMIier8PwZxVmMzGu78yd WLSw== 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=0ZhD7yT/7R1eCsb1KVHZYRDXDvmIw9EQwhDg13G8eb4=; fh=eW9sXTggpGrP9Q0O+YDZlRtemEU7E2tQ/2EK8hEEmXs=; b=NSif13NfL6qq4pTqhEHcRsT1MHrKIyGwr7SlzDYLNXktx5bnS+OUG8nVAjALz3+eQ2 UJ0bAC4R1DOSwCcHhjM4DyeA36iiIJU57CIETYYoA8l0SsoF8IHv8VSt5zpPI/Ujs1mN K7tvbu+kktyBNhIpTyf+dZFP0LhPpS1RGpWXm0Eyq7UhXqJpU0Cus9kSji5BX1u3TmIT euqxeBw7tCjyUoRNkEi7ugxGOt33bMKDU9MT72Qmi6Z4/vLsoSh2ti0lW80a327AMPJe lefwKHgcuNCgenBQcbyCDSTsF/wr3eFbYIPA6J/d3fdc6R9oSAh38jpmLXVLZz50UF3S L/VQ== 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m17-20020a17090b069100b00267d70fe0f7si1292804pjz.23.2023.08.17.04.33.02; Thu, 17 Aug 2023 04:33:15 -0700 (PDT) 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349221AbjHQJCu (ORCPT <rfc822;274620705z@gmail.com> + 99 others); Thu, 17 Aug 2023 05:02:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242446AbjHQJCd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 17 Aug 2023 05:02:33 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65A1910C8 for <linux-kernel@vger.kernel.org>; Thu, 17 Aug 2023 02:02:32 -0700 (PDT) Received: from dggpeml500002.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RRJpB1kgbzNmy7; Thu, 17 Aug 2023 16:58:58 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by dggpeml500002.china.huawei.com (7.185.36.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 17 Aug 2023 17:02:30 +0800 From: Junhao He <hejunhao3@huawei.com> To: <suzuki.poulose@arm.com>, <mike.leach@linaro.org>, <leo.yan@linaro.org>, <james.clark@arm.com> CC: <coresight@lists.linaro.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linuxarm@huawei.com>, <jonathan.cameron@huawei.com>, <yangyicong@huawei.com>, <prime.zeng@hisilicon.com>, <hejunhao3@huawei.com> Subject: [PATCH 0/2] Fix memory leak in coresight drivers Date: Thu, 17 Aug 2023 16:59:35 +0800 Message-ID: <20230817085937.55590-1-hejunhao3@huawei.com> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.69.192.56] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500002.china.huawei.com (7.185.36.158) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1774475799451121256 X-GMAIL-MSGID: 1774475799451121256 |
Series |
Fix memory leak in coresight drivers
|
|
Message
hejunhao
Aug. 17, 2023, 8:59 a.m. UTC
When build kernel with CONFIG_KASAN=y there are reports of memory leaks, like: ... unreferenced object 0xffff2020510fe200 (size 64): comm "insmod", pid 4642, jiffies 4295983961 (age 46049.752s) hex dump (first 32 bytes): 10 20 40 06 28 20 ff ff 10 40 7f 06 20 20 ff ff . @.( ...@.. .. 10 20 bb 8a 20 00 ff ff 10 e0 c7 8a 20 00 ff ff . .. ....... ... backtrace: [<0000000034ec4724>] __kmem_cache_alloc_node+0x2f8/0x348 [<0000000057fbc15d>] __kmalloc_node_track_caller+0x5c/0x110 [<0000000055d5e34b>] krealloc+0x8c/0x178 [<00000000a4635beb>] coresight_alloc_device_name+0x128/0x188 [coresight] [<000000000ce9d17b>] smb_probe+0x268/0x478 [ultrasoc_smb] ... unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........<!... 00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ................ backtrace: [<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] ... The patchset based on "coresight: platform: acpi: Ignore the absence of graph" https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?h=next&id=3a2888aa1f962c55ca36119aebe67355c7bf54e4 Junhao He (2): coresight: Fix memory leak in acpi_buffer->pointer coresight: core: fix memory leak in dict->fwnode_list drivers/hwtracing/coresight/coresight-core.c | 20 +++++++++- .../hwtracing/coresight/coresight-platform.c | 40 ++++++++++++------- 2 files changed, 45 insertions(+), 15 deletions(-)
Comments
On 17/08/2023 09:59, Junhao He wrote: > There are memory leaks reported by kmemleak: > ... > unreferenced object 0xffff00213c141000 (size 1024): > comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) > hex dump (first 32 bytes): > 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........<!... > 00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ................ > backtrace: > [<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348 > [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 > [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 > [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 > [<0000000024583908>] acpi_evaluate_object+0x388/0x438 > [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 > [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] > ... > > The ACPI buffer memory (buf.pointer) should be freed. But the buffer > is also used after returning from acpi_get_dsd_graph(). > Move the temporary variables buf to acpi_coresight_parse_graph(), > and free it before the function return to prevent memory leak. > > Fixes: 76ffa5ab5b79 ("coresight: Support for ACPI bindings") > Signed-off-by: Junhao He <hejunhao3@huawei.com> I confirmed that the error gone. Thanks for the fix. Reviewed-by: James Clark <james.clark@arm.com> > --- > .../hwtracing/coresight/coresight-platform.c | 40 ++++++++++++------- > 1 file changed, 26 insertions(+), 14 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c > index 7d7b641c0a71..9d550f5697fa 100644 > --- a/drivers/hwtracing/coresight/coresight-platform.c > +++ b/drivers/hwtracing/coresight/coresight-platform.c > @@ -492,19 +492,18 @@ static inline bool acpi_validate_dsd_graph(const union acpi_object *graph) > > /* acpi_get_dsd_graph - Find the _DSD Graph property for the given device. */ > static const union acpi_object * > -acpi_get_dsd_graph(struct acpi_device *adev) > +acpi_get_dsd_graph(struct acpi_device *adev, struct acpi_buffer *buf) > { > int i; > - struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER }; > acpi_status status; > const union acpi_object *dsd; > > status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, > - &buf, ACPI_TYPE_PACKAGE); > + buf, ACPI_TYPE_PACKAGE); > if (ACPI_FAILURE(status)) > return NULL; > > - dsd = buf.pointer; > + dsd = buf->pointer; > > /* > * _DSD property consists tuples { Prop_UUID, Package() } > @@ -555,12 +554,12 @@ acpi_validate_coresight_graph(const union acpi_object *cs_graph) > * returns NULL. > */ > static const union acpi_object * > -acpi_get_coresight_graph(struct acpi_device *adev) > +acpi_get_coresight_graph(struct acpi_device *adev, struct acpi_buffer *buf) > { > const union acpi_object *graph_list, *graph; > int i, nr_graphs; > > - graph_list = acpi_get_dsd_graph(adev); > + graph_list = acpi_get_dsd_graph(adev, buf); > if (!graph_list) > return graph_list; > > @@ -661,22 +660,24 @@ static int acpi_coresight_parse_graph(struct device *dev, > struct acpi_device *adev, > struct coresight_platform_data *pdata) > { > + int ret = 0; > int i, nlinks; > const union acpi_object *graph; > struct coresight_connection conn, zero_conn = {}; > struct coresight_connection *new_conn; > + struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL }; > > - graph = acpi_get_coresight_graph(adev); > + graph = acpi_get_coresight_graph(adev, &buf); > /* > * There are no graph connections, which is fine for some components. > * e.g., ETE > */ > if (!graph) > - return 0; > + goto free; > > nlinks = graph->package.elements[2].integer.value; > if (!nlinks) > - return 0; > + goto free; > > for (i = 0; i < nlinks; i++) { > const union acpi_object *link = &graph->package.elements[3 + i]; > @@ -684,17 +685,28 @@ static int acpi_coresight_parse_graph(struct device *dev, > > conn = zero_conn; > dir = acpi_coresight_parse_link(adev, link, &conn); > - if (dir < 0) > - return dir; > + if (dir < 0) { > + ret = dir; > + goto free; > + } > > if (dir == ACPI_CORESIGHT_LINK_MASTER) { > new_conn = coresight_add_out_conn(dev, pdata, &conn); > - if (IS_ERR(new_conn)) > - return PTR_ERR(new_conn); > + if (IS_ERR(new_conn)) { > + ret = PTR_ERR(new_conn); > + goto free; > + } > } > } > > - return 0; > +free: > + /* > + * When ACPI fails to alloc a buffer, it will free the buffer > + * created via ACPI_ALLOCATE_BUFFER and set to NULL. > + * ACPI_FREE can handle NULL pointers, so free it directly. > + */ > + ACPI_FREE(buf.pointer); > + return ret; > } > > /*
On 17/08/2023 09:59, Junhao He wrote: > There are memory leaks reported by kmemleak: > ... > unreferenced object 0xffff2020103c3200 (size 256): > comm "insmod", pid 4476, jiffies 4294978252 (age 50072.536s) > hex dump (first 32 bytes): > 10 60 40 06 28 20 ff ff 10 c0 59 06 20 20 ff ff .`@.( ....Y. .. > 10 e0 47 06 28 20 ff ff 10 00 49 06 28 20 ff ff ..G.( ....I.( .. > backtrace: > [<0000000034ec4724>] __kmem_cache_alloc_node+0x2f8/0x348 > [<0000000057fbc15d>] __kmalloc_node_track_caller+0x5c/0x110 > [<00000055d5e34b>] krealloc+0x8c/0x178 > [<00000000a4635beb>] coresight_alloc_device_name+0x128/0x188 [coresight] > [<00000000a92ddfee>] funnel_cs_ops+0x10/0xfffffffffffedaa0 [coresight_funnel] > [<00000000449e20f8>] dynamic_funnel_ids+0x80/0xfffffffffffed840 [coresight_funnel] > ... > > when remove driver, the golab variables defined by the macro > DEFINE_CORESIGHT_DEVLIST will be released, dict->nr_idx and > dict->fwnode_list are cleared to 0. The lifetime of the golab > variable has ended. So the buffer pointer is lost. > > Use the callback of devm_add_action_or_reset() to free memory. > > Fixes: 0f5f9b6ba9e1 ("coresight: Use platform agnostic names") > Signed-off-by: Junhao He <hejunhao3@huawei.com> > --- > drivers/hwtracing/coresight/coresight-core.c | 20 +++++++++++++++++++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index 9fabe00a40d6..6849faad697d 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -1756,6 +1756,20 @@ bool coresight_loses_context_with_cpu(struct device *dev) > } > EXPORT_SYMBOL_GPL(coresight_loses_context_with_cpu); > > +void coresight_release_dev_list(void *data) > +{ > + struct coresight_dev_list *dict = data; > + > + mutex_lock(&coresight_mutex); > + > + if (dict->nr_idx) { > + kfree(dict->fwnode_list); > + dict->nr_idx = 0; > + } > + > + mutex_unlock(&coresight_mutex); > +} > + > /* > * coresight_alloc_device_name - Get an index for a given device in the > * device index list specific to a driver. An index is allocated for a > @@ -1766,12 +1780,16 @@ EXPORT_SYMBOL_GPL(coresight_loses_context_with_cpu); > char *coresight_alloc_device_name(struct coresight_dev_list *dict, > struct device *dev) > { > - int idx; > + int idx, ret; > char *name = NULL; > struct fwnode_handle **list; > > mutex_lock(&coresight_mutex); > > + ret = devm_add_action_or_reset(dev, coresight_release_dev_list, dict); > + if (ret) > + goto done; > + Hi Junhao, Changing the list allocator to a devm one fixes the issue without having to add the callback: - list = krealloc_array(dict->fwnode_list, + list = devm_krealloc_array(dev, dict->fwnode_list, The callback stands out a bit and would make someone reading it wonder why only that one is done that way but all other allocations in Coresight avoid it. The nr_idx variable doesn't need to be zeroed because its backed by a static variable and is zeroed when the module is reloaded as far as I can see. Thanks James > idx = coresight_search_device_idx(dict, dev_fwnode(dev)); > if (idx < 0) { > /* Make space for the new entry */