From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935778AbcCQLlR (ORCPT ); Thu, 17 Mar 2016 07:41:17 -0400 Received: from www.linutronix.de ([62.245.132.108]:59729 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934508AbcCQLlO (ORCPT ); Thu, 17 Mar 2016 07:41:14 -0400 Date: Thu, 17 Mar 2016 12:39:46 +0100 (CET) From: Thomas Gleixner To: Peter Zijlstra cc: Xiong Zhou , "linux-kernel@vger.kernel.org" , Ingo Molnar , Borislav Petkov , Andreas Herrmann , Jens Axboe Subject: Re: 4.5.0+ panic when setup loop device In-Reply-To: <20160317102633.GR6344@twins.programming.kicks-ass.net> Message-ID: References: <20160317095220.GO6344@twins.programming.kicks-ass.net> <20160317102633.GR6344@twins.programming.kicks-ass.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); } }