From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F18D6C33CA1 for ; Thu, 9 Jan 2020 13:50:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C8C6E20661 for ; Thu, 9 Jan 2020 13:50:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731283AbgAINuI (ORCPT ); Thu, 9 Jan 2020 08:50:08 -0500 Received: from smtp1.de.adit-jv.com ([93.241.18.167]:56591 "EHLO smtp1.de.adit-jv.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728435AbgAINuH (ORCPT ); Thu, 9 Jan 2020 08:50:07 -0500 Received: from localhost (smtp1.de.adit-jv.com [127.0.0.1]) by smtp1.de.adit-jv.com (Postfix) with ESMTP id 628BD3C04C0; Thu, 9 Jan 2020 14:50:04 +0100 (CET) Received: from smtp1.de.adit-jv.com ([127.0.0.1]) by localhost (smtp1.de.adit-jv.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnVdHi-5nOMk; Thu, 9 Jan 2020 14:49:59 +0100 (CET) Received: from HI2EXCH01.adit-jv.com (hi2exch01.adit-jv.com [10.72.92.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.de.adit-jv.com (Postfix) with ESMTPS id 0D9103C00B7; Thu, 9 Jan 2020 14:49:59 +0100 (CET) Received: from lxhi-065.adit-jv.com (10.72.93.66) by HI2EXCH01.adit-jv.com (10.72.92.24) with Microsoft SMTP Server (TLS) id 14.3.468.0; Thu, 9 Jan 2020 14:49:58 +0100 Date: Thu, 9 Jan 2020 14:49:56 +0100 From: Eugeniu Rosca To: Geert Uytterhoeven CC: Eugeniu Rosca , Geert Uytterhoeven , Linus Walleij , Bartosz Golaszewski , Jonathan Corbet , Rob Herring , Mark Rutland , Harish Jenny K N , Eugeniu Rosca , Alexander Graf , Peter Maydell , Paolo Bonzini , Phil Reid , Marc Zyngier , Christoffer Dall , Magnus Damm , "open list:GPIO SUBSYSTEM" , "open list:DOCUMENTATION" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux-Renesas , Linux Kernel Mailing List , QEMU Developers Subject: Re: [PATCH v3 5/7] gpio: Add GPIO Aggregator/Repeater driver Message-ID: <20200109134843.GA2558@lxhi-065.adit-jv.com> References: <20191127084253.16356-1-geert+renesas@glider.be> <20191127084253.16356-6-geert+renesas@glider.be> <20191203105103.GA20470@x230> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-Originating-IP: [10.72.93.66] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On Thu, Jan 09, 2020 at 02:35:10PM +0100, Geert Uytterhoeven wrote: > On Tue, Dec 3, 2019 at 11:51 AM Eugeniu Rosca wrote: > > > > FWIW/FTR, doing some blind creation and deletion of gpio aggregator > > chips [1] on R-Car H3ULCB overnight, kmemleak reported once [2]. Not > > sure this is something 100% reproducible. > > > > [1] while true; do \ > > echo e6055400.gpio 12,13 > /sys/bus/platform/drivers/gpio-aggregator/new_device; \ > > echo gpio-aggregator.0 > /sys/bus/platform/drivers/gpio-aggregator/delete_device; \ > > done > > > > [2] unreferenced object 0xffff0006d2c2e000 (size 128): > > comm "kworker/3:1", pid 55, jiffies 4294676978 (age 38546.676s) > > hex dump (first 32 bytes): > > 00 d9 d2 d3 06 00 ff ff 0c 00 e0 0f ff ff ff ff ................ > > 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > backtrace: > > [<00000000a8e18c13>] slab_post_alloc_hook+0x8c/0x94 > > [<000000006f419a4f>] __kmalloc+0x170/0x218 > > [<0000000060d185ea>] kobj_map+0x78/0x1c0 > > [<00000000c96645f3>] cdev_add+0x68/0x94 > > [<00000000a7a5a8ac>] cdev_device_add+0x74/0x90 > > [<00000000497871d3>] gpiochip_setup_dev+0x84/0x1f0 > > [<00000000b993f95f>] gpiochip_add_data_with_key+0xbcc/0x11f0 > > [<00000000fd728c0e>] devm_gpiochip_add_data+0x60/0xa8 > > [<00000000442e34c1>] gpio_aggregator_probe+0x210/0x3c8 > > [<00000000076e13fb>] platform_drv_probe+0x70/0xe4 > > [<00000000de84b58b>] really_probe+0x2d8/0x434 > > [<00000000c95c9784>] driver_probe_device+0x15c/0x16c > > [<00000000afb7dd4f>] __device_attach_driver+0xdc/0x120 > > [<00000000efa40cae>] bus_for_each_drv+0x12c/0x154 > > [<00000000c149acef>] __device_attach+0x148/0x1e0 > > [<00000000a74fd158>] device_initial_probe+0x24/0x30 > > This is the allocation of the GPIO character device, which is allocated > in response to the creation of the GPIO chip, from .probe(). > As that is done using devm_gpiochip_add_data(), the chardev should be > deallocated automatically by devm_gpio_chip_release() when > platform_device_unregister() is called. > > Weird... It might have been a false positive. Kmemleak is not w/o flaws. I will retest and report later. In any case, it does not look severe to me. -- Best Regards, Eugeniu