linux-kernel - Re: Should io(read|write)(8|16|32)_rep take (const|) volatile u(8|16|32) _

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, 01 Feb 2007 19:15:54 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Michael K. Edwards" <medwards.linux@...il.com>
CC:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: Should io(read|write)(8|16|32)_rep take (const|) volatile u(8|16|32)
 __iomem *addr?

Michael K. Edwards wrote:
> 
> It looks to me, by comparison to memcpy_(from|to)io, as if the
> volatiles ought to be there.  It also looks to me like the void *
> parameters should be u(8|16|32) * instead, so the compiler knows what
> alignment to expect (the implementations would generally fail or suck
> on non-aligned arguments).  (That would also be more consistent with
> the fact that the length parameters are in (8|16|32)-bit units, not
> octets.)
> 
> Opinions?
> 

The real question is whether or not gcc does anything sane with "const 
volatile", which may incorrectly sound oxymoronic to some people (it's 
not, const means "this element must not be written to" and volatile 
means "reading or writing this element has side effects".)

I would argue the right thing to do is to do the patch assuming gcc is 
sane, and let it sit in -mm for a kernel cycle or two.

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