From: Weiping Zhang <zhangweiping@didiglobal.com> To: <axboe@kernel.dk>, <tom.leiming@gmail.com>, <bvanassche@acm.org> Cc: <linux-block@vger.kernel.org> Subject: [PATCH v4 0/6] Fix potential kernel panic when increase hardware queue Date: Tue, 28 Apr 2020 21:25:19 +0800 [thread overview] Message-ID: <cover.1588078594.git.zhangweiping@didiglobal.com> (raw) Hi, This series do some improvement base on V2, and also fix two memleaks. And V2 import a regression for blktest/block/test/029, this test case will increase and decrease hardware queue count quickly. Memleak 1: __blk_mq_alloc_rq_maps __blk_mq_alloc_rq_map if fail blk_mq_free_rq_map Actually, __blk_mq_alloc_rq_map alloc both map and request, here also need free request. Memleak 2: When driver decrease hardware queue, set->nr_hw_queues will be changed firstly in blk_mq_realloc_tag_set_tags or __blk_mq_update_nr_hw_queues, then blk_mq_realloc_hw_ctxs and blk_mq_map_swqueue, even blk_mq_free_tag_set have no chance to free these hardware queue resource, because they iterate hardware queue by for (i = 0; i < set->nr_hw_queues; i++). Patch1: fix Memleak 1. Patch2: fix prev_nr_hw_queues issue, need be saved before change. Patch3: refactor __blk_mq_alloc_rq_maps and fix Memleak 2. Patch4: fix potential kernel panic when increase hardware queue. Patch5~6: rename two function, because these two function alloc both map and request, and keep in pair with blk_mq_free_map_and_request(s). Changes since V3: * record patchset, fix issue fistly then rename. * rename function to blk_mq_alloc_map_and_request Changes since V2: * rename some functions name and fix memleak when free map and requests * Not free new allocated map and request, they will be relased when tagset gone Changes since V1: * Add fix for potential kernel panic when increase hardware queue Weiping Zhang (6): block: free both rq_map and request block: save previous hardware queue count before udpate block: refactor __blk_mq_alloc_rq_maps block: alloc map and request for new hardware queue block: rename __blk_mq_alloc_rq_map block: rename blk_mq_alloc_rq_maps block/blk-mq.c | 47 +++++++++++++++++++++++++++++------------- include/linux/blk-mq.h | 1 + 2 files changed, 34 insertions(+), 14 deletions(-) -- 2.18.1
WARNING: multiple messages have this Message-ID (diff)
From: Weiping Zhang <zhangweiping@didiglobal.com> To: <axboe@kernel.dk>, <tom.leiming@gmail.com>, <bvanassche@acm.org> Cc: <linux-block@vger.kernel.org> Subject: [RESEND PATCH v4 0/6] Fix potential kernel panic when increase hardware queue Date: Tue, 28 Apr 2020 21:29:19 +0800 [thread overview] Message-ID: <cover.1588078594.git.zhangweiping@didiglobal.com> (raw) Message-ID: <20200428132919.9bHRgAY3SfYS2tSRPt1En2xSg9DiFTW2zmfXG-Ot570@z> (raw) Hi, This series do some improvement base on V2, and also fix two memleaks. And V2 import a regression for blktest/block/test/029, this test case will increase and decrease hardware queue count quickly. Memleak 1: __blk_mq_alloc_rq_maps __blk_mq_alloc_rq_map if fail blk_mq_free_rq_map Actually, __blk_mq_alloc_rq_map alloc both map and request, here also need free request. Memleak 2: When driver decrease hardware queue, set->nr_hw_queues will be changed firstly in blk_mq_realloc_tag_set_tags or __blk_mq_update_nr_hw_queues, then blk_mq_realloc_hw_ctxs and blk_mq_map_swqueue, even blk_mq_free_tag_set have no chance to free these hardware queue resource, because they iterate hardware queue by for (i = 0; i < set->nr_hw_queues; i++). Patch1: fix Memleak 1. Patch2: fix prev_nr_hw_queues issue, need be saved before change. Patch3: refactor __blk_mq_alloc_rq_maps and fix Memleak 2. Patch4: fix potential kernel panic when increase hardware queue. Patch5~6: rename two function, because these two function alloc both map and request, and keep in pair with blk_mq_free_map_and_request(s). Changes since V3: * record patchset, fix issue fistly then rename. * rename function to blk_mq_alloc_map_and_request Changes since V2: * rename some functions name and fix memleak when free map and requests * Not free new allocated map and request, they will be relased when tagset gone Changes since V1: * Add fix for potential kernel panic when increase hardware queue Weiping Zhang (6): block: free both rq_map and request block: save previous hardware queue count before udpate block: refactor __blk_mq_alloc_rq_maps block: alloc map and request for new hardware queue block: rename __blk_mq_alloc_rq_map block: rename blk_mq_alloc_rq_maps block/blk-mq.c | 47 +++++++++++++++++++++++++++++------------- include/linux/blk-mq.h | 1 + 2 files changed, 34 insertions(+), 14 deletions(-) -- 2.18.1
next reply other threads:[~2020-04-28 13:25 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-28 13:25 Weiping Zhang [this message] 2020-04-28 13:29 ` [RESEND PATCH v4 0/6] Fix potential kernel panic when increase hardware queue Weiping Zhang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1588078594.git.zhangweiping@didiglobal.com \ --to=zhangweiping@didiglobal.com \ --cc=axboe@kernel.dk \ --cc=bvanassche@acm.org \ --cc=linux-block@vger.kernel.org \ --cc=tom.leiming@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.