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] [day] [month] [year] [list]

Date:	Wed, 29 Apr 2009 22:50:47 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Tim Abbott <tabbott@....EDU>
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, Apr 28, 2009 at 03:48:24PM -0400, Tim Abbott wrote:
> 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.

Yes - lets get the support stuff applied first and work out from there.
I plan to apply your patches to kbuild-next during the weekend so
we have them in a tree that hits -next.

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