linux-kernel - Re: [PATCH] Fix vmi time header bug

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:	Tue, 13 Mar 2007 10:53:13 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Andi Kleen <ak@...e.de>, zach@...are.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix vmi time header bug

On Tue, 13 Mar 2007, Andrew Morton wrote:
> 
> (The ARM thing is a pain, because the compiler cannot check that the
> definition and declaration match.  However something like sparse could do
> so).

Well, I guess sparse could do it, but the fact is, this is just a gcc bug. 
It would be much better if *gcc* just checked the function attributes it 
cared about. Anybody want to send a bug-report to the gcc lists?

Here's a trivial test-case.

	#define section(x) __attribute__((__section__(x)))

	extern int section(".text.one") test_function(int);

	int section(".text.two") test_function(int arg)
	{
		return arg+1;
	}

and the bug is that gcc doesn't warn about the section mismatch, and still 
seems to care.

(Now, if gcc doesn't care, missing the section from the declaration could 
be considered ok. But having explicit but *different* section declarations 
can clearly not be ok, and it seems that gcc sometimes *does* require 
sections to match, so it probably should always require them to match 
exactly).

We could make sparse care, but right now sparse ignores the section 
attribute *entirely*.

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