linux-kernel - Re: [PATCH] x86: SGU UV Add volatile to macros that access chipset registers

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:	Wed, 9 Sep 2009 14:38:30 -0500
From:	Jack Steiner <steiner@....com>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	Daniel Walker <dwalker@...o99.com>, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: SGU UV Add volatile to macros that access chipset registers

On Wed, Sep 09, 2009 at 12:54:29PM -0600, Chris Friesen wrote:
> On 09/09/2009 12:11 PM, Daniel Walker wrote:
> > On Wed, 2009-09-09 at 13:01 -0500, Jack Steiner wrote:
> >> Volatile is being added to the accessor functions that are used to
> >> read/write memory-mapped I/O registers located within the UV chipset.
> >> The use of volatile is hidden within the functions and is not exposed
> >> to the users of the functions.
> >>
> >> Note that the use is limited to the accessor functions in the header
> >> file. No .c files are changed or need to know about volatile.
> >>
> >>
> >> This seems to be consistent with other uses of volatile within the kernel.
> > 
> > The document that I cited specifically addresses memory accessors as not
> > needing the volatile keyword .. So your still not addressing exactly why
> > your code needs it .. Are your accessors special in some way? Is there
> > some defect your seeing without the volatile keyword?
> 
> 
> >From that document:
> 
> "There are still a few rare situations where volatile makes sense in the
> kernel:
> 
>   - The above-mentioned accessor functions might use volatile on
>     architectures where direct I/O memory access does work.
>     Essentially, each accessor call becomes a little critical section
>     on its own and ensures that the access happens as expected by the
>     programmer."
> 
> 
> However, the fact that these functions are returning volatile pointers
> is a bit sketchy.  Normally accesses to such memory would be wrapped
> entirely in a read/write function which would handle the volatility
> internally to the function.
> 
> In this case there's no point in the function returning a "volatile
> unsigned long *" if it's going to be cast to a volatile pointer before
> being dereferenced.

make sense.

How is this..... Avoids adding volatile to any return types.
--------------------------------------------------------


Add "volatile" to the SGI UV read/write macros that are used to access chipset
memory mapped registers.

Signed-off-by: Jack Steiner <steiner@....com>


---
 arch/x86/include/asm/uv/uv_hub.h |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

Index: linux/arch/x86/include/asm/uv/uv_hub.h
===================================================================
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h	2009-09-09 01:34:02.000000000 -0500
+++ linux/arch/x86/include/asm/uv/uv_hub.h	2009-09-09 14:36:23.000000000 -0500
@@ -258,13 +258,13 @@ static inline unsigned long *uv_global_m
 static inline void uv_write_global_mmr32(int pnode, unsigned long offset,
 				 unsigned long val)
 {
-	*uv_global_mmr32_address(pnode, offset) = val;
+	*(volatile unsigned long *)uv_global_mmr32_address(pnode, offset) = val;
 }
 
 static inline unsigned long uv_read_global_mmr32(int pnode,
 						 unsigned long offset)
 {
-	return *uv_global_mmr32_address(pnode, offset);
+	return *(volatile unsigned long *)uv_global_mmr32_address(pnode, offset);
 }
 
 /*
@@ -281,13 +281,13 @@ static inline unsigned long *uv_global_m
 static inline void uv_write_global_mmr64(int pnode, unsigned long offset,
 				unsigned long val)
 {
-	*uv_global_mmr64_address(pnode, offset) = val;
+	*(volatile unsigned long *)uv_global_mmr64_address(pnode, offset) = val;
 }
 
 static inline unsigned long uv_read_global_mmr64(int pnode,
 						 unsigned long offset)
 {
-	return *uv_global_mmr64_address(pnode, offset);
+	return *(volatile unsigned long *)uv_global_mmr64_address(pnode, offset);
 }
 
 /*
@@ -301,22 +301,22 @@ static inline unsigned long *uv_local_mm
 
 static inline unsigned long uv_read_local_mmr(unsigned long offset)
 {
-	return *uv_local_mmr_address(offset);
+	return *(volatile unsigned char *)uv_local_mmr_address(offset);
 }
 
 static inline void uv_write_local_mmr(unsigned long offset, unsigned long val)
 {
-	*uv_local_mmr_address(offset) = val;
+	*(volatile unsigned char *)uv_local_mmr_address(offset) = val;
 }
 
 static inline unsigned char uv_read_local_mmr8(unsigned long offset)
 {
-	return *((unsigned char *)uv_local_mmr_address(offset));
+	return *((volatile unsigned char *)uv_local_mmr_address(offset));
 }
 
 static inline void uv_write_local_mmr8(unsigned long offset, unsigned char val)
 {
-	*((unsigned char *)uv_local_mmr_address(offset)) = val;
+	*((volatile unsigned char *)uv_local_mmr_address(offset)) = val;
 }
 
 /*
--
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/