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:
[<c07f741c>] kmemleak_alloc+0x60/0xc8
[<c024cb44>] __kmalloc+0x184/0x2f4
[<c03dc1c8>] sg_kmalloc+0x48/0x4c
[<c03dc0dc>] __sg_alloc_table+0x78/0x11c
[<c03dc5d0>] sg_alloc_table+0x2c/0x5c
[<bf07d7e8>] brcmf_sdiod_sgtable_alloc+0xc0/0x110 [brcmfmac]
[<bf07b814>] brcmf_sdio_probe+0x24c/0x970 [brcmfmac]
[<bf07c6fc>] brcmf_ops_sdio_probe+0x17c/0x244 [brcmfmac]
[<c057d5b4>] sdio_bus_probe+0xb4/0x124
[<c04add08>] driver_probe_device+0x1d8/0x438
[<c04ae00c>] __driver_attach+0xa4/0x108
[<c04abe20>] bus_for_each_dev+0x84/0x98
[<c04ad644>] driver_attach+0x28/0x30
[<c04ad084>] bus_add_driver+0xe4/0x24c
[<c04ae834>] driver_register+0xac/0xf0
[<c057d7dc>] sdio_register_driver+0x2c/0x34
Regards
Stefan
> Arend van Spriel <[email protected]> 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:
> > [<c07f741c>] kmemleak_alloc+0x60/0xc8
> > [<c024cb44>] __kmalloc+0x184/0x2f4
> > [<c03dc1c8>] sg_kmalloc+0x48/0x4c
> > [<c03dc0dc>] __sg_alloc_table+0x78/0x11c
> > [<c03dc5d0>] sg_alloc_table+0x2c/0x5c
> > [<bf07d7e8>] brcmf_sdiod_sgtable_alloc+0xc0/0x110 [brcmfmac]
> > [<bf07b814>] brcmf_sdio_probe+0x24c/0x970 [brcmfmac]
> > [<bf07c6fc>] brcmf_ops_sdio_probe+0x17c/0x244 [brcmfmac]
> > [<c057d5b4>] sdio_bus_probe+0xb4/0x124
> > [<c04add08>] driver_probe_device+0x1d8/0x438
> > [<c04ae00c>] __driver_attach+0xa4/0x108
> > [<c04abe20>] bus_for_each_dev+0x84/0x98
> > [<c04ad644>] driver_attach+0x28/0x30
> > [<c04ad084>] bus_add_driver+0xe4/0x24c
> > [<c04ae834>] driver_register+0xac/0xf0
> > [<c057d7dc>] 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);
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:
> [<c07f741c>] kmemleak_alloc+0x60/0xc8
> [<c024cb44>] __kmalloc+0x184/0x2f4
> [<c03dc1c8>] sg_kmalloc+0x48/0x4c
> [<c03dc0dc>] __sg_alloc_table+0x78/0x11c
> [<c03dc5d0>] sg_alloc_table+0x2c/0x5c
> [<bf07d7e8>] brcmf_sdiod_sgtable_alloc+0xc0/0x110 [brcmfmac]
> [<bf07b814>] brcmf_sdio_probe+0x24c/0x970 [brcmfmac]
> [<bf07c6fc>] brcmf_ops_sdio_probe+0x17c/0x244 [brcmfmac]
> [<c057d5b4>] sdio_bus_probe+0xb4/0x124
> [<c04add08>] driver_probe_device+0x1d8/0x438
> [<c04ae00c>] __driver_attach+0xa4/0x108
> [<c04abe20>] bus_for_each_dev+0x84/0x98
> [<c04ad644>] driver_attach+0x28/0x30
> [<c04ad084>] bus_add_driver+0xe4/0x24c
> [<c04ae834>] driver_register+0xac/0xf0
> [<c057d7dc>] 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.
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);
On 7/26/2017 8:12 AM, Stefan Wahren wrote:
> Hi Arend,
>
>> Stefan Wahren <[email protected]> hat am 23. Juli 2017 um 02:24 geschrieben:
>>
>>
>>
>>> Arend van Spriel <[email protected]> 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:
>>>> [<c07f741c>] kmemleak_alloc+0x60/0xc8
>>>> [<c024cb44>] __kmalloc+0x184/0x2f4
>>>> [<c03dc1c8>] sg_kmalloc+0x48/0x4c
>>>> [<c03dc0dc>] __sg_alloc_table+0x78/0x11c
>>>> [<c03dc5d0>] sg_alloc_table+0x2c/0x5c
>>>> [<bf07d7e8>] brcmf_sdiod_sgtable_alloc+0xc0/0x110 [brcmfmac]
>>>> [<bf07b814>] brcmf_sdio_probe+0x24c/0x970 [brcmfmac]
>>>> [<bf07c6fc>] brcmf_ops_sdio_probe+0x17c/0x244 [brcmfmac]
>>>> [<c057d5b4>] sdio_bus_probe+0xb4/0x124
>>>> [<c04add08>] driver_probe_device+0x1d8/0x438
>>>> [<c04ae00c>] __driver_attach+0xa4/0x108
>>>> [<c04abe20>] bus_for_each_dev+0x84/0x98
>>>> [<c04ad644>] driver_attach+0x28/0x30
>>>> [<c04ad084>] bus_add_driver+0xe4/0x24c
>>>> [<c04ae834>] driver_register+0xac/0xf0
>>>> [<c057d7dc>] 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.
>
> do you plan to send a proper patch for this?
Sure. Catching up after my vacation.
Regards,
Arend
Hi Arend,
> Stefan Wahren <[email protected]> hat am 23. Juli 2017 um 02:24 geschrieben:
>
>
>
> > Arend van Spriel <[email protected]> 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:
> > > [<c07f741c>] kmemleak_alloc+0x60/0xc8
> > > [<c024cb44>] __kmalloc+0x184/0x2f4
> > > [<c03dc1c8>] sg_kmalloc+0x48/0x4c
> > > [<c03dc0dc>] __sg_alloc_table+0x78/0x11c
> > > [<c03dc5d0>] sg_alloc_table+0x2c/0x5c
> > > [<bf07d7e8>] brcmf_sdiod_sgtable_alloc+0xc0/0x110 [brcmfmac]
> > > [<bf07b814>] brcmf_sdio_probe+0x24c/0x970 [brcmfmac]
> > > [<bf07c6fc>] brcmf_ops_sdio_probe+0x17c/0x244 [brcmfmac]
> > > [<c057d5b4>] sdio_bus_probe+0xb4/0x124
> > > [<c04add08>] driver_probe_device+0x1d8/0x438
> > > [<c04ae00c>] __driver_attach+0xa4/0x108
> > > [<c04abe20>] bus_for_each_dev+0x84/0x98
> > > [<c04ad644>] driver_attach+0x28/0x30
> > > [<c04ad084>] bus_add_driver+0xe4/0x24c
> > > [<c04ae834>] driver_register+0xac/0xf0
> > > [<c057d7dc>] 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.
do you plan to send a proper patch for this?
>
> >
> > 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);