Messages in this thread | | | Subject | Re: 4.5.0+ panic when setup loop device | From | Jens Axboe <> | Date | Thu, 17 Mar 2016 13:23:40 -0700 |
| |
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. >>>> >>>> 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 > > 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
| |