linux-kernel - Re: [PATCH] x86: Remove readq()/writeq() on 32-bit

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:	Thu, 14 May 2009 16:19:03 +0900
From:	Hitoshi Mitake <h.mitake@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Roland Dreier <rdreier@...co.com>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	tglx@...utronix.de, rpjday@...shcourse.ca,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Remove readq()/writeq() on 32-bit

On Wed, 13 May 2009 20:49:26 -0400
Jeff Garzik <jeff@...zik.org> wrote:

> H. Peter Anvin wrote:
> > Jeff Garzik wrote:
> >> Judging from this thread and past, I think people will continue to 
> >> complain and get confused, even with the above.
> >>
> > 
> > Do you really think so?  Seems unfortunate, since an API rename would be
> > way more invasive.  This is the entirety of the header patch
> > (compile-tested using 32-bit allyesconfig).
> 
> The header patch does not lessen the confusion, because you cannot look 
> at the code and immediately tell what is going on...
> 
> Having a single function's behavior change based on #include selection 
> is /not/ intuitive at all, particularly for driver writers.  That is 
> unlike almost every other Linux API, where functions' behavior stays 
> constant across platforms, regardless of magic "under the hood."
> 
> That sort of trick is reserved for arch maintainers who know what they 
> are doing :)
> 
> 	Jeff
> 
> 
> 

I found another way:
Making architecture with atomic readq/writeq provide HAVE_READQ_ATOMIC/HAVE_WRITEQ_ATOMIC
and making architecture with non-atomic readq/writeq provide HAVE_READQ/HAVE_WRITEQ.
(HAVE_READQ_ATOMIC/HAVE_WRITEQ_ATOMIC should double as HAVE_READQ/HAVE_WRITEQ.)

So driver programmers who need atomic readq/writeq can judge existence of API they really need.
If platform doesn't provide atomic readq/writeq, drivers need these can be disabled by Kconfig.
And bugs Roland and David talking about will be banished.
How about this? > Roland and David
I wrote a test patch. Request for comments.

Signed-off-by: Hitoshi Mitake <h.mitake@...il.com>

---
 arch/x86/Kconfig |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index df9e885..c94fc48 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -19,8 +19,6 @@ config X86_64
 config X86
 	def_bool y
 	select HAVE_AOUT if X86_32
-	select HAVE_READQ
-	select HAVE_WRITEQ
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_IDE
 	select HAVE_OPROFILE
@@ -2022,6 +2020,20 @@ config HAVE_ATOMIC_IOMAP
 	def_bool y
 	depends on X86_32
 
+config HAVE_READQ
+	def_bool y
+
+config HAVE_WRITEQ
+	def_bool y
+
+config HAVE_READQ_ATOMIC
+	def_bool y
+	depends on X86_64
+
+config HAVE_WRITEQ_ATOMIC
+	def_bool y
+	depends on X86_64
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"
-- 
1.5.6.5

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