* [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up
@ 2019-05-03 23:35 Douglas Anderson
2019-05-03 23:52 ` Matthias Kaehlcke
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Douglas Anderson @ 2019-05-03 23:35 UTC (permalink / raw)
To: Ulf Hansson, Adrian Hunter, Linus Walleij
Cc: linux-rockchip, groeck, mka, drinkcat, Douglas Anderson,
Ming Lei, linux-mmc, Hannes Reinecke, linux-kernel, Jens Axboe,
Omar Sandoval
If I run the following on rk3288-veyron-minnie (a 2GB machine)
cd /sys/bus/platform/drivers/dwmmc_rockchip
for i in $(seq 1 3000); do
echo "========================" $i
echo ff0f0000.dwmmc > unbind
sleep .5
echo ff0f0000.dwmmc > bind
while true; do
if [ -e /dev/mmcblk2 ]; then
break;
fi
sleep .1
done
done
Then I start OOMing somewhere between iteration 200 and 250. Using
kmemleak, I see reports like:
unreferenced object 0xe39c5580 (size 64):
comm "kworker/1:0", pid 17, jiffies 4294821091 (age 96.952s)
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:
[<ad19d10a>] __kmalloc+0x1ec/0x2dc
[<a28614c3>] blk_mq_alloc_tag_set+0x27c/0x2bc
[<0955ae01>] mmc_init_queue+0xa8/0x2a8
[<5102b986>] mmc_blk_alloc_req+0xf8/0x2d4
[<f1c2214f>] mmc_blk_probe+0x4a8/0x6c0
[<0dfdd9d5>] mmc_bus_probe+0x24/0x28
It's pretty clear that we're missing a call to blk_mq_free_tag_set().
Let's add it.
Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/mmc/core/queue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 7c364a9c4eeb..09071e13282e 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -480,6 +480,8 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
*/
flush_work(&mq->complete_work);
+ blk_mq_free_tag_set(&mq->tag_set);
+
mq->card = NULL;
}
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up
2019-05-03 23:35 [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up Douglas Anderson
@ 2019-05-03 23:52 ` Matthias Kaehlcke
2019-05-04 0:20 ` Guenter Roeck
[not found] ` <20190503233526.226272-1-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2 siblings, 0 replies; 5+ messages in thread
From: Matthias Kaehlcke @ 2019-05-03 23:52 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, Adrian Hunter, Linus Walleij, linux-rockchip,
groeck, drinkcat, Ming Lei, linux-mmc, Hannes Reinecke,
linux-kernel, Jens Axboe, Omar Sandoval
On Fri, May 03, 2019 at 04:35:26PM -0700, Douglas Anderson wrote:
> If I run the following on rk3288-veyron-minnie (a 2GB machine)
>
> cd /sys/bus/platform/drivers/dwmmc_rockchip
> for i in $(seq 1 3000); do
> echo "========================" $i
> echo ff0f0000.dwmmc > unbind
> sleep .5
> echo ff0f0000.dwmmc > bind
> while true; do
> if [ -e /dev/mmcblk2 ]; then
> break;
> fi
> sleep .1
> done
> done
>
> Then I start OOMing somewhere between iteration 200 and 250. Using
> kmemleak, I see reports like:
>
> unreferenced object 0xe39c5580 (size 64):
> comm "kworker/1:0", pid 17, jiffies 4294821091 (age 96.952s)
> 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:
> [<ad19d10a>] __kmalloc+0x1ec/0x2dc
> [<a28614c3>] blk_mq_alloc_tag_set+0x27c/0x2bc
> [<0955ae01>] mmc_init_queue+0xa8/0x2a8
> [<5102b986>] mmc_blk_alloc_req+0xf8/0x2d4
> [<f1c2214f>] mmc_blk_probe+0x4a8/0x6c0
> [<0dfdd9d5>] mmc_bus_probe+0x24/0x28
>
> It's pretty clear that we're missing a call to blk_mq_free_tag_set().
> Let's add it.
>
> Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> drivers/mmc/core/queue.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 7c364a9c4eeb..09071e13282e 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -480,6 +480,8 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
> */
> flush_work(&mq->complete_work);
>
> + blk_mq_free_tag_set(&mq->tag_set);
> +
> mq->card = NULL;
> }
>
FWIW:
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up
2019-05-03 23:35 [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up Douglas Anderson
2019-05-03 23:52 ` Matthias Kaehlcke
@ 2019-05-04 0:20 ` Guenter Roeck
[not found] ` <20190503233526.226272-1-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2019-05-04 0:20 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, Adrian Hunter, Linus Walleij,
open list:ARM/Rockchip SoC...,
Guenter Roeck, Matthias Kaehlcke, Nicolas Boichat, Ming Lei,
linux-mmc, Hannes Reinecke, linux-kernel, Jens Axboe,
Omar Sandoval
On Fri, May 3, 2019 at 4:35 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> If I run the following on rk3288-veyron-minnie (a 2GB machine)
>
> cd /sys/bus/platform/drivers/dwmmc_rockchip
> for i in $(seq 1 3000); do
> echo "========================" $i
> echo ff0f0000.dwmmc > unbind
> sleep .5
> echo ff0f0000.dwmmc > bind
> while true; do
> if [ -e /dev/mmcblk2 ]; then
> break;
> fi
> sleep .1
> done
> done
>
> Then I start OOMing somewhere between iteration 200 and 250. Using
> kmemleak, I see reports like:
>
> unreferenced object 0xe39c5580 (size 64):
> comm "kworker/1:0", pid 17, jiffies 4294821091 (age 96.952s)
> 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:
> [<ad19d10a>] __kmalloc+0x1ec/0x2dc
> [<a28614c3>] blk_mq_alloc_tag_set+0x27c/0x2bc
> [<0955ae01>] mmc_init_queue+0xa8/0x2a8
> [<5102b986>] mmc_blk_alloc_req+0xf8/0x2d4
> [<f1c2214f>] mmc_blk_probe+0x4a8/0x6c0
> [<0dfdd9d5>] mmc_bus_probe+0x24/0x28
>
> It's pretty clear that we're missing a call to blk_mq_free_tag_set().
> Let's add it.
>
> Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Nice one.
Reviewed-by: Guenter Roeck <groeck@chromium.org>
> ---
>
> drivers/mmc/core/queue.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 7c364a9c4eeb..09071e13282e 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -480,6 +480,8 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
> */
> flush_work(&mq->complete_work);
>
> + blk_mq_free_tag_set(&mq->tag_set);
> +
> mq->card = NULL;
> }
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <20190503233526.226272-1-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up
[not found] ` <20190503233526.226272-1-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2019-05-04 11:57 ` Linus Walleij
2019-05-06 7:22 ` Adrian Hunter
1 sibling, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2019-05-04 11:57 UTC (permalink / raw)
To: Douglas Anderson
Cc: Jens Axboe, Ulf Hansson, drinkcat-F7+t8E8rja9g9hUCZPvPmw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-mmc, Adrian Hunter,
Ming Lei, open list:ARM/Rockchip SoC...,
Matthias Kaehlcke, Hannes Reinecke,
groeck-F7+t8E8rja9g9hUCZPvPmw, Omar Sandoval
On Sat, May 4, 2019 at 1:35 AM Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> If I run the following on rk3288-veyron-minnie (a 2GB machine)
>
> cd /sys/bus/platform/drivers/dwmmc_rockchip
> for i in $(seq 1 3000); do
> echo "========================" $i
> echo ff0f0000.dwmmc > unbind
> sleep .5
> echo ff0f0000.dwmmc > bind
> while true; do
> if [ -e /dev/mmcblk2 ]; then
> break;
> fi
> sleep .1
> done
> done
>
> Then I start OOMing somewhere between iteration 200 and 250. Using
> kmemleak, I see reports like:
>
> unreferenced object 0xe39c5580 (size 64):
> comm "kworker/1:0", pid 17, jiffies 4294821091 (age 96.952s)
> 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:
> [<ad19d10a>] __kmalloc+0x1ec/0x2dc
> [<a28614c3>] blk_mq_alloc_tag_set+0x27c/0x2bc
> [<0955ae01>] mmc_init_queue+0xa8/0x2a8
> [<5102b986>] mmc_blk_alloc_req+0xf8/0x2d4
> [<f1c2214f>] mmc_blk_probe+0x4a8/0x6c0
> [<0dfdd9d5>] mmc_bus_probe+0x24/0x28
>
> It's pretty clear that we're missing a call to blk_mq_free_tag_set().
> Let's add it.
>
> Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
> Signed-off-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Looks correct to me:
Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up
[not found] ` <20190503233526.226272-1-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2019-05-04 11:57 ` Linus Walleij
@ 2019-05-06 7:22 ` Adrian Hunter
1 sibling, 0 replies; 5+ messages in thread
From: Adrian Hunter @ 2019-05-06 7:22 UTC (permalink / raw)
To: Douglas Anderson, Ulf Hansson, Linus Walleij
Cc: Jens Axboe, Hannes Reinecke, drinkcat-F7+t8E8rja9g9hUCZPvPmw,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ming Lei,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mka-F7+t8E8rja9g9hUCZPvPmw, groeck-F7+t8E8rja9g9hUCZPvPmw,
Omar Sandoval
On 4/05/19 2:35 AM, Douglas Anderson wrote:
> If I run the following on rk3288-veyron-minnie (a 2GB machine)
>
> cd /sys/bus/platform/drivers/dwmmc_rockchip
> for i in $(seq 1 3000); do
> echo "========================" $i
> echo ff0f0000.dwmmc > unbind
> sleep .5
> echo ff0f0000.dwmmc > bind
> while true; do
> if [ -e /dev/mmcblk2 ]; then
> break;
> fi
> sleep .1
> done
> done
>
> Then I start OOMing somewhere between iteration 200 and 250. Using
> kmemleak, I see reports like:
>
> unreferenced object 0xe39c5580 (size 64):
> comm "kworker/1:0", pid 17, jiffies 4294821091 (age 96.952s)
> 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:
> [<ad19d10a>] __kmalloc+0x1ec/0x2dc
> [<a28614c3>] blk_mq_alloc_tag_set+0x27c/0x2bc
> [<0955ae01>] mmc_init_queue+0xa8/0x2a8
> [<5102b986>] mmc_blk_alloc_req+0xf8/0x2d4
> [<f1c2214f>] mmc_blk_probe+0x4a8/0x6c0
> [<0dfdd9d5>] mmc_bus_probe+0x24/0x28
>
> It's pretty clear that we're missing a call to blk_mq_free_tag_set().
> Let's add it.
>
> Fixes: 81196976ed94 ("mmc: block: Add blk-mq support")
> Signed-off-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Same as:
https://lore.kernel.org/lkml/20190502190714.181664-1-rrangel-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org/
> ---
>
> drivers/mmc/core/queue.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 7c364a9c4eeb..09071e13282e 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -480,6 +480,8 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
> */
> flush_work(&mq->complete_work);
>
> + blk_mq_free_tag_set(&mq->tag_set);
> +
> mq->card = NULL;
> }
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-05-06 7:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-03 23:35 [PATCH] mmc: block: Fix memory leak in blk-mq when cleaning up Douglas Anderson
2019-05-03 23:52 ` Matthias Kaehlcke
2019-05-04 0:20 ` Guenter Roeck
[not found] ` <20190503233526.226272-1-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2019-05-04 11:57 ` Linus Walleij
2019-05-06 7:22 ` Adrian Hunter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).