[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2046663.fHIlWH1ph1@wuerfel>
Date: Fri, 05 Feb 2016 11:52:29 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Andrzej Hajda <a.hajda@...sung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
open list <linux-kernel@...r.kernel.org>,
Bob Peterson <rpeterso@...hat.com>
Subject: Re: [PATCH v3] err.h: allow IS_ERR_VALUE to handle properly more types
On Thursday 04 February 2016 10:59:31 Andrew Morton wrote:
> On Thu, 04 Feb 2016 13:40:38 +0100 Arnd Bergmann <arnd@...db.de> wrote:
>
> > diff --git a/include/linux/err.h b/include/linux/err.h
> > index b7d4a9ff6342..bd4936a2c352 100644
> > --- a/include/linux/err.h
> > +++ b/include/linux/err.h
> > @@ -18,9 +18,7 @@
> >
> > #ifndef __ASSEMBLY__
> >
> > -#define IS_ERR_VALUE(x) ((typeof(x))(-1) <= 0 \
> > - ? unlikely((x) <= -1) \
> > - : unlikely((x) >= (typeof(x))-MAX_ERRNO))
> > +#define IS_ERR_VALUE(x) (unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
> >
> > static inline void * __must_check ERR_PTR(long error)
> > {
> >
> >
> > I'm not sure if the cast to 'unsigned long long' might cause less
> > efficient code to be generated by gcc. I would hope that it is smart
> > enough to not actually extend shorter variables to 64 bit before
> > doing the comparison but I have not checked yet.
>
> I did a quick test with i386 on drivers/nvmem/core.o. The patch takes
> the text size from 9098 bytes to 9133. That file has 11 instances of
> IS_ERR_VALUE().
This seems to be because it brings back the logic to what it was before
in case of 'int' arguments. I checked the assembly output and found mine
to be identical to v4.4 in this case:
text data bss dec hex filename
v4.4 9942 1872 2856 14670 394e drivers/nvmem/core.o
a.hajda 9922 1872 2856 14650 393a drivers/nvmem/core.o
arnd 9942 1872 2856 14670 394e drivers/nvmem/core.o
Andrzej's version is a little shorter on ARM because in case of signed numbers
it only checks for negative values, rather than checking for values in the
[-MAX_ERRNO..-1] range. I think the original behavior is more logical
in this case, and my version restores it.
Looking at drivers/char/mem.o, which had an actual bug that was fixed by
Andrzej's patch, the output with my version and his is identical (failing
an lseek on /dev/mem to offset 0xfffffffffffffe00 or higher, instead of
failing for offset 0x00000000fffffe00-0x00000000ffffffff).
Arnd
Powered by blists - more mailing lists