Thread (11 messages) 11 messages, 5 authors, 2016-02-12

Re: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE

From: Russell King - ARM Linux <hidden>
Date: 2016-02-11 10:47:15
Also in: linux-arm-kernel, lkml

On Tue, Feb 09, 2016 at 06:37:46PM -0800, Guenter Roeck wrote:
On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
quoted
On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
quoted
IS_ERR_VALUE() assumes that its parameter is an unsigned long.
It can not be used to check if an unsigned int reflects an error.
Doing so can result in the following build warning.

drivers/tty/serial/digicolor-usart.c: In function ‘digicolor_uart_probe’:
include/linux/err.h:21:38: warning:
        comparison is always false due to limited range of data type
drivers/tty/serial/digicolor-usart.c:485:6: note:
        in expansion of macro ‘IS_ERR_VALUE’

If that warning is seen, an error return from platform_get_irq() is missed.
The patch looks correct to me, but what compiler version and which kernel
tree is it that triggered the warning?

Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
changes are still under discussion, but I don't see that warning with
any of the versions.
I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.

I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
I disagree.  What happens if (eg) you decide to do this:

	u8 irq;

	irq = platform_get_irq(...);
	if (IS_ERR_VALUE(irq))
		...

is that the fault of IS_ERR_VALUE() that it will never be true?  No, it's
a programming error in the caller, because the caller is using the wrong
type here - in fact, you can't do anything in IS_ERR_VALUE() to correct
that.

The same is true if you assign an error value to an unsigned int: the
problem is in the caller, not in IS_ERR_VALUE().

What would be preferable is if there was some way IS_ERR_VALUE() could
detect if it's used on something that isn't at least a short, and is
signed, but I suspect coccinelle can do that much better than trying to
work out some way to get the C compiler to check that.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help