[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070104191046.GV17561@ftp.linux.org.uk>
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