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:	Sun, 03 Jun 2012 17:35:54 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Yong Zhang <yong.zhang0@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tony Luck <tony.luck@...el.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Mike Frysinger <vapier@...too.org>,
	Hirokazu Takata <takata@...ux-m32r.org>,
	Richard Kuo <rkuo@...eaurora.org>,
	David Howells <dhowells@...hat.com>,
	Bob Liu <lliubbo@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Richard Weinberger <richard@....at>,
	Jesper Nilsson <jesper.nilsson@...s.com>,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Matt Turner <mattst88@...il.com>, nikunj@...ux.vnet.ibm.com
Subject: Re: [PATCH 01/27] smpboot: Provide a generic method to boot	secondary
 processors

On 06/03/2012 05:09 PM, Russell King - ARM Linux wrote:

> On Sun, Jun 03, 2012 at 05:03:50PM +0530, Srivatsa S. Bhat wrote:
>> That's a good point! But unfortunately we can't do that just yet.
>> Because, some architectures have explicit comments that say that
>> irqs must be enabled at a certain point in time, or have something
>> special than just a local_irq_enable(), and hence fall under the
>> __cpu_post_online() function when converted to this model.
>>
>> Examples: ARM (patch 26) and ia64 (patch 15)
>>
>> Unless the maintainers give a go-ahead to change them, I don't
>> think it would be safe.. (I have added the Notes section to each
>> patch to get the attention of the maintainers to such issues).
> 
> I have no intention of touching ARMs SMP bringup any more than is
> absolutely necessary - this code is extremely fragile, and it's taken
> a long time to get it to where it presently is, where most people are
> happy with it.
> 

> Especially problematical is stuff like where we enable interrupts in

> relation to other activities.
> 
> It's probably best to describe the code not as "mostly bug free" but
> as "causes the least pain" because I don't think there is a solution
> which satisfies all the constraints placed upon this code path by
> the various parts of the kernel.
> 


Thanks for your comments Russell. I understand your concerns. So, the
ARM patch does no functional change and retains how and where the
interrupts are enabled. And from looking at what you said above about
the bringup being fragile, I think even in future you wouldn't want any
functional changes to ARM just to make it fit into some generic model.
Thanks for the clarification.

However, what are your thoughts on the existing ARM patch (patch 26)
(which doesn't cause any functional changes)? That shouldn't pose any
problems right?

Regards,
Srivatsa S. Bhat

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ