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]

Message-Id: <20110117.223513.183031917.davem@davemloft.net>
Date:	Mon, 17 Jan 2011 22:35:13 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	rostedt@...dmis.org
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

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 it doesn't, then we should investigate to find out the real reason
why.

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