linux-kernel - Re: [PATCH][RFC] getting rid of stupid loop in 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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jul 2007 11:24:49 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@....linux.org.uk>
cc:	David Miller <davem@...emloft.net>, jeremy@...p.org, hpa@...or.com,
	kaos@....com.au, xyzzy@...akeasy.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH][RFC] getting rid of stupid loop in BUG()

On Wed, 25 Jul 2007, Al Viro wrote:
> 
> Umm...  Actually, we might be able to do something like
> {
> 	l: __builtin_trap();
> 	static struct ... v __attribute__((section(...))) = { &&l, n, file };

No.

A C-level label is a pointer to a C-level construct.

The compiler may have reasons to put other instructions in between the 
label and the final end result of the __builtin_trap. The above may work 
for some trivial test-case, but in the end, the label and the __builtin 
are *not* atomic, and the compiler may well end up having register spills 
etc in there, or having CSE'd two traps, or any number of details meaning 
that the label doesn't point to the exact ud2 instruction.

			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/