linux-kernel - Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi

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, 18 Jan 2011 12:30:56 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	David Miller <davem@...emloft.net>
Cc:	richm@...elvet.org.uk, 609371@...s.debian.org, ben@...adent.org.uk,
	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
	fweisbec@...il.com, mingo@...hat.com, Jesper.Nilsson@...s.com,
	jeffm@...e.com, mathieu.desnoyers@...icios.com
Subject: Re: Bug#609371: linux-image-2.6.37-trunk-sparc64: module scsi_mod:
 Unknown relocation: 36

On Mon, 2011-01-17 at 22:35 -0800, David Miller wrote:
> From: Steven Rostedt <rostedt@...dmis.org>
> Date: Mon, 17 Jan 2011 09:15:41 -0500
> 
> > Again, this is to help the linker keep arrays in tacked. Tracepoints are
> > allocated into the tracepoint section, and then read like an array. If
> > the linker adds holes as it links sections into one big one, then the
> > reading of the array breaks.
> > 
> > We either need to compact it (with the align(4)) which is undesirable,
> > or add our own holes like the above does.
> 
> Just take away all of the align directives, it should just work.

If that was the case, we would have never added it :-)

> 
> If it doesn't, then we should investigate to find out the real reason
> why.

OK, we can remove it and I can see what breaks.

> 
> The linker has no reason to add holes, and in fact if we are to believe
> the commit message for 86c38a31aa7f2dd6e74a262710bf8ebf7455acc5
> ("tracing: Fix ftrace_event_call alignment for use with gcc 4.5"), with
> gcc-4.x where x < 5, it did work even though some ftrace_event_call
> declarations lacked the align directive.
> 
> If this align thing is so critical, why don't we need it for the
> exception table entries which live in the "__ex_table" section in the
> kernel?  It's the same _exact_ kind of thing, and the asm sequence we
> use to populate it is identical to what GCC emits for the tracing
> object declarations in question.

But aren't the __ex_table entries just two words? Which would align
nicely regardless.

The ftrace_event_call is a relatively large structure, as it may end on
a 4 byte alignement, the linker may start the next section with more
space to get it back to a 8 byte alignment. This is assuming that x86_64
packs the array in 4 bytes.

Hmm, perhaps changing the alignment in vmlinux.lds.h would fix that.

Anyway, I'll revert that commit and see if I can break it again. If so,
then I'll look for other solutions.

Thanks!

-- Steve


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