linux-kernel - [RFP] atomic[64]_[read|set] asm implementations

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-next>] [day] [month] [year] [list]

Message-ID: <46C33E19.3050805@redhat.com>
Date:	Wed, 15 Aug 2007 13:55:37 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-arch@...r.kernel.org
Subject: [RFP] atomic[64]_[read|set] asm implementations

In the fallout from the recent atomic_t volatility discussions, patches 
have been posted to moot the compiler correctness issues by implementing 
atomic[64]_[read|set] in inline assembly on powerpc, i386, and x86_64. 
While I personally don't consider such implementations to be critically 
necessary, they slightly reduce binary size and greatly reduce lkml 
controversy, so I like them.

I'm not an inline assembly expert, but I would welcome it if those who 
are would like to submit implementations of these functions for 
architectures they're intimately familiar with.  I'll pull them into the 
atomic_t patch set I've stumbled into shepherding, and hopefully we can 
commit something all at once that makes all architectures consistent, 
resists compiler bugs, and doesn't piss off too many people.

For architectures whose maintainers aren't worried and whose 
developers/users aren't bothered enough to submit an inline assembly 
patch, I'll just keep the inlines with the *(volatile foo *)& casts, 
unless of course ISO clarifies the C standard to different effect while 
we're arguing over semantics and micro-optimizations.

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