All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Hajda <a.hajda@samsung.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: open list <linux-kernel@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v2] err.h: allow IS_ERR_VALUE to handle properly more types
Date: Tue, 02 Feb 2016 09:22:54 +0100	[thread overview]
Message-ID: <56B0675E.8070309@samsung.com> (raw)
In-Reply-To: <20160201222351.dbbca353.akpm@linux-foundation.org>

On 02/02/2016 07:23 AM, Andrew Morton wrote:
> On Thu, 28 Jan 2016 09:27:28 +0100 Andrzej Hajda <a.hajda@samsung.com> wrote:
>
>> Current implementation of IS_ERR_VALUE works correctly only with
>> following types:
>> - unsigned long,
>> - short, int, long.
>> Other types are handled incorrectly either on 32-bit either on 64-bit
>> either on both architectures.
>> The patch fixes it by comparing argument with MAX_ERRNO casted
>> to argument's type for unsigned types and comparing with zero for signed
>> types. As a result all integer types bigger than char are handled properly.
>>
>> I have analyzed usage of IS_ERR_VALUE using coccinelle and in about 35
>> cases it is used incorrectly, ie it can hide errors depending of 32/64 bit
>> architecture. Instead of fixing usage I propose to enhance the macro
>> to cover more types.
>> And just for the record: the macro is used 101 times with signed variables,
>> I am not sure if it should be preferred over simple comparison "ret < 0",
>> but the new version can do it as well.
>>
>> And below list of detected potential errors:
>>
>> ...
>>
>> --- a/include/linux/err.h
>> +++ b/include/linux/err.h
>> @@ -18,7 +18,9 @@
>>  
>>  #ifndef __ASSEMBLY__
>>  
>> -#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
>> +#define IS_ERR_VALUE(x) ((typeof(x))(-1) <= 0 \
>> +				? unlikely((x) < 0) \
>> +				: unlikely((x) >= (typeof(x))-MAX_ERRNO))
>>  
> hm, seems complicated.  Can we simply cast the value to long?
>
> #define IS_ERR_VALUE(x) ((long)x < 0) && (long)x >= (long)-MAX_ERRNO)
>
> and simplify that to
>
> #define IS_ERR_VALUE(x) ((unsigned long)(long)x >= (unsigned long)-MAX_ERRNO)
>
> or something like that.
It will not work with u32 on 64bit systems.

Short rationales behind my implementation:

1. Typical usage pattern of the macro looks like:
T x;
...
x = -ESOME_ERROR;
...
if (IS_ERR_VALUE(x))
    ...

In error assignment we have casting of -ESOME_ERROR to type T.
Casting of -MAX_ERRNO to the same type in the macro assures that
comparison will be sane, at least for types big enough. In short we ends
at following expression (for unsigned types):
    (T)-ESOME_ERROR >= (T)-MAX_ERRNO
In old implementation we ended at:
    (unsigned)(T)-ESOME_ERROR >= (unsigned)-MAX_ERRNO
Different castings for -ESOME_ERROR and for -MAX_ERRNO makes this
comparison incorrect for some types T.

2. Error checking is completely different for signed and unsigned vars:
a. signed are compared to 0: ret < 0.
b. unsigned are compared with some high value: ret >= (-MAX_ERRNO).
This dualism is clearly visible and emphasized in this implementation.
In old implementation IS_ERR_VALUE works correctly for some signed types
due to obscure C casting rules.

Summarizing: current implementation is short but tricky, answering why
it works/fails for certain types is quite challenging. On the other side
proposed implementation is longer but more straightforward, and of course
is correct for more types :)

Maybe, to make it more clear, it could be good to use separate macro for
signedness:

#define IS_SIGNED_TYPE(t) ((t)(-1) <= 0)

#define IS_ERR_VALUE(x) (IS_SIGNED_TYPE(typeof(x)) \
                ? unlikely((x) < 0) \
                : unlikely((x) >= (typeof(x))-MAX_ERRNO))
 
Regards
Andrzej

  reply	other threads:[~2016-02-02  8:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 14:58 [PATCH] err.h: allow IS_ERR_VALUE to handle properly more types Andrzej Hajda
2016-01-07 15:48 ` kbuild test robot
2016-01-28  8:27   ` [PATCH v2] " Andrzej Hajda
2016-02-02  6:23     ` Andrew Morton
2016-02-02  8:22       ` Andrzej Hajda [this message]
2016-02-03  0:33     ` Andrew Morton
2016-02-03 10:53       ` Andrzej Hajda
2016-02-03 13:15       ` [PATCH v3] " Andrzej Hajda
2016-02-04 12:40         ` Arnd Bergmann
2016-02-04 14:44           ` Andrzej Hajda
2016-02-04 15:00             ` Arnd Bergmann
2016-02-04 15:10               ` Arnd Bergmann
2016-02-04 18:59           ` Andrew Morton
2016-02-05 10:52             ` Arnd Bergmann
2016-02-08  8:45               ` Andrzej Hajda
2016-02-08 12:01                 ` Arnd Bergmann
2016-02-09  1:44                   ` Al Viro
2016-02-09  8:42                   ` Andrzej Hajda
2016-02-10 21:01                     ` Arnd Bergmann
2016-02-11  7:00                       ` Andrzej Hajda
2016-02-11 16:39                         ` Arnd Bergmann
2016-02-12 14:45                           ` Andrzej Hajda
2016-02-11 21:14                         ` Al Viro
2016-02-04 23:37         ` Rasmus Villemoes
2016-02-10 15:16           ` Guenter Roeck
2016-01-15 13:45 ` [PATCH] " Andrzej Hajda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B0675E.8070309@samsung.com \
    --to=a.hajda@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.