linux-kernel - Re: [PATCH v2 00/15] clean up page aligned data and bss sections

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]

Message-ID: <alpine.DEB.1.10.0904281527210.1623@vinegar-pot.mit.edu>
Date:	Tue, 28 Apr 2009 15:48:24 -0400 (EDT)
From:	Tim Abbott <tabbott@....EDU>
To:	Sam Ravnborg <sam@...nborg.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Anders Kaseorg <andersk@....edu>,
	Waseem Daher <wdaher@....edu>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Jeff Arnold <jbarnold@....edu>,
	Paul Mundt <lethal@...ux-sh.org>,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v2 00/15] clean up page aligned data and bss sections

On Tue, 28 Apr 2009, Tim Abbott wrote:

> Here's a new version of the page-aligned section cleanup patch
> series.  Changes since last version include:

Sam,

I am close to having prepared another 4 patch series of similar size to 
this one for .data.nosave, .data.cacheline_aligned, .data.init_task, and 
.data.read_mostly.  Along with this page-aligned series and the things 
that have already been merged, I think these are all of the major 
cross-architecture patchsets needed for -ffunction-sections (there will 
remain a good number of section names that only appear on one or two 
architectures).

It seems with this set of patches that we're going to bother all the arch 
maintainers several times if we handle these all completely independently 
(especially since each patch series has patches that depend on patches 
from the previous one).  So, I was thinking perhaps we should proceed as 
follows:

(1) I send a patch series that does the architecture-independent macro 
additions as well as the changes for one architecture (say, x86) to use 
those macros so that they can be reviewed along with the actual usage.

(2) We get those reviewed and merge at least the architecture-independent 
patches

(3) I can send one patch series for each architecture that is just using 
the macros that have already been merged; then the patch series are nicely 
decoupled and each arch maintainer only has to ack a single set of changes 
to their architecture.

Does this plan make sense?

	-Tim Abbott

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