Re: 4.5.0+ panic when setup loop device

[Thomas Gleixner]

B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote:

> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote:
> > On Thu, 17 Mar 2016, Peter Zijlstra wrote:
> > 
> > > Could you please try? I'm not sure how this would explain your loop
> > > device bug fail, but it certainly pointed towards broken.
> > 
> > It definitely does not explain it. The wreckage that topo stuff causes is that
> > it disables a cpu, but that really is not a reason for block/loop to explode.
> 
> Right. Sadly I could not reproduce that error on my machine. But we can
> at least start by fixing the 'obvious' problems and then maybe we get
> more clues ;-)

I'm able to reproduce by rejecting a cpu in that topology map function
forcefully.

That stuff explodes, because the block-mq code assumes that cpu_possible_mask
has no holes.

#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)++)

is what makes that assumption about a consecutive possible mask.

The cure for now is the patch below on top of PeterZ's patch.

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.

Thanks,

	tglx
---
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 643dbdccf4bc..f2ed8a01f870 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -345,7 +345,6 @@ static void __init smp_init_package_map(void)
 			continue;
 		pr_warn("CPU %u APICId %x disabled\n", cpu, apicid);
 		per_cpu(x86_bios_cpu_apicid, cpu) = BAD_APICID;
-		set_cpu_possible(cpu, false);
 		set_cpu_present(cpu, false);
 	}
 }