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
| ||
|
Date: Thu, 4 Jan 2007 19:10:46 +0000 From: Al Viro <viro@....linux.org.uk> To: Linus Torvalds <torvalds@...l.org> Cc: Segher Boessenkool <segher@...nel.crashing.org>, Albert Cahalan <acahalan@...il.com>, akpm@...l.org, linux-kernel@...r.kernel.org, s0348365@....ed.ac.uk, bunk@...sta.de, mikpe@...uu.se Subject: Re: kernel + gcc 4.1 = several problems On Thu, Jan 04, 2007 at 09:47:01AM -0800, Linus Torvalds wrote: > NOBODY will guarantee you that they follow all standards to the letter. > Some use compiler extensions knowingly, but pretty much _everybody_ ends > up depending on subtle issues without even realizing it. It's almost > impossible to write a real program that has no bugs, and if they don't > show up in testing (because the compiler didn't generate buggy assembly > code from source code that had the _potential_ for bugs), they often won't > get fixed. > > The kernel does things like compare pointers across objects, and the > kernel EXPECTS it to work. I seriously doubt that the kernel is even > unusual in this. The common way to avoid AB-BA deadlocks in any threaded > code (whether kernel or user space) is to just take two locks in a > specific order, and the common way to do that for locks of the same type > is simply to compare the addresses). > > The fact that this is "undefined" behaviour matters not a _whit_. Not for > the kernel, and I bet not for a lot of other applications either. True, but we'd better understand what assumptions we are making. I have seen patches seriously attempting to _subtract_ unrelated pointers. And that simply doesn't work for obvious reasons... - 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/
Powered by blists - more mailing lists