linux-kernel - Re: 4.5.0+ panic when setup loop device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Mar 2016 10:31:19 +0800
From:	Xiong Zhou <jencce.kernel@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Andreas Herrmann <aherrmann@...e.com>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: 4.5.0+ panic when setup loop device

Hi,

On Thu, Mar 17, 2016 at 7:39 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 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.

No panic with both Peter's patch and yours.

Thanks all.

--
Xiong

>
> 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);
>         }
>  }
>
>
>
>
>
>
>
>