| 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
| ||
|
Date: Fri, 28 Mar 2008 13:51:12 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Sam Ravnborg <sam@...nborg.org> CC: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu> Subject: Re: use of volatile in iounmap()? Sam Ravnborg wrote: > While reviewing some CAN driver I stumbled on iounmap > which has following prototype on x86: > > extern void iounmap(volatile void __iomem *addr); > > I argued that the driver should not use volatile > but then I cannot explain why the argument to > iounmap takes a volatile. > > The same goes for many other functions in > the io*.h headers. > > Grepping the other archs they mostly follow > same pattern. > > Can anyone explain the rational for volatile in this case. > Yes. The use of volatile in a function prototype like this means that it is valid to pass a volatile pointer to that function -- in other words, we're telling gcc that we're not going to do anything with the pointer that is invalid for a volatile pointer. A lot of the "volatile considered harmful" stuff that has been bandied about is explicitly about marking *data* items volatile (it does have its uses, but it's easy to get wrong); Linus has explicitly made the distinction between volatile *data* and volatile *operations*. -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/
Powered by blists - more mailing lists