From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936011AbcCQQmM (ORCPT ); Thu, 17 Mar 2016 12:42:12 -0400 Received: from mail-pf0-f172.google.com ([209.85.192.172]:35179 "EHLO mail-pf0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030507AbcCQQmL (ORCPT ); Thu, 17 Mar 2016 12:42:11 -0400 Subject: Re: 4.5.0+ panic when setup loop device To: Thomas Gleixner , Peter Zijlstra References: <20160317095220.GO6344@twins.programming.kicks-ass.net> <20160317102633.GR6344@twins.programming.kicks-ass.net> <20160317115120.GT6344@twins.programming.kicks-ass.net> Cc: Xiong Zhou , "linux-kernel@vger.kernel.org" , Ingo Molnar , Borislav Petkov , Andreas Herrmann From: Jens Axboe Message-ID: <56EADE5F.7000601@kernel.dk> Date: Thu, 17 Mar 2016 09:42:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------000206040703090907000306" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------000206040703090907000306 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/17/2016 05:01 AM, Thomas Gleixner wrote: > On Thu, 17 Mar 2016, Peter Zijlstra wrote: >> On Thu, Mar 17, 2016 at 12:39:46PM +0100, Thomas Gleixner wrote: >>> But we have to clarify and document whether holes in cpu_possible_mask are not >>> allowed at all or if code like the above is simply broken. >> >> So the general rule is that cpumasks can have holes, and exempting one >> just muddles the water. >> >> Therefore I'd call the code just plain broken. > > Agreed. > > That macro is not really helping the readability of the code at all. So a > simple for_each_possible_cpu() loop would have avoided that wreckage. Does the attached work? The rest of blk-mq should deal with holes just fine, we found some of those issues on sparc. Not sure why this one slipped through the cracks. -- Jens Axboe --------------000206040703090907000306 Content-Type: text/x-patch; name="blk-mq-discontig.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="blk-mq-discontig.patch" diff --git a/block/blk-mq.h b/block/blk-mq.h index eaede8e45c9c..5a8ab6c2abe5 100644 --- a/block/blk-mq.h +++ b/block/blk-mq.h @@ -118,4 +118,22 @@ static inline bool blk_mq_hw_queue_mapped(struct blk_mq_hw_ctx *hctx) return hctx->nr_ctx && hctx->tags; } +static inline struct blk_mq_ctx *next_ctx(struct request_queue *q, int *i) +{ + do { + (*i)++; + if (*i < q->nr_queues) { + if (cpu_possible(*i)) + return per_cpu_ptr(q->queue_ctx, *i); + continue; + } + break; + } while (1); + + return NULL; +} + +#define queue_for_each_ctx(q, ctx, i) \ + for ((i) = 0; (ctx = next_ctx((q), &(i))) != NULL;) + #endif diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h index 7fc9296b5742..a8756cd00767 100644 --- a/include/linux/blk-mq.h +++ b/include/linux/blk-mq.h @@ -261,22 +261,8 @@ static inline void *blk_mq_rq_to_pdu(struct request *rq) for ((i) = 0; (i) < (q)->nr_hw_queues && \ ({ hctx = (q)->queue_hw_ctx[i]; 1; }); (i)++) -#define queue_for_each_ctx(q, ctx, i) \ - for ((i) = 0; (i) < (q)->nr_queues && \ - ({ ctx = per_cpu_ptr((q)->queue_ctx, (i)); 1; }); (i)++) - #define hctx_for_each_ctx(hctx, ctx, i) \ for ((i) = 0; (i) < (hctx)->nr_ctx && \ ({ ctx = (hctx)->ctxs[(i)]; 1; }); (i)++) -#define blk_ctx_sum(q, sum) \ -({ \ - struct blk_mq_ctx *__x; \ - unsigned int __ret = 0, __i; \ - \ - queue_for_each_ctx((q), __x, __i) \ - __ret += sum; \ - __ret; \ -}) - #endif --------------000206040703090907000306--