linux-kernel - Re: [RFC/PATCH] arm: do not skip SMP init calls on SMP_ON

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:	Mon, 23 Nov 2015 13:04:24 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Nikita Yushchenko <nyushchenko@....rtsoft.ru>
Cc:	Vladimir Murzin <vladimir.murzin@....com>,
	kuznetsovg@....rtsoft.ru, Ian Campbell <ian.campbell@...rix.com>,
	Mason <slash.tmp@...e.fr>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Will Deacon <will.deacon@....com>,
	Paul Kocialkowski <contact@...lk.fr>,
	linux-kernel@...r.kernel.org,
	Masahiro Yamada <yamada.m@...panasonic.com>,
	Pavel Machek <pavel@....cz>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC/PATCH] arm: do not skip SMP init calls on SMP_ON_UP case

On Mon, Nov 23, 2015 at 03:47:34PM +0300, Nikita Yushchenko wrote:
> >>>>> While running an imx6s boasrd, I got following message in boot log:
> >>>>>
> >>>>> [    0.032414] CPU1: failed to boot: -38
> >>>>>
> >>>>> This looked strange: imx6s is singe-core and kernel perfectly knows
> >>>>> that. However, for some reason it tries to initialize CPU 1?
> >>>>>
> >>>>> I found this to be caused by
> >>>>> - CONFIG_SMP_ON_UP successfully detects that system is single core,
> >>>>> - this causes is_smp() to return false,
> >>>>> - this causes setup_arch() to skip smp_init_cpus() call,
> >>>>> - this skips board-specific code that sets cpu_possible mask.
> >>>>
> >>>> Right, so you should end up with the possible and present masks
> >>>> containing just one CPU, which should prevent the kernel trying to
> >>>> bring any secondary CPUs online.
> >>>
> >>> Kernel that is running here still tries to init CPU 1 for some reason.
> >>
> >> I *guess* cpus node [1] in your dts has more than one cpu entry, could
> >> you check please?
> > 
> > Indeed looks so:
> > 
> > # ls /proc/device-tree/cpus
> > #address-cells  #size-cells  cpu@0  cpu@1  name
> > 
> > But my custom device tree just includes imx6dl.dtsi
> > 
> > So it is imx6dl.dtsi in linux-imx tree broken?..
> 
> Just booted mainline...  unline linux-imx, it does not try to init cpu1.
> 
> However, imx6dl.dtsi from mainline also has both cpu@0 and cpu@1
> 
> So missing piece in linux-imx is elsewhere :(

It works as you mentioned - and it relies upon the code you tried to
modify.

The early boot code detects that the boot CPU is not SMP capable, so
through SMP_ON_UP, it "turns off" SMP support by fixing up the code
and making is_smp() return false.

This prevents smp_init_cpus() being called, which in turn prevents
imx_smp_init_cpus() executing, which prevents the CPU possible mask
including any CPU but the boot CPU.

As only the boot CPU is possible, this prevents the SMP code trying
to bring any secondary CPUs online.

Applying your patch which removes the is_smp() check will break this
logic.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/