From: Weiping Zhang <zhangweiping@didiglobal.com>
To: <axboe@kernel.dk>, <tom.leiming@gmail.com>, <bvanassche@acm.org>,
<hch@infradead.org>
Cc: <linux-block@vger.kernel.org>
Subject: [PATCH v6 0/5] Fix potential kernel panic when increase hardware queue
Date: Thu, 7 May 2020 21:03:28 +0800 [thread overview]
Message-ID: <cover.1588856361.git.zhangweiping@didiglobal.com> (raw)
Hi,
This series mainly fix the kernel panic when increase hardware queue,
and also fix some other misc issue.
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.
Patch1: fix Memleak 1.
Patch2: fix prev_nr_hw_queues issue, need be saved before change.
Patch3: From Ming, fix potential kernel panic when increase hardware queue.
Patch4~5: 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 V5:
* fix 80 char per line for patch-4
Changes since V4:
* use another way to fix kernel panic when increase hardware queue,
this patch from Ming.
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
Ming Lei (1):
block: alloc map and request for new hardware queue
Weiping Zhang (4):
block: free both rq_map and request
block: save previous hardware queue count before udpate
block: rename __blk_mq_alloc_rq_map
block: rename blk_mq_alloc_rq_maps
block/blk-mq.c | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
--
2.18.2
next reply other threads:[~2020-05-07 13:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 13:03 Weiping Zhang [this message]
2020-05-07 13:03 ` [PATCH v6 1/5] block: free both rq_map and request Weiping Zhang
2020-05-07 15:09 ` Hannes Reinecke
2020-05-07 13:03 ` [PATCH v6 2/5] block: save previous hardware queue count before udpate Weiping Zhang
2020-05-07 15:09 ` Hannes Reinecke
2020-05-07 13:04 ` [PATCH v6 3/5] block: alloc map and request for new hardware queue Weiping Zhang
2020-05-07 15:11 ` Hannes Reinecke
2020-05-07 13:04 ` [PATCH v6 4/5] block: rename __blk_mq_alloc_rq_map Weiping Zhang
2020-05-07 15:12 ` Hannes Reinecke
2020-05-07 13:04 ` [PATCH v6 5/5] block: rename blk_mq_alloc_rq_maps Weiping Zhang
2020-05-07 15:12 ` Hannes Reinecke
2020-05-07 13:43 ` [PATCH v6 0/5] Fix potential kernel panic when increase hardware queue Christoph Hellwig
2020-05-07 18:31 ` Jens Axboe
2020-05-12 1:30 ` Bart Van Assche
2020-05-12 12:09 ` Weiping Zhang
2020-05-12 12:20 ` Weiping Zhang
2020-05-12 23:08 ` Bart Van Assche
2020-05-13 0:43 ` 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.1588856361.git.zhangweiping@didiglobal.com \
--to=zhangweiping@didiglobal.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hch@infradead.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: link
Be 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.