Return-path: Received: from mout.kundenserver.de ([217.72.192.73]:50855 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751957AbdGWAYX (ORCPT ); Sat, 22 Jul 2017 20:24:23 -0400 Date: Sun, 23 Jul 2017 02:24:15 +0200 (CEST) From: Stefan Wahren To: franky.lin@broadcom.com, pieter-paul.giesberts@broadcom.com, kvalo@codeaurora.org, Arend van Spriel , hante.meuleman@broadcom.com Cc: brcm80211-dev-list.pdl@broadcom.com, linux-wireless@vger.kernel.org Message-ID: <1455616686.54674.1500769455061@email.1und1.de> (sfid-20170723_022435_630505_88B7AD9D) In-Reply-To: <325e5f1a-2752-6004-a460-a59e8e2c702d@broadcom.com> References: <1442361688.41682.1500729531173@email.1und1.de> <325e5f1a-2752-6004-a460-a59e8e2c702d@broadcom.com> Subject: Re: brcmfmac: Possible memleak brcmf_sdiod_sgtable_alloc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: > Arend van Spriel hat am 22. Juli 2017 um 21:40 geschrieben: > > > On 22-07-17 15:18, Stefan Wahren wrote: > > Hi, > > > > with enabled memleak detector on 4.13-rc1 (Raspberry Pi Zero W) i get the following: > > > > root@raspberrypi:/sys/kernel/debug# cat kmemleak > > unreferenced object 0xd824e400 (size 1024): > > comm "kworker/0:0", pid 3, jiffies 4294939822 (age 873.420s) > > hex dump (first 32 bytes): > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > backtrace: > > [] kmemleak_alloc+0x60/0xc8 > > [] __kmalloc+0x184/0x2f4 > > [] sg_kmalloc+0x48/0x4c > > [] __sg_alloc_table+0x78/0x11c > > [] sg_alloc_table+0x2c/0x5c > > [] brcmf_sdiod_sgtable_alloc+0xc0/0x110 [brcmfmac] > > [] brcmf_sdio_probe+0x24c/0x970 [brcmfmac] > > [] brcmf_ops_sdio_probe+0x17c/0x244 [brcmfmac] > > [] sdio_bus_probe+0xb4/0x124 > > [] driver_probe_device+0x1d8/0x438 > > [] __driver_attach+0xa4/0x108 > > [] bus_for_each_dev+0x84/0x98 > > [] driver_attach+0x28/0x30 > > [] bus_add_driver+0xe4/0x24c > > [] driver_register+0xac/0xf0 > > [] sdio_register_driver+0x2c/0x34 > > Hi Stefan, > > Thanks for the report. Checking elixir it shows two call sites to > brcmf_sdiod_sgtable_alloc() [1]. This is rather unexpected. We did move > the call so this might be a merge issue. > > 4d7928959 sdio.c (Hante Meuleman 2016-02-17 11:27:07 +0100: > 3867) brcmf_sdiod_sgtable_alloc(sdiodev); > > e0045bf80 sdio.c (Hante Meuleman 2016-01-19 12:39:24 +0100: > 4180) brcmf_sdiod_sgtable_alloc(bus->sdiodev); > > The most recent change is: > > commit 4d7928959832 ("brcmfmac: switch to new platform data") found in > patchwork [2], which shows the added call, but no removal so the merge > issue is probably internal with us (me :-( ). > > Again thanks for the report. Below change should fix the issue. Yes, this fixed the leak. Thanks for you fast reply. > > Regards, > Arend > > [1] > http://elixir.free-electrons.com/linux/latest/ident/brcmf_sdiod_sgtable_alloc > [2] https://patchwork.kernel.org/patch/8336231/ > > --- > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > index fbcbb43..ed2c693 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > @@ -4174,11 +4174,6 @@ struct brcmf_sdio *brcmf_sdio_probe(struct > brcmf_sdio_dev *sdiodev) > goto fail; > } > > - /* allocate scatter-gather table. sg support > - * will be disabled upon allocation failure. > - */ > - brcmf_sdiod_sgtable_alloc(bus->sdiodev); > - > /* Query the F2 block size, set roundup accordingly */ > bus->blocksize = bus->sdiodev->func[2]->cur_blksize; > bus->roundup = min(max_roundup, bus->blocksize);