linux-kernel - Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE

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]

Message-ID: <49EDE9E9.8090905@zytor.com>
Date:	Tue, 21 Apr 2009 08:44:41 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Hitoshi Mitake <h.mitake@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>, Roland Dreier <rdreier@...co.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Robert P. J. Day" <rpjday@...shcourse.ca>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars

Hitoshi Mitake wrote:
> I suggest 2) (or 3)).
> Because there's no problem since ported readq/writeq on x86_32.
> And as H. Peter Anvin mentioned non-atomic is generally fine.

Okay, I'm going to throw in yet another wrench in the machinery.

There are devices which really only want to use writeq() if it is an
inexpensive (no x86 MMX hacks) atomic operation.

What follows is *NOT* a hypothetical example, I worked on a real device
which behaved this way:

Consider a device with a set of control registers in device memory.  You
can issue a whole command sequence at one point, but the command isn't
activated until a write is received with a certain bit set (located in
the high half of the last qword.)

For performance, the device provides its registers mapped to two
different physical addresses, with the intent that the OS will map one
of them write-combining.

Thus, what you want is to perform all writes but the very last one as a
write-combining write; the very last write should be a conventional I/O
write that flushes the write combiners ahead of itself and triggers the
write.

Now, in theory you could use writel() for this, but if you have a
working writeq() [e.g. 64-bit mode] you want to use it.

So it's important that the driver can know when readq/writeq are
emulated at all.

One way to deal with that is the <linux/io64*.h> method, another is with
feature test macros.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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