Re: [PATCH RESEND v2 1/2] blk-mq: Fix failed allocation path when mapping queues

2016-12-14 Thread Jens Axboe
On 12/06/2016 08:31 AM, Gabriel Krisman Bertazi wrote: > This should apply cleanly on top of Jen's for-next branch. Jens, not Jen. > @@ -1893,6 +1893,15 @@ static void blk_mq_map_swqueue(struct request_queue *q, > if (!cpumask_test_cpu(i, online_mask)) > contin

Re: [PATCH RESEND v2 1/2] blk-mq: Fix failed allocation path when mapping queues

2016-12-07 Thread Douglas Miller
On 12/07/2016 02:06 PM, Douglas Miller wrote: On 12/06/2016 09:31 AM, Gabriel Krisman Bertazi wrote: In blk_mq_map_swqueue, there is a memory optimization that frees the tags of a queue that has gone unmapped. Later, if that hctx is remapped after another topology change, the tags need to be re

Re: [PATCH RESEND v2 1/2] blk-mq: Fix failed allocation path when mapping queues

2016-12-07 Thread Douglas Miller
On 12/06/2016 09:31 AM, Gabriel Krisman Bertazi wrote: In blk_mq_map_swqueue, there is a memory optimization that frees the tags of a queue that has gone unmapped. Later, if that hctx is remapped after another topology change, the tags need to be reallocated. If this allocation fails, a simple

[PATCH RESEND v2 1/2] blk-mq: Fix failed allocation path when mapping queues

2016-12-06 Thread Gabriel Krisman Bertazi
In blk_mq_map_swqueue, there is a memory optimization that frees the tags of a queue that has gone unmapped. Later, if that hctx is remapped after another topology change, the tags need to be reallocated. If this allocation fails, a simple WARN_ON triggers, but the block layer ends up with an act