linux-kernel - Re: [PATCH 0/4] Add support for compiling with -ffunction-sections -fdata-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]

Date:	Tue, 24 Mar 2009 03:23:39 -0400 (EDT)
From:	Tim Abbott <tabbott@....EDU>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
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>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>, Jeff Arnold <jbarnold@....edu>
Subject: Re: [PATCH 0/4] Add support for compiling with -ffunction-sections
 -fdata-sections

On Tue, 24 Mar 2009, Stephen Rothwell wrote:

> On Tue, 24 Mar 2009 01:28:41 -0400 Tim Abbott <tabbott@....EDU> wrote:
> >
> > I'd like to see this patch series merged for 2.6.30.  It applies on
> > top of your current master (aka v2.6.29).  Patch 1/4 would benefit
> > from special treatment during the merge window, since it makes many
> > small changes in lots of files, and thus is likely to conflict with
> > other changes; the other patches are fairly small.
> 
> Indeed.  I just did a merge of your changes with next-20090323 and it
> conflicted with changes in 10 files across 4 architectures.  There has
> been work on several areas that you are changing here (some of which will
> make your life easier - like the percpu changes).  

Yeah, unfortunately, because people are always modifying the kernel's 
"magic" sections, a version of the patch that applies to master will 
basically always conflict with something in linux-next (at least, this has 
been my experience updating it during the 2.6.29 release cycle).  As Rusty 
Russell said last month about this patch, there's no good time for this 
kind of change.

I'm happy to rebase this patch again to merge it late in the merge window 
if that makes life easier for others.  Merge conflicts with this patch are 
hard to avoid but fairly easy to resolve -- you just replace .data.foo 
with .data..foo (etc.).

> I suspect that at least some of patch 1/4 could have bee split out and 
> sent to the appropriate maintainers.

Because the change is actually renaming sections, it needs to be made on 
all the architectures at the same time as changes are made to the 
architecture-independent code.  So, changes in, say, include/linux/init.h:

-#define __nosavedata __section(.data.nosave)
+#define __nosavedata __section(.data..nosave)

must be synchronized with, say, arch/arm/kernel/vmlinux.lds.S:

                . = ALIGN(4096);
                __nosave_begin = .;
-               *(.data.nosave)
+               *(.data..nosave)

So, while it might have been useful to split out and send individual 
per-architecture patches to arch maintainers for review, that would not 
avoid the need to merge it as a single giant patch.

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