linux-kernel - Re: [PATCH 00/34] _

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]

Date:	Fri, 9 Feb 2007 13:33:55 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Heiko Carstens <heiko.carstens@...ibm.com>,
	Alon Bar-Lev <alon.barlev@...il.com>,
	linux-kernel@...r.kernel.org, bwalle@...e.de,
	rmk+lkml@....linux.org.uk, spyro@....com, davej@...emonkey.org.uk,
	hpa@...or.com, Riley@...liams.name, tony.luck@...el.com,
	geert@...ux-m68k.org, ralf@...ux-mips.org, matthew@....cx,
	grundler@...isc-linux.org, kyle@...isc-linux.org, paulus@...ba.org,
	schwidefsky@...ibm.com, lethal@...ux-sh.org, davem@...emloft.net,
	uclinux-v850@....nec.co.jp, ak@....de, vojtech@...e.cz,
	chris@...kel.net, len.brown@...el.com, lenb@...nel.org,
	herbert@...dor.apana.org.au, viro@...iv.linux.org.uk,
	bzolnier@...il.com, dmitry.torokhov@...il.com, dtor@...l.ru,
	jgarzik@...ox.com, linux-mm@...ck.org, dwmw2@...radead.org,
	patrick@...epenguin.com, kuznet@....inr.ac.ru, pekkas@...core.fi,
	jmorris@...ei.org, philb@....org, tim@...erelk.net, andrea@...e.de,
	ambx1@....rr.com, James.Bottomley@...eleye.com,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH 00/34] __initdata cleanup

On Fri, 9 Feb 2007 18:37:34 +0100 (CET)
Roman Zippel <zippel@...ux-m68k.org> wrote:

> Hi,
> 
> On Fri, 9 Feb 2007, Heiko Carstens wrote:
> 
> > And indeed all the __initdata annotated local and global variables on
> > s390 are in the init.data section. So I'm wondering what this patch
> > series is about. Or I must have missed something.
> 
> I think it reaches back to times when gcc 2.7.* was still supported, which 
> does behave as described in the documentation. gcc 2.95 and newer don't 
> require explicit initialization anymore, so this has become a non-issue.
> 

Yes, nobody's been observing any problems arising from this, and if this
memory was really uninitialised, people would be hitting problems.

I don't want to have to require that all __attribute__((section)) storage
be initialised - people will surely forget to do it and things will slip
through.

If we really do have a problem here it'd be better to fix it in some
central and global fashion: either by ensuring that each architecture's
startup code will zero this memory or by some compiler/linker option such
as -fno-common.

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