linux-kernel - Re: [PATCH v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20151110162553.GH8644@n2100.arm.linux.org.uk>
Date:	Tue, 10 Nov 2015 16:25:53 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Kapil Hali <kapilh@...adcom.com>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>, Ray Jui <rjui@...adcom.com>,
	Scott Branden <sbranden@...adcom.com>,
	Jon Mason <jonmason@...adcom.com>,
	Gregory Fong <gregory.0xf0@...il.com>,
	Lee Jones <lee@...nel.org>, Hauke Mehrtens <hauke@...ke-m.de>,
	Kever Yang <kever.yang@...k-chips.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Olof Johansson <olof@...om.net>,
	Paul Walmsley <paul@...an.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Chen-Yu Tsai <wens@...e.org>, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH v3 1/4] dt-bindings: add SMP enable-method for Broadcom
 NSP

On Tue, Nov 10, 2015 at 09:33:12PM +0530, Kapil Hali wrote:
> Hi Russel,

Wrong.  Look at my name as sent in the From: and as quoted in the very
next line.  As far as I'm concerned (and I don't care what other people
say) it's disrespectful to spell people's names incorrectly.

> It was clear the very first time itself as pointed out by you and the 
> lead developers and hence the change was readily sent in the very next
> patch set. I didn't change a comment in this patch, which is misleading 
> about the SMP enable-method used in the patch set, it is my mistake and   
> I apologies for the same. I will change it and send the next patch set.

Thanks.

> Also, before sending out the patch set, I had asked for a clarification 
> about the method: https://lkml.org/lkml/2015/11/6/234

Sorry, I don't read every single email irrespective of how it's marked.
There's way too much email, and way too much mail with improperly
classified recipient lists to be able to usefully sort this mail.
(If you do the math, the email rate during a 12 hour working day from
just linux-arm-kernel is one email every 2.5 minutes, assuming 300 emails
a day.  It takes way longer than that to compose a proper reply to an
email - I've spent around 15 minutes on this one alone.  Hence, if I'm
busy, I more or less totally ignore email now, and rarely bother to
"catch up" with missed emails.)

> For my understanding, I am repeating my query- In case of simple method of 
> waking up secondary core, smp_boot_secondary() will always return success 
> indicating secondary core successfully started. I understand that in 
> __cpu_up(), primary core waits for completion till secondary core comes 
> online or time outs. However, is it appropriate to return successful start 
> of secondary core without knowing if it really did?

Yes, because all that your smp_boot_secondary() should be doing is
trying to start the core.  If you encounter an error trying to do so,
that's what the error return is for.

If you just set a bit somewhere to tell the hardware to release the
secondary core's reset, then if you set the bit and return success,
that's prefectly acceptable.  The core ARM SMP code will then wait
up to one second for the secondary core to become known to the kernel
before declaring that the CPU failed to come online.

If it fails to appear, we assume that it will never appear - and
actually at that point the system is in an unknown state: if the
secondary CPU crashed during its boot, it could start scribbling
into memory or touching devices in an unpredictable way: the only
sane answer is to reboot the whole system to ensure that it's back
to a known good state.  Hence why we don't provide any cleanup at
the point of a failed secondary CPU (I've been debating about
tainting the kernel at that point, so we know when things have
gone bad.)

Hope this helps.

-- 
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/