Re: 4.5.0+ panic when setup loop device

From: Jens Axboe
Date: Thu Mar 17 2016 - 16:23:49 EST

On 03/17/2016 01:20 PM, Thomas Gleixner wrote:
On Thu, 17 Mar 2016, Jens Axboe wrote:
On 03/17/2016 09:42 AM, Jens Axboe wrote:
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.


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

Bah. Attachements ...

You'll live. Let's face it, all mailers suck in one way or another.

fine, we found some of those issues on sparc. Not sure why this one
slipped through the cracks.

This might be better, we need to start at -1 to not miss the first one...
Still untested.

+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) = -1; (ctx = next_ctx((q), &(i))) != NULL;)

What's wrong with

for_each_possible_cpu(cpu) {
ctx = per_cpu_ptr(q->queue_ctx, cpu);


instead of hiding it behind an incomprehensible macro mess?

We might not have mapped all of them.

Jens Axboe