netdev - Re: [PATCH] make atomic_t volatile on all architectures

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:	Sun, 12 Aug 2007 21:13:20 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	wjiang@...ilience.com, wensong@...ux-vs.org,
	heiko.carstens@...ibm.com, linux-kernel@...r.kernel.org,
	ak@...e.de, cfriesen@...tel.com, netdev@...r.kernel.org,
	horms@...ge.net.au, akpm@...ux-foundation.org,
	schwidefsky@...ibm.com, Chuck Ebbert <cebbert@...hat.com>,
	davem@...emloft.net, zlynx@....org, Chris Snook <csnook@...hat.com>
Subject: Re: [PATCH] make atomic_t volatile on all architectures

>> Yeah.  Compiler errors are more annoying though I dare say ;-)
>
> Actually, compile-time errors are fine,

Yes, they don't cause data corruption or anything like that,
but I still don't think the 390 people want to ship a kernel
that doesn't build -- and it seems they still need to support
GCC versions before 4.0.  Up until the day they can finally
drop 3.x, they'll have to...

> and easy to work around.

...use the simple workaround, annoying as it may be, at least
it works.  That's all I'm saying.

> *Much*
> more annoying is when gcc actively generates subtly bad code.

Quite so.

> We've had
> use-after-free issues due to incorrect gcc liveness calculations etc, 
> and
> inline asm has beeen one of the more common causes - exactly because 
> the
> kernel is one of the few users (along with glibc) that uses it at all.

The good news is that things are getting better since more and
more of the RTL transformations are ripped out.

> Now *those* are hard to find - the code works most of the time, but the
> compiler has inserted a really subtle race condition into the code
> (deallocated a local stack entry before last use). We had that with our
> semaphore code at some point.

Yeah, magnifying glass + lots of time kind of bug.  Lovely :-/


Segher

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html