[RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

[RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

[Chris Packham]

Update __read_32bit_c0_register() and __read_32bit_c0_ctrl_register() to
use "unsigned int res;" instead of "int res;". There is little reason to
treat these register values as signed. They are either counters (which
by definition are unsigned) or are made up of various bit fields to be
interpreted as per the CPU datasheet.

Signed-off-by: Chris Packham <judge.packham@gmail.com>

---
This has come up via u-boot[1] which sync's asm/mipsregs.h with the
kernel. In u-boots case the value read from read_c0_count() is assigned
to an unsigned long [2] which triggers a sign extension and causes a
bug.

U-boot should probably be more explicit about the types used for the
timer_read_counter() API but that aside is there any reason to treat
these values as signed integers? A quick grep around the arch/mips makes
me thing that there may be some bugs lurking when read_c0_count() starts
to yield a negative value but I haven't really explored any of them.

I also notice that read_32bit_cp1_register has a similar issue. I
haven't touched it at this stage but it probably makes sense to do so
for consistency if the CP0 macros are changed. Looking at the users of
read_32bit_cp1_register() it's probably less of an issue.

Thanks,
Chris
--
[1] - http://lists.denx.de/pipermail/u-boot/2015-July/219086.html
[2] - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/mips/cpu/time.c#l11

 arch/mips/include/asm/mipsregs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index c5b0956..54a942f 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -932,7 +932,7 @@ do {								\
  */
 
 #define __read_32bit_c0_register(source, sel)				\
-({ int __res;								\
+({ unsigned int __res;							\
 	if (sel == 0)							\
 		__asm__ __volatile__(					\
 			"mfc0\t%0, " #source "\n\t"			\
@@ -1014,7 +1014,7 @@ do {									\
  * On RM7000/RM9000 these are uses to access cop0 set 1 registers
  */
 #define __read_32bit_c0_ctrl_register(source)				\
-({ int __res;								\
+({ unsigned int __res;							\
 	__asm__ __volatile__(						\
 		"cfc0\t%0, " #source "\n\t"				\
 		: "=r" (__res));					\
-- 
2.5.0.rc0

Re: [RFC PATCH v1] mips: Use unsigned int when reading CP0 registers

[Ralf Baechle]

On Wed, Jul 15, 2015 at 10:44:30AM +1200, Chris Packham wrote:

> Update __read_32bit_c0_register() and __read_32bit_c0_ctrl_register() to
> use "unsigned int res;" instead of "int res;". There is little reason to
> treat these register values as signed. They are either counters (which
> by definition are unsigned) or are made up of various bit fields to be
> interpreted as per the CPU datasheet.
> 
> Signed-off-by: Chris Packham <judge.packham@gmail.com>
> 
> ---
> This has come up via u-boot[1] which sync's asm/mipsregs.h with the
> kernel. In u-boots case the value read from read_c0_count() is assigned
> to an unsigned long [2] which triggers a sign extension and causes a
> bug.
> 
> U-boot should probably be more explicit about the types used for the
> timer_read_counter() API but that aside is there any reason to treat
> these values as signed integers? A quick grep around the arch/mips makes
> me thing that there may be some bugs lurking when read_c0_count() starts
> to yield a negative value but I haven't really explored any of them.

Known issue but I've always been concerned about math with cycle values
like:

  unsigned int now, timeout = read_c0_counter() + a_bit_of_time;

  waste_some_time();

  if (timeout - read_c0_counter() < 0)
	do_timeout_stuff();

Which now with both variables being unsigned would yield a positive value
thus the if would never be taken.  This particular construction GCC would
warn about but there are other, constructs that wouldn't trigger a warning.

I don't even want to think about what C type propagation rules say about
mixing signed and unsigned types.  Whenever such knowledge is required
to figure out what a piece of code is doing it probably should be considered
broken anyway - but the mess resulting from unwanted sign is no better!

Anyway, I've queued your patch for 4.3.  Thanks!

> I also notice that read_32bit_cp1_register has a similar issue. I
> haven't touched it at this stage but it probably makes sense to do so
> for consistency if the CP0 macros are changed. Looking at the users of
> read_32bit_cp1_register() it's probably less of an issue.

I've cooked up a patch for read_32bit_cp1_register and queued it for 4.3.

  Ralf